如果我這樣做的命令行我的Mac（UTF-8的終端，因此該文件）：可打印字符VS Linux的
tr -cd '[:print:]\n' <infile> outfile
我得到不同的結果比我OUTFILE在Linux系統上運行相同的命令（UTF-8在終端中，文件也是如此）。
這可能是什麼原因？
這是在Mac上運行該命令時仍存在的示例字符： š （該字符是帶caron的擴展ASCII字符0x9A/s）。 在Linux上運行命令時將刪除相同的字符。
不幸的是，卡羅爾C已在tr源圖所示，它不支持Unicode可言，所以對於一個UTF-8的文件在Linux上的行爲只是不會，如果該文件包含任何多字節工作序列。
根據this database，U + 009A字符是控制字符而不是可打印字符。該角色的名字是「單字符介紹人」。看起來，該頁面上呈現的字形在視覺上與您提供的描述相匹配，但這不是它在Linux上的顯示方式。然而，還有另一個角色是「與一個caron」。 Unicode可能很複雜。
According to Wikipedia，對於小寫字母「s（s with caron）」字符實際上是U + 0161，對於大寫字母是U + 0160。
這也與此數據庫對齊：
你確定UTF-8與UTF-16有關嗎？ – bmargulies 2014-11-21 23:37:15
@bmargulies我的答案根本不討論字符的編碼。我只是在談論codepoints，所以我不確定你在問什麼。 – b4hand 2014-11-21 23:39:00
如果剩下的字符是U + 009A，那麼Linux不正確。該命令應該刪除可打印的字符並留下不可打印的字符。 U + 009A是不可打印的，所以它應該留在輸出中。 OP說，Linux正在消除這個特性，OS X正在離開它。如果剩下的字符是U + 0161，那麼Linux是正確的，並且OS X不正確。 – 2014-11-21 23:59:03
如果剩餘的字節是0x9A執行，該文件是不正確的UTF-8，也不是工具，你使用查看它（0x9A是在例如Windows codepage 1252），也不明顯你的tr。
要正確解決您的問題，我們需要查看文件中實際字節的一個片段。例如，顯示爲åäö一個文件可能包含字節
0xE5 0xE4 0xF6
，如果它在ISO-8859-1或
0xC3 0xA5 0xC3 0xA4 0xC3 0xB6
（與CP1252在這些位置，其重合），如果它是正確的UTF-8。在OSX，舊文件也可以振振有詞在Mac Roman這將這個編碼字符串作爲
0x8C 0x81 0x9A
以及，當然，大量其他的編碼，根據文件的出處。
另請參閱https://rawgit.com/tripleee/8bit/master/encodings.html#0x9a – tripleee 2014-11-26 12:18:30
你的文件本身是否包含一個「0x9A」字節，或者它是否有一個「0xC2」後跟一個「0x9A」？正確編碼的UTF-8流應具有「\ xC2 \ x9A」。 – b4hand 2014-11-21 23:17:11
推測這兩個系統有不同的Unicode字符類型數據庫，可能是由於錯誤或由於基於Unicode標準的不同版本。 – 2014-11-21 23:19:34
@ b4hand，我的系統說''是帶有CARON U + 0161的LATIN小字母S，它是UTF-8中的0xC5 0xA1。彼得，沒有任何東西被稱爲「擴展ASCII」。我懷疑你是指ISO 8859-1，但當然這與UTF-8不同。 – 2014-11-21 23:27:13