繁體中文WIndows採用CP950編碼(即Big5):"xCCxCC"為「昍」、"xCDxCD"為「迋」,因此會顯示「昍昍昍昍」和「迋迋迋迋」。
日文Windows採用CP932編碼(即Shift-JIS):"xCC"為「フ」、"xCD"為「ヘ」,因此顯示「フフフフフフフフ」和「ヘヘヘヘヘヘヘヘ」。
其他語言下基本會被直接當成普通的亂碼了……(要怪就只能怪GBK的這兩個碼位恰好都是常用字了吧2333)


二、「锟斤拷」

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

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

要產生「锟斤拷」這個串,需要幾個步驟——
把一段字節序列用錯誤的編碼轉成Unicode字符序列(一般用字符串來製作索引),並使用Unicode指定的替代用字符「U+FFFD」替代所有轉換失敗的字符。將這段字符序列以UTF-8編碼儲存為字節序列(字符串需要採用一個統一的內部編碼來保存,一般用Unicode的某種編碼),連續的兩個「U+FFFD」會表示為"xEFxBFxBDxEFxBFxBD"。再將這段字節序列錯誤地以GBK編碼呈現為字符序列(程序bug,把內部數據編碼搞混了),即出現「锟斤拷」。
如果把上面的GBK換成Big5,出現的會是「嚙踝蕭」。
換成IBM437,出現的會是「∩┐╜∩┐╜」。
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而顯示成字符「羚紱」。

而「주세요」(韓文常見的句尾)用CP949編碼(即KSC5601編碼),再被誤作GBK轉為字符得到的即是「林技夸」。"> 繁體中文WIndows採用CP950編碼(即Big5):"xCCxCC"為「昍」、"xCDxCD"為「迋」,因此會顯示「昍昍昍昍」和「迋迋迋迋」。
日文Windows採用CP932編碼(即Shift-JIS):"xCC"為「フ」、"xCD"為「ヘ」,因此顯示「フフフフフフフフ」和「ヘヘヘヘヘヘヘヘ」。
其他語言下基本會被直接當成普通的亂碼了……(要怪就只能怪GBK的這兩個碼位恰好都是常用字了吧2333)


二、「锟斤拷」

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

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

要產生「锟斤拷」這個串,需要幾個步驟——
把一段字節序列用錯誤的編碼轉成Unicode字符序列(一般用字符串來製作索引),並使用Unicode指定的替代用字符「U+FFFD」替代所有轉換失敗的字符。將這段字符序列以UTF-8編碼儲存為字節序列(字符串需要採用一個統一的內部編碼來保存,一般用Unicode的某種編碼),連續的兩個「U+FFFD」會表示為"xEFxBFxBDxEFxBFxBD"。再將這段字節序列錯誤地以GBK編碼呈現為字符序列(程序bug,把內部數據編碼搞混了),即出現「锟斤拷」。
如果把上面的GBK換成Big5,出現的會是「嚙踝蕭」。
換成IBM437,出現的會是「∩┐╜∩┐╜」。
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而顯示成字符「羚紱」。

而「주세요」(韓文常見的句尾)用CP949編碼(即KSC5601編碼),再被誤作GBK轉為字符得到的即是「林技夸」。"/>
养卡提额

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

浏览:258

网友回答

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

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

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

一、「烫烫屯屯」

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

比如同樣是「八個 0xCC 字節」和「八個 0xCD 字節」:
簡體中文 Windows 採用 CP 936 編碼(即 GBK),"xCCxCC" 為「烫」、"xCDxCD"為「屯」,因此顯示「烫烫烫烫」和「屯屯屯屯」。英文 Windows 採用 CP 437 編碼(又稱 IBM 437):"xCC"為「╠」、"xCD" 為「═」,因此顯示「╠╠╠╠╠╠╠╠」和「════════」。
繁體中文 WIndows 採用 CP 950 編碼(即 Big5):"xCCxCC" 為「昍」、"xCDxCD"為「迋」,因此會顯示「昍昍昍昍」和「迋迋迋迋」。
日文 Windows 採用 CP 932 編碼(即 Shift-JIS):"xCC"為「フ」、"xCD" 為「ヘ」,因此顯示「フフフフフフフフ」和「ヘヘヘヘヘヘヘヘ」。
其他語言下基本會被直接當成普通的亂碼了……(要怪就只能怪 GBK 的這兩個碼位恰好都是常用字了吧2333)


二、「锟斤拷」

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

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

要產生「锟斤拷」這個串,需要幾個步驟——
把一段字節序列用錯誤的編碼轉成 Unicode 字符序列(一般用字符串來製作索引),並使用 Unicode 指定的替代用字符「U+FFFD」替代所有轉換失敗的字符。將這段字符序列以 UTF-8 編碼儲存為字節序列(字符串需要採用一個統一的內部編碼來保存,一般用 Unicode 的某種編碼),連續的兩個「U+FFFD」會表示為 "xEFxBFxBDxEFxBFxBD"。再將這段字節序列錯誤地以 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 轉為字符得到的即是「林技夸」。

相关内容

    © YangKaTie.Com All Rights Reserved HTML地图 | xml地图 | txt地图 桂ICP备16002597号-7