綜合演習 — 推理亂碼的成因

日文平假名的 UTF-8 位元組序列以 E3 81 / E3 82 / E3 83 開頭，把這 2 個位元組用 Shift_JIS 的表去查，分別會得到「縺」「繧」「繝」。所以把 UTF-8 的日文當成 Shift_JIS 誤讀時，這 3 個字會以異常的頻率出現，多出來的位元組看起來就是半形片假名（ｫ、ｯ 等）。反方向（把 Shift_JIS 當成 UTF-8 讀）如下一題所示會滿是替換字元，因此光看亂法的外觀就能連方向一起確定。

「テスト」的 Shift_JIS 是 83 65 83 58 83 67。當成 UTF-8 讀時，0x83 是長得像「後續位元組」的孤立位元組，屬於非法而被替換成 �（U+FFFD）。另一方面，第 2 位元組的 65（e）、58（X）、67（g）落在 ASCII 範圍所以原樣倖存 — 第 4 章學過的「Shift_JIS 的第 2 位元組侵入 ASCII 區域」在這裡成了指紋。「� 連發 + 英文字母碎片」是把 Shift_JIS 系當成 UTF-8 讀的信號。

日文的 UTF-8 是 1 個字元 3 個位元組，開頭位元組幾乎都在 E3〜E9。在 Latin-1 系的表中，E3 對應 ã、E5 對應 å、E6 對應 æ，於是出現「每 3 個字元冒出一個 ã 之類的字母、字元數膨脹約 3 倍」的指紋（中間有些位元組會變成看不見的控制碼）。因為是用 1 位元組 = 1 字元的表在讀，不容易出現替換字元 — 這是與 q2 模式的分辨點。這是無視或遺失 charset 宣告的國外工具、郵件軟體的經典亂法。

從「縺」的指紋可以推理出 UTF-8 被 Shift_JIS（CP932）系讀取，這與雙擊開啟的 Excel 的預設行為相符。在沒有宣告機制的 CSV 中，BOM（EF BB BF）是少數「可以埋進實體的標籤」，加上它是定石（第 6 章）。此外，這種情況下檔案的實體毫髮無傷，使用者端也可以改用匯入功能明確指定 UTF-8 來正確讀取。

誤讀（縺薙ｓ型）的位元組序列毫髮無傷所以可逆；替換成 ? 則是轉換處理把「表示不了的字元」改寫成 ? 這另一個字元後存檔的結果，不可逆。像 ① 或 髙 這類 CP932 的機種相依字元被丟進嚴格的轉換時就會發生（第 4 章）。處置也不同：誤讀就重新讀取，替換則需要從遷移來源的資料重新投入。能分清「亂碼」與「替換」，直接關係到能否復原的判斷。

郵件的標頭在歷史上只允許 ASCII，所以非 ASCII 的主旨要包成「=?編碼名?B?Base64 資料?=」這種 MIME 編碼來傳送。主旨與內文的編碼宣告位置不同，只有一邊亂掉反而是很自然的症狀。接收端無法解讀 MIME、宣告與實體錯位、途中的系統弄壞了標頭等是典型原因 — 這是「宣告與實體」的思考方式（第 6 章）以標頭為單位適用的例子。

「只有含特定字元的列會壞」正是第 4 章地雷字元的指紋。「ソ」（83 5C）的第 2 位元組與反斜線同值，以位元組為單位做跳脫處理的程式會把字元的中間誤認成符號。對策是改用能正確認識 Shift_JIS 的函式庫處理、把交接改成 UTF-8 等「正確處理字元分界」的方向。既不是片假名本身有錯，也不是溢位。

這是課程的總整理。宣告只是標籤（第 6 章），實體的位元組序列要經過轉換處理才會改變。所謂轉換，就是「用 EUC-JP 的表讀取、還原成碼位（號碼），再用 UTF-8 的規則重編成位元組序列」— 一趟經由 2 個階段（第 1 章）的搬家。不是亂掉後再修，而是在跨越邊界之前正確轉換 — 讓「寫入的編碼」與「讀取的編碼」持續一致，就是字元編碼實務的全部。