字符編碼：Unicode、UTF-8 與常見陷阱

電腦本質上只處理數字。字符編碼定義了文字符號如何對應到這些數字。編碼不一致是亂碼、資料損壞與安全問題的常見來源。本文說明現代標準與實務處理方式。

Unicode 與編碼形式

Unicode 為全世界的文字符號分配唯一的碼點（code point）。它本身不是編碼，而是字符集。要把碼點存成位元組，需要編碼形式。最普遍的是 UTF-8：它與 ASCII 相容，英文與數字只佔 1 個位元組，中文等字符通常佔 3 個位元組，具有良好的空間效率與相容性。

其他形式包括 UTF-16 與 UTF-32。Windows 內部與部分系統曾廣泛使用 UTF-16。網頁與多數現代系統預設或推薦 UTF-8。

為什麼會出現亂碼

亂碼通常發生在「用錯誤的編碼解讀位元組」時。例如檔案實際是 UTF-8，卻被當作 Big5 或 Latin-1 打開，中文字就會變成奇怪符號。另一個常見情況是多次錯誤轉換，導致資料永久損壞。

位元組順序記號（BOM）在 UTF-8 中可有可無，但某些舊軟體依賴它判斷編碼。缺少或不當的 BOM 有時也會造成問題。

常見陷阱

• 字串長度：有些語言的「長度」以位元組計，有些以碼點或字素計，處理中文時要特別注意。
• 正規化：同一個視覺字符可能有多種 Unicode 表示（例如預組與組合字符），比較前可能需要正規化。
• 資料庫與連線編碼不一致。
• 檔案在不同作業系統間傳輸時編碼宣告遺失。

與工具的關係

編碼轉換、Base64、URL 編碼等工具都與字符如何變成位元組有關。正確理解編碼可以避免在這些轉換中引入錯誤。文字處理工具應明確使用 Unicode，並在輸入輸出時保留編碼資訊。

Wusper 的文字與編碼工具在瀏覽器環境中運作，現代瀏覽器對 UTF-8 有良好支援。處理大量或特殊字符時，仍建議先確認來源編碼，並在重要資料上測試往返轉換是否無損。

進一步建議

開發時把編碼問題當成一等公民處理：從檔案讀取、資料庫、API 到前端顯示，全程一致使用 UTF-8。遇到亂碼時，先確定原始位元組與預期編碼，再用工具嘗試正確解讀，而不是反覆亂試轉換。