scanf函数中\n格式说明符的行为及Windows文本文件适配问题

一、scanf对格式串中第二个'\n'的处理 #

• %[^\n]是扫描集格式说明符，它会匹配并读取所有非'\n'的字符，直到遇到第一个'\n'为止，将读取到的字符存入目标数组arr。注意：这个'\n'会留在输入缓冲区中，不会被读取到arr里。
• 格式串末尾的\n属于空白字符格式符。scanf处理空白字符时，会自动跳过输入缓冲区中所有连续的空白字符（包括'\n'、'\r'、空格、制表符等），直到遇到第一个非空白字符，或者到达输入流末尾才停止。也就是说，这个\n不是要求精确匹配一个换行符，而是让scanf清理当前行之后的所有空白内容，直到下一个有效输入出现。

二、在Windows文本文件中无法正常工作的原因 #

Windows和类Unix系统的文本文件换行符存在本质差异：

• 类Unix系统（Linux、macOS等）使用单个\n（ASCII码0x0A）表示换行。
• Windows文本文件使用\r\n（ASCII码0x0D + 0x0A，即回车+换行）作为换行标记。

结合scanf的行为，问题出在两个环节：

1. 扫描集读取到多余的'\r'：如果程序以二进制模式读取Windows文本文件，文件中的\r\n会被原封不动读入输入缓冲区。此时%[^\n]会把'\r'当作有效字符（因为'\r'不是'\n'）存入arr末尾。这个'\r'是不可见字符，后续用printf输出arr时，'\r'会让光标跳转到行首，导致后续输出覆盖前面内容，看起来像是输出异常。
2. 文本模式下的隐式转换干扰：如果程序以文本模式读取Windows文本文件，C标准库会自动将\r\n转换为单个\n，此时%[^\n]能正常读取一行内容，但格式串末尾的\n会让scanf跳过转换后的'\n'。如果文件末尾是换行符，scanf会一直等待输入（因为它在跳过空白，直到遇到非空白字符），导致程序卡住。

另外，从Windows键盘输入时按下回车键，会向输入缓冲区写入\r\n，此时%[^\n]也会读取到'\r'并存入arr，引发类似的输出异常，这和文本文件的问题本质一致。

内容的提问来源于stack exchange，提问作者Dandys