为什么换行符会出现多种形式？
在日常编程中，我们经常使用\n来表示换行。但有些时候，你可能会遇到\r，甚至是\r\n的组合。为什么一个看似简单的"换行"操作会有这么多不同的表示方法？这背后隐藏着一段有趣的计算机发展史，也导致了现代编程中许多令人头疼的兼容性问题。
“回车”和“换行”的本意和演变
要理解这些符号，我们需要回溯到打字机时代：
回车（Carriage Return，简称CR，\r）： 本意是打字机的打印头回到行首。在使用机械打字机时，当一行文字打完，需要将打字头移回本行的起始位置，以便开始新的一行输入。这个操作就被称为 “回车”，对应的 ASCII 码值为 13（0x0D）。在早期的计算机系统中，如 Teletype Model 33 ASR 终端，回车符被用来控制打印机或终端设备的打印头回到一行的开头。
换行（Line Feed，简称LF，\n）： 它的作用是将纸张向上推进一行，使打字位置移到下一行。在 ASCII 编码中，换行符的码值为 10（0x0A）。在计算机系统中，换行符用于表示文本行的结束，指示程序将后续的文本输出到下一行。
在机械打字机上，这是两个独立的操作：你需要先移动打印头到行首(回车)，然后转动滚筒使纸张上移一行(换行)。后来计算机出现后，这两个符号被保留，但不同系统却赋予了它们不同的含义：
Unix/Linux 系统：使用单独的换行符 LF (\n)，继承自Multics系统
早期的苹果系统（Classic Mac OS）：使用单独的回车符 CR (\r)。但从Mac OS X 开始，苹果公司采用了基于 Unix 的内核，新版的 macOS 系统和 Unix、Linux 系统一样，使用 LF（Line Feed）也就是 “\n” 作为换行符。
Windows/DOS系统：使用回车加换行 CRLF (\r\n)，继承自CP/M，而CP/M是为了兼容电传打字机
这些差异，正是今天多种回车换行符共存的历史原因。
如何处理回车换行符？
不同编程语言和平台，对换行符的处理也略有不同。大多数语言读和写文件会区分文本模式和二进制模式，文本模式下，无论原格式是什么，总会在读入内存时转化为单字符\n，而在输出时将回车转化为当前平台格式。二进制模式则不进行处理。
# Python会自动将不同平台的换行符统一转换为\n
with open('file.txt', 'r') as f:
content = f.read() # 所有换行符会被转换为\n
// JavaScript也是如此
const fs = require('fs');
const content = fs.readFileSync('file.txt', 'utf8'); // 统一为\n
# Python写入时会根据平台自动转换
with open('file.txt', 'w') as f:
f.write('Hello\nWorld') # Windows上会写入\r\n
有些语言如Java提供 System.lineSeparator() 来获得平台相关的换行符。
在C/C++中，标准输入stdin默认以“文本模式”打开。特别是在 Windows 平台上，这意味着从控制台输入的\r\n（即用户按下回车键产生的字符）会被自动转换为单一的\n。因此，如果你使用如getchar()、scanf()或cin等常规输入函数，通常只会读取到一个\n，不会看到\r。
然而，如果你将标准输入显式以二进制模式打开，例如：
freopen(NULL, "rb", stdin);
则输入的\r\n将不会被转换，程序将会依次读取到两个字符：\r (13) 和 \n (10)。这对需要精确处理输入字节的程序员非常重要。
#include
int main() {
// 切换到二进制模式：注释此行查看默认文本模式效果
// freopen(NULL, "rb", stdin);
int c1 = getchar();
int c2 = getchar();
printf("c1 = %d, c2 = %d\n", c1, c2);
return 0;
}
在 Windows 下运行这段代码后，输入 a + 回车，你会看到：
文本模式下：c1 = 97, c2 = 10
二进制模式下：c1 = 97, c2 = 13（下一次调用会读到10）
最佳实践
跨平台开发时，尽量使用\n作为内部统一标准，输出到文件时再根据目标系统进行转换。使用Git等版本管理工具时，要注意设置换行符策略（如.gitattributes）来避免跨平台协作的麻烦。使用跨平台脚本建议使用专用的文本编辑器（如VSCode、Sublime）设置统一的换行符。