旧 Mac OS 的 C 编译器下 '\n' 的值是什么？

Question

背景：

在最高版本 9 的 Mac OS 版本中，文本文件的标准表示使用 ASCII CR（回车）字符（十进制值 13）来标记行尾。

Mac OS 10 与早期版本不同，它类似于 UNIX，并使用 ASCII LF（换行）字符（十进制值 10）来标记行尾。

问题是，在 OS X 之前的 Mac OS 版本的 C 和 C++ 编译器中字符常量 '\n' 和 '\r' 的值是什么？

有（至少）两种可能的方法可以采取：

1. 将'\n'视为ASCII LF字符，并在文本流的输出和输入中将其与CR转换（类似于Windows系统上的LF和CR-LF之间的转换）；或
2. 将'\n' 视为ASCII CR 字符，不需要对输入或输出进行转换。

第二种方法会有一些潜在的问题。一是假设'\n' 是LF 的代码可能会失败。 （无论如何，这样的代码本质上是不可移植的。）另一个是'\r' 仍然需要一个不同的值，并且在基于 ASCII 的系统上，CR 是唯一合理的值。并且 C 标准不允许 '\n' == '\r'（感谢 mafso 找到引用，5.2.2 第 3 段），因此必须将一些 other 值用于 '\r'。

这个C程序在Mac OS下编译执行N，N小于10的输出是什么？

#include <stdio.h>
int main(void) {
    printf("'\\n' = %d\n", '\n');
    printf("'\\r' = %d\n", '\r');
    if ('\n' == '\r') {
        printf("Hmm, this could be a problem\n");
    }
}

这个问题适用于 C 和 C++。我想两者的答案都是一样的。

答案也可能因一个 C 编译器而异——但我希望编译器实现者能够保持彼此之间的一致性。

为了清楚起见，我不是在问旧版本的 Mac OS 用什么表示法来表示文本文件中的行尾 。我的问题是专门针对 C 或 C++ 源代码中的常量 '\n' 和 '\r' 的值。我知道将'\n'（无论它的值是什么）打印到文本流会导致它被转换为系统的行尾表示（在本例中为ASCII CR）；这种行为是 C 标准所要求的。

Answer 1

字符常量 \r 和 \n 的值在经典 Mac OS 环境中与在其他任何地方完全相同：\r 是 CR 是 ASCII 13 (0x0d)； \n 是 LF 是 ASCII 10 (0x0a)。在经典 Mac OS 上唯一不同的是 \r 用作文本编辑器中的“标准”行结尾，就像在 UNIX 系统上使用 \n 或在 DOS 和 Windows 系统上使用 \r\n 一样。

这是一个在 Mac OS 9 上的 Metrowerks CodeWarrior 中运行的简单测试程序的屏幕截图，例如：

请记住，经典 Mac OS 系统没有系统范围的标准 C 库！ printf() 之类的函数仅作为特定于编译器的库的一部分存在，例如 CodeWarrior 的 SIOUX，它通过将输出写入带有文本字段的窗口来实现 C 标准 I/O。因此，标准文件 I/O 的某些实现可能已经在 \r 和 \n 之间执行了一些自动转换，这可能是您所想的。 （例如，如果您不将 "b" 标志传递给 fopen()，许多 Windows 系统对 \r\n 执行类似的操作。）不过，Mac OS 工具箱中肯定没有类似的东西。

Answer 2

我进行了搜索，发现 this page 有一个旧的讨论，特别是可以找到以下内容：

Metrowerks MacOS 实现更进了一步 反转 CR 和 LF 的重要性 '\r' 和 '\n' 在涉及文件的 i/o 中转义，但不是 在任何其他情况下。这意味着如果您打开 FILE 或 fstream 在文本模式下，每个 '\r' 将在那里输出为 一个 LF 以及每个 '\n' 都作为 CR 输出，并且相同 输入为真 - 转义到 ASCII 二进制对应 被逆转。但是在记忆中它们并没有反转，例如 使用 sprintf() 到缓冲区或使用 std::stringstream。 我觉得这很混乱，如果不是非标准的话，至少 比其他实现更糟糕。

事实证明，MSL 有一个解决方法 - 如果您打开 二进制模式下的文件然后 '\n' 总是 == LF 和 '\r' 总是 == CR。这就是我想要的，但在得到 这个信息我也得到了很多理由 那边的人说这是获得的“标准”方式 我想要什么，当我觉得这更像是一种解决方法 对于他们的实现中的错误。毕竟 CR 和 LF 是 7 位 ASCII 值，我希望能够使用 以文本模式打开文件的标准方式。

（答案清楚地表明这确实不违反标准。）

显然，至少有一个实现使用\n和\r和通常的ASCII值，但将它们转换为（非二进制）文件输出（通过交换它们） .

Answer 3

在较旧的 Mac 编译器上，\r 和 \n 的角色颠倒了：我们有 '\n' == 13 和 '\r' == 10，而今天 '\n' == 10 和 '\r ' == 13. 在过渡阶段非常有趣。使用旧编译器将 '\n' 写入文件，使用新编译器读取文件，并获得 '\r' （当然，这两次你实际上都有一个数字 13）。

Answer 4

C 语言规范：

5.2.2
...
2 表示执行字符集中非图形字符的字母转义序列旨在在显示设备上产生如下操作：
...
\n（新行）将活动位置移动到下一行的初始位置。
\r (回车) 将活动位置移动到当前行的初始位置。

所以\n 表示该字符编码中的适当字符...在ASCII 中是LF 字符

Answer 5

我没有旧的 Mac 编译器来检查它们是否遵循这个，但 '\n' 的数值应该与 ASCII 换行符相同（假设那些编译器使用 ASCII 兼容编码作为执行编码，我相信他们做到了）。 '\r' 应该与 ASCII 回车具有相同的数值。

处理写入文本模式文件的库或操作系统函数负责将'\n' 的数值转换为操作系统用来终止行的任何值。这些字符在运行时的数值完全由执行字符集决定。

因此，由于我们仍然是 ASCII 兼容的执行编码，因此数值应该与经典 Mac 编译器相同。