国外程序员也烫屯锟斤拷吗？

（2019-07-20 更新「朹方」，見底部）

經常跟亂碼打交道的路過。。。

簡單答案：全世界都有類似的情況，但看到的和我們可能不一樣。

具體來說嘛～
首先，「烫烫屯屯」和「锟斤拷」是兩個不同的問題，但都和 GBK 編碼相關。
另外還有人提到「許蓋功」、「变巨」、「林技夸」、「朹方」什麼的，下面分別來談～

一、「烫烫屯屯」

這是 Visual Studio 在調試模式下編譯的 C/C++ 程序中可能遇到的東西。源自 VC++ 編譯器在調試模式下會將未初始化的內存空間用 0xCC 和 0xCD 填充。但由於 Windows 控制台在不同語言下會用不同的編碼，不同語言下效果會不一樣。

比如同樣是「八個 0xCC 字節」和「八個 0xCD 字節」：

• 簡體中文 Windows 採用 CP 936 編碼（即 GBK），"\xCC\xCC" 為「烫」、"\xCD\xCD"為「屯」，因此顯示「烫烫烫烫」和「屯屯屯屯」。
• 英文 Windows 採用 CP 437 編碼（又稱 IBM 437）："\xCC"為「╠」、"\xCD" 為「═」，因此顯示「╠╠╠╠╠╠╠╠」和「════════」。
  
• 繁體中文 WIndows 採用 CP 950 編碼（即 Big5）："\xCC\xCC" 為「昍」、"\xCD\xCD"為「迋」，因此會顯示「昍昍昍昍」和「迋迋迋迋」。
  
• 日文 Windows 採用 CP 932 編碼（即 Shift-JIS）："\xCC"為「ﾌ」、"\xCD" 為「ﾍ」，因此顯示「ﾌﾌﾌﾌﾌﾌﾌﾌ」和「ﾍﾍﾍﾍﾍﾍﾍﾍ」。

其他語言下基本會被直接當成普通亂碼或普通 bug 了……（要怪就只能怪 GBK 的這兩個碼位恰好都是常用字了吧2333）

二、「锟斤拷」

如果數據來自網絡自動收集處理的話經常會有程序將編碼判斷錯的問題。所以搜索引擎的網頁資料是重災區。

「锟斤拷」是在 GBK 和 UTF-8 編碼的兩種數據混用時會發生的現象。

要產生「锟斤拷」這個串，需要幾個步驟——

1. 把一段字節序列用錯誤的編碼轉成 Unicode 字符序列（一般用字符串來製作索引），並使用 Unicode 指定的替代用字符「U+FFFD」替代所有轉換失敗的字符。
2. 將這段字符序列以 UTF-8 編碼儲存為字節序列（字符串需要採用一個統一的內部編碼來保存，一般用 Unicode 的某種編碼），連續的兩個「U+FFFD」會表示為 "\xEF\xBF\xBD\xEF\xBF\xBD"。
3. 再將這段字節序列錯誤地以 GBK 編碼呈現為字符序列（程序 bug，把內部數據編碼搞混了），即出現「锟斤拷」。

如果把上面的 GBK 換成 Big5，出現的會是「嚙踝蕭」。
換成 IBM 437，出現的會是「∩┐╜∩┐╜」。
Shift-JIS 下是不合法編碼，會變成什麼樣（或者能不能出現這個 bug）就不一定了。

所以其他語言下估計也會直接被當成普通亂碼什麼的……（大概還是得怪 GBK 這三個碼位不僅兩個是常用字而且三個字之間還有奇妙的意義關聯了吧2333）

三、「許蓋功」

這是由於 Big-5 碼一些字符的第二字節跟 ASCII 下大量字符重疊，而某些字符在 Unix 命令行、程序代碼中可能有特殊作用，往往導致字符串被不正確地解釋。這只會發生在 Big-5 環境下。這就是 Big-5 的設計缺陷了。。

其實 GBK 下偶爾也有類似的情況，比如某些用 GBK 編碼處理 LRC 歌詞的播放器。由於 GBK 某些字第二字節 0x5B 與 LRC 標籤起始字符「[」重疊，如果直接用按字節來找起始字符的話會導致這些不幸的字與它後面的文本全被當成標籤。。而且這一般會在日文歌詞中發生，簡體中文一般遇不到所以還不太有開發者關注……當然如今普遍是內部統一用 Unicode 字符處理，只要能正確識別文件編碼就不太有這種問題了。

附：「变巨」「林技夸」

這是在簡體中文系統運行為其他語言系統開發的程序時，由於程序內的文本並未使用相符的編碼，也未使用 Unicode 於是編碼錯亂所致。

「曹操」用 Big5 編碼成字節序列後，再被誤當成 GBK 轉為字符得到的即是「变巨」。
類似的還有「三國志曹操傳」變成「 ?T瓣в变巨肚」。第一個字節在 GBK 中是不合法編碼，在 Windows 上呈現時會變成問號或直接忽略，現今 Unix 諸系統一般會用 U+FFFD 顯示。（另外注意那個「в」是西里爾字母小寫 ve，不是 B）
此外還有反過來的情況，比如在內嵌字型的 Big5 遊戲中，字符「曹操」被系統用 GBK 字節序列表示，但會被內嵌的字型當成 Big5 而顯示成字符「羚紱」。

而「주세요」（韓文常見的句尾）用 CP 949 編碼（即 KSC5601 編碼），再被誤作 GBK 轉為字符得到的即是「林技夸」。

2019-07-20 再附：「東方」→「朹方」

這個也算是上面「許蓋功」的 GBK 版了。它主要出現在 Windows 一些經過解包或網絡傳輸之類的文件名中，「東方」會莫名變成「朹方」。原因是「東」的 GBK 表示為 "\x96\x7C"，其中第二字節 0x7C 恰與 ASCII 的 "|" (U+007C) 相同，於是一些只會按字節處理文件名的軟件，會誤以為它是 Windows 文件名禁止出現的字符 "|"，就將其替換為下劃線 "_" (U+005F)，即換成字節 0x5F，於是「東」"\x96\x7C" 就變成了「朹」"\x96\x5f"。

国外当然也有乱码问题。

这大约是2002年的故事了。大意是一个法国人给俄罗斯人寄东西，收件地址是俄文，西里尔字母在俄罗斯用KOI8-R编码，而欧洲用ISO-8859-1字符集，于是就变成一堆变音字母。法国这位老兄也不核实一下就硬抄上去。包裹到达俄罗斯后，邮递员并没有退件，而是手动查字符集，用红笔写下正确字符，并完成投递。

日本的朋友也遇到了同样的问题。如果你是俄罗斯邮递员，请发挥爱岗敬业的精神，帮助他找出正确的收件地址。

公布答案：俄罗斯叶卡捷琳堡