一位客户向我发送了一个 .csv 文件，其中的换行符由序列 0xD 0xD 0xA 组成。据我所知，换行符是来自 Mac 或 Unix 的 0xA 或来自 Windows 的 0xD 0xA。
0xD 0xD 0xA 是否有任何已知的编码？是否有任何已知的节省顺序会破坏导致此问题的文件行尾（我认为客户使用的是 Mac）？
文件不以任何编码标记开头，它直接以文本内容开头。如果使用代码页 1252 打开，文本将正确显示。
【问题讨论】：
标签： character-encoding file-format
CRCRLF 被称为 Windows XP notepad word wrap bug 的结果。
为了将来参考，以下是链接博客的相关性摘录：
当您在 Windows 计算机上按 Enter 键时，实际上会存储两个字符：回车符 (CR) 和换行符 (LF)。操作系统总是以与 Enter 键相同的方式解释字符序列 CR LF：它移动到下一行。但是，当它们本身有额外的 CR 或 LF 字符时，这有时会导致问题。
Windows XP 版本的记事本中存在一个错误，可能会导致显示窗口中存储额外的 CR 字符。该错误发生在以下情况：
如果您打开了自动换行选项并且显示窗口包含环绕的长行，则保存文件会导致记事本在显示窗口的每个换行点插入字符 CR CR LF，但不会在保存的文件。
如果您将 CR CR LF 字符复制并粘贴到其他程序中，它们可能会导致异常。如果您调整记事本窗口的大小，它们还会阻止记事本正确地重新换行。
您可以通过关闭自动换行功能来删除 CR CR LF 字符，然后在需要时将其重新打开。但是，当您执行此操作时，光标会重新定位在显示窗口的开头。
【讨论】：
Netscape ANSI 编码文件使用 0D 0D 0A 作为换行符。
【讨论】：
众所周知，Apple 邮件会在出站的文本和 csv 附件上产生编码错误。本质上，它用每行上的软换行符替换行终止符，在编码中看起来像 =0D。如果附件通过电子邮件发送到 Outlook，Outlook 会看到软换行符，删除 =，然后附加真正的换行符，即 0D0A，因此您在每行的末尾得到 0D0D0A (cr cr lf)。如果它是 mac 格式文件（或任何其他风格的 unix），则编码应该是 =0D=；如果它是 windows 格式文件，则编码应该是 =0D0A=。
如果您是从 Apple Mail 发送电子邮件（至少在 Mavericks 或 yosemite 中），使附件不是文本或 csv 文件是可接受的解决方法，例如压缩它。
如果您在并行下运行 Windows 虚拟机并使用苹果邮件从那里通过电子邮件发送 txt 文件，则该错误也存在。它是电子邮件编码。在这里形成以前的 cmets，看起来 netscape 也有同样的问题。
【讨论】：
这通常源于版本控制系统或类似系统中的错误。这是 CVS 的产品，如果文件从 Windows 签入到 Unix 服务器，然后再次签出...
也就是说，它只是坏掉了……
【讨论】：
0D 0A 转换为0D 0D 0A（为什么TCVS 在将0A 扩展为0D 0A 时不尊重现有的0D 0A？！）我最终在Eclipse 中使用了双行距，我厌倦了清理向上。通过在签出时选择“使用 UNIX 行结尾”选项修复了该问题。
只是说，这也是从php返回的值（种类...）：
<?php var_dump(urlencode(PHP_EOL)); ?>
// Prints: string '%0D%0A' (length=6)-- used in 5.4.24 at least
【讨论】：
我在 Solidworks 3D CAD 程序生成的文本文件中看到了这一点。例如，如果您将模型的方程导出到文本文件（默认名称为 equations.txt），则行尾使用 0x0D 0x0D 0x0A。
我确定这是一个错误，但它就是这样。
这些文件（至少是 2019 版软件生成的文件）包括
<0xEF, 0xBB, 0xBF> UTF-8 表示的字节顺序标记作为文件开头的前导编码标记。
【讨论】：