背景：
在Mac OS 9之前的版本中，文本文件的标准表示使用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之间的转换）;或
1.将'\n'视为ASCII CR字符，它不需要在输入或输出上进行转换。
第二种方法可能会有一些潜在的问题，其中之一是假设'\n'是LF的代码可能会失败。（无论如何，这样的代码本质上是不可移植的。）另一个问题是'\r'仍然需要一个不同的值，在基于ASCII的系统上，CR是唯一合理的值，而且C标准不允许'\n' == '\r'（感谢MAFSO找到引文，5.2.2第3段），因此必须对'\r'使用某个 * 其他 * 值。
当在Mac OS * N * 下编译和执行此C程序时，如果 * 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'的值。（无论它的值是什么）转换为文本流会导致它被转换为系统的行尾表示（在本例中为ASCII CR）;这种行为是C标准所要求的。
5条答案
按热度按时间q43xntqr1#
字符常量
\r和\n的值在Classic Mac OS环境中与在其他环境中完全相同：\r为标准字符集，为ASCII码13（0x0d）;\n是LF是ASCII 10（0x0a）。在Classic Mac OS上唯一不同的是\r被用作文本编辑器中的“标准”行结尾，就像\n在UNIX系统上使用，或者\r\n在DOS和Windows系统上使用一样。下面是一个简单的测试程序的屏幕截图，该程序在MacOS 9上的Metrowerks CodeWarrior中运行：
请记住，经典的Mac OS系统没有一个系统级的标准C库！像
printf()这样的函数只是作为编译器专用库的一部分出现的，比如SIOUX for CodeWarrior，它通过将输出写入一个带有文本字段的窗口来实现C标准I/O。标准文件I/O的一些实现可能已经执行了\r和\n之间的一些自动转换，这可能是您所想的。（例如，如果您不将"b"标志传递给fopen()，许多Windows系统会对\r\n执行类似的操作。）不过，Mac OS Toolbox中肯定没有类似的内容。wnvonmuf2#
我做了一个搜索，发现this page有一个旧的讨论，特别是可以找到以下内容：
Metrowerks MacOS实现更进了一步，在涉及文件的i/o中，而不是在任何其他上下文中，颠倒了CR和LF对于“\r”和“\n”转义的意义。这意味着如果您以文本模式打开FILE或fstream，则每个“\r”将作为LF输出，每个“\n”将作为CR输出。输入也是如此--转义到ASCII二进制的对应关系被颠倒了。但是在内存中它们没有被颠倒，例如，用sprintf（）到缓冲区或用std：：stringstream。我发现这很混乱，如果不是不标准的话，至少比其他实现更糟糕。
原来MSL有一个变通方案-如果你以二进制模式打开文件，那么“\n”总是== LF和“\r”总是== CR。这是我想要的，但在获得这些信息时，我也从那里的人那里得到了很多理由，认为这是获得我想要的东西的“标准”方式，当我觉得这更像是解决实现中的bug时，毕竟CR和LF是7位ASCII值，我希望能够以标准方式使用它们，并以文本模式打开文件。
(An答案表明，这确实 * 不 * 违反标准。）
因此，显然有 * 至少一个 * 实现使用
\n和\r与通常的ASCII值，但将它们转换为（非二进制）文件输出（通过交换它们）。v2g6jxz63#
在较早的Mac编译器上，\r和\n的角色相反：我们有“\n”== 13和“\r”== 10，而今天有“\n”== 10和“\r”== 13。过渡阶段非常有趣。用旧编译器将"\n“写入文件，用新编译器读取该文件，然后得到”\r“（当然，这两次实际上都是数字13）。
brvekthn4#
C语言规范：
五、二、二
...
2表示执行字符集中非图形字符的字母转义序列用于在显示设备上产生如下动作：
...
\n（新行）将活动位置移动到下一行的初始位置。
\r（回车）将活动位置移动到当前行的初始位置。
因此
\n表示该字符编码中的相应字符...在ASCII中为LF字符wh6knrhe5#
我没有一个旧的Mac编译器来检查它们是否遵循这个规则，但是
'\n'的数值应该与ASCII换行符相同（假设那些编译器使用ASCII兼容编码作为执行编码，我相信它们确实这样做了）。'\r'应该与ASCII回车符具有相同的数值。处理写入文本模式文件的库或操作系统函数负责将
'\n'的数值转换为操作系统用来终止行的任何值。运行时这些字符的数值完全由执行字符集决定。因此，由于我们仍然是ASCII兼容的执行编码，数值应该与经典的Mac编译器相同。