如果我从 Mac 上的命令行执行此操作（终端中的 UTF-8 和文件）：
tr -cd '[:print:]\n' < infile > outfile
我在输出文件中得到的结果与在 Linux 系统上运行相同的命令不同（终端中的 UTF-8 和文件）。
这可能是什么原因？
这是在 Mac 上运行命令时仍然存在的示例字符：š（该字符是扩展的 ASCII 字符 0x9A/s，带有 caron）。在 Linux 上运行该命令时会删除相同的字符。
问问题
380 次
2 回答
1
如果剩余字节为 0x9A，则该文件不是正确的 UTF-8，您用来查看它的工具也不是（0x9A 是 š 在例如Windows 代码页 1252中），显然您的tr.
为了正确解决您的问题，我们需要查看文件中实际字节的片段。例如，显示为的文件åäö可能包含字节
0xE5 0xE4 0xF6
如果它在ISO-8859-1中（在这些位置与 CP1252 一致）或
0xC3 0xA5 0xC3 0xA4 0xC3 0xB6
如果它是正确的 UTF-8。在 OSX 上，一个旧文件也可能在Mac Roman中，它会将这个字符串编码为
0x8C 0x81 0x9A
当然，还有大量其他编码，具体取决于文件的出处。
于 2014-11-22T12:10:06.713 回答
0
Unfortunately, as Karol C has shown below in the tr source, it does not support Unicode at all, so the behavior on Linux for a UTF-8 file is just not going to work if the file contains any multibyte sequences.
According to this database, the U+009A character is a control character and not a printable character. The name of the character is "SINGLE CHARACTER INTRODUCER". It appears that the glyph as rendered on that page visually matches the description that you've provided, but that is not how it is being displayed on Linux. However there is another character that is "s with a caron". Unicode can be complicated.
According to Wikipedia, the "š" (s with caron) character is actually U+0161 for the lower case and U+0160 for the capital.
This also aligns with this database:
于 2014-11-21T23:24:49.203 回答