unix 与 mac 上 sed 和 nl 之间的行输入/计数差异答案

【问题标题】：Line entry/count difference between sed and nl on unix vs. macunix 与 mac 上 sed 和 nl 之间的行输入/计数差异
【发布时间】：2013-12-10 23:49:33
【问题描述】：

我有一个简单而烦人的问题，对于没有发布示例，我深表歉意。这些文件很大，我无法使用较小的文件重新创建确切的问题：

这些是制表符分隔的文件（一些条目包含"; 或单个空格字符）。在 UNIX 上，当我通过 nl file | sed -n '/word/p' 访问一个唯一词时，我看到我的词在我所有文件中的同一行上。

现在我将文件复制到我的 mac。我在相同的确切文件上运行相同的命令，但行号都不同！通过wc -l 获得的总行数仍然与我在unix 中获得的数字相同，但是当我执行nl file | tail -n1 时，我看到的数字不同。然而，当我输入从我的 unix nl 返回的数字，并通过 sed '12345p' file 访问同一行时，我得到了正确的输入！？

我的问题：我的某些行中一定有一些东西在我的 mac 上被解释为换行符，但在 unix 中却没有，而且只有 nl 而不是 sed。谁能帮我弄清楚它是什么？我已经知道它不是在每条线上。当我将数据加载到R 时，我发现这个问题仍然存在，我很困惑。谢谢！

【问题讨论】：

您是如何复制文件的？副本是否翻译了行尾，或者它们在 Unix 和 Mac 上是否逐字节相同？
我使用 scp 复制了它们。我以前从未注意到 unix 文件和 mac 文件之间的区别。
是的，它们是相同的，字节对字节：
17e4759590d804ecb5c44b17982939ae (unix md5sum)
确实很奇怪。将每个系统上的 nl 输出重定向到一个单独的文本文件，并将它们与comm -3 nl_unix.txt nl_mac.txt | head -1 进行比较，以查看错误开始的位置。（比我上面的二进制搜索建议更容易）

标签： r macos unix sed newline

【解决方案1】：

“幻象换行符”可以以称为"overlong sequence" 的多字节UTF-8 字符的形式隐藏在文本中。

UTF-8 通常将 ASCII 字符表示为自身：0 到 127 范围内的 UTF-8 字节就是那些字符值。但是，超长序列可用于（错误地）使用多个 UTF-8 字节（范围为 0x80-0xFF）对 ASCII 字符进行编码。正确编写的 UTF-8 解码器必须检测过长的序列并以某种方式将它们标记为无效字节。一个简单编写的 UTF-8 解码器将简单地提取隐含的字符。

因此，您的数据可能被视为 UTF-8，并且包含一些看起来像是换行符的超长序列的字节，这会欺骗您正在使用的某些软件。换行符的两字节超长序列看起来像C0 8A，而三字节超长序列看起来像E0 80 8A。

很难提出不涉及字符编码的替代假设。

【讨论】：

谢谢你，Kaz - 我必须调查一下。我最终重写了我的脚本，但没有遇到同样的问题。我看看能不能把旧文件挖出来。