如果我在Mac上的命令行执行此操作（终端中的UTF-8，文件也是如此）：
tr -cd '[:print:]\n' < infile > outfile
我在outfile中获得的结果与在Linux系统上运行相同命令的结果不同（终端中的UTF-8，文件也是如此）。
这可能是什么原因？
这是在Mac上运行命令时仍然存在的示例字符： š （该字符是带有caron的扩展ASCII字符0x9A / s）。 在Linux上运行该命令时，将删除相同的字符。
答案 0 :(得分：1)
如果剩余的字节是0x9A，那么文件不是正确的UTF-8，也不是你用来查看它的工具（例如Windows codepage 1252中的0x9A是š），也不是你的tr。
为了正确解决您的问题，我们需要查看文件中实际字节的片段。例如，显示为åäö的文件可以包含字节
0xE5 0xE4 0xF6
如果它在ISO-8859-1中（与这些位置的CP1252一致）或
0xC3 0xA5 0xC3 0xA4 0xC3 0xB6
如果它是正确的UTF-8。在OSX上，旧文件也可能合理地位于Mac Roman中，该文件将此字符串编码为
0x8C 0x81 0x9A
以及当然还有大量其他编码，具体取决于文件的来源。
答案 1 :(得分：0)
不幸的是，正如Karol C在tr源代码中所示，根本不支持支持Unicode，因此Linux上针对UTF-8文件的行为不会发生如果文件包含任何多字节序列，则工作。
根据this database，U + 009A字符是控制字符，而不是可打印字符。角色的名称是“SINGBLE CHARACTER INTRODUCER”。看起来在该页面上呈现的字形在视觉上与您提供的描述相匹配，但这不是它在Linux上的显示方式。然而，还有另一个角色是“带着卡通”。 Unicode可能很复杂。
According to Wikipedia，“š”（带有caron的）字符实际上是小写的U + 0161和大写的U + 0160.
这也符合这个数据库：