一兩個月前某些原因，花了一個禮拜寫了這篇文章，卻遲遲拖稿沒貼出來，正好最近又遇到這類的問題，反正都寫了就把它發出來吧。
網路上有不少關於中日文 Unicode 字集文章，發現很多人對系統顯示字元的規則不了解，但為了看日文，拿著別人藥方開始東添西湊，雖然是不會有什麼問題，只是到頭來根本是治標不治本，換了系統還是會照樣發生，然而自己也是過來人，XP + Unicode 補完計畫 + AppLocal，走到 Win 7 + AppLocal，這一段歷程讓個人體驗很深，在提出看法與最好作法前，先跟各位講解一下系統編碼的原則...
系統編碼
以 Windows 系統來說，構成系統主要的編碼為 ANSI 和 Unicode，在 XP 統領整個家用與商用作業系統前，9X 系列本身是不支援 Unicode，在此之前只有用 ANSI，ANSI 泛指所有以 ASCII 為基準所延伸構成的編碼，而 ASCII 是基於拉丁字母所訂定的一套電腦編碼系統，主要用於顯示現代英語，長度為一個 Byte，定義到 127 為止，這其中有可顯示字元，如 0~9、A~Z、a~z，以及 !@#$%^ 等半型符號，還有一些有作用我們卻看不到的字元，稱為控制字元，換行符號就是其中之一。
ANSI 最多只有 2 Bytes，因此容量有限，不可能全部的字元都裝入，發展的結果就是不同國家使用 ANSI 編碼不同，造成編碼錯誤的原因就在這地方，系統中所使用的 ANSI 編碼和軟體認知不同，不同的表所定義的字元位置皆不相同，就會因為對到錯誤的字元而造成錯誤，在 Big5、GB 下執行日本遊戲就會發生這樣的問題，或是軟體無法對應 ANSI 中的字元，造成路徑不完全而出現錯誤，在 BIG5 系統下，以 ANSI 編寫的軟體開啟含有日文的資料夾或檔案就會出現這樣的錯誤。
Unicode 補完計畫的作用
由於 M$ 在 Windows 使用了轉換表，使得字元會依照需求在 ANSI 和 Unicode 間作轉換，以 Big5 來說，在沒有使用補完計畫的情況下輸入日文到筆記本中，存檔後會出現警告，這是因為系統中的 Unicode 在 Big5 中沒有對應字碼，所以系統提出了警告。而補完計畫在 Big5 補入了日文等中文字，並和系統的 Unicode 做對應，因而在存檔時，在轉換表中找到了對應字元，而不再提出警告。另外，只有 Notepad 會提出警告，使用 M$ 日文輸入法所輸出的字是 Unicode 編碼，這點是從日文部分實驗出來的，但是不是所有 M$ 輸入法皆是如此，個人就不清楚，但另一方面，過去 9X 所用的櫻花輸入法，打出來的字確實是 Big5 編碼，在檔案移轉到不具有補完計畫的系統上會呈現空白～
Unicode 補完計畫的優缺點
補完計畫最大的優點就是使 ANSI 撰寫的程式在 Big5 下能夠正常的讀取日文檔案，在有 Unicode 原生程式出來以前，還能使用以 ANSI 程式作替代，當然這僅限於本身就是用 ANSI Big5 寫的程式，Shift-JIS、GB 等其他的 ANSI 程式，請投靠 AppLocal。然而使用的人往往會忘了自己使用有修改過的編碼，常常直接存了就丟給其他人，這屬於同為 Big5 的小狀況，將檔案拖入 Firefox 等瀏覽器選 Big5 就能顯示，但建議無論有無使用補完計畫，盡量將檔案以 Unicode 或 UTF-8 儲存會比較好。
除了 txt，MP3 的 ID3 也是會用到 ANSI，這種情形就容易見到使用補完計畫的造成缺字。相較之下，由於 XP/Vista/7 的檔案名稱能以 Unicode 或是 ANSI 顯示，所以反倒不易察覺，要到了沒有補完計畫的電腦才有機會遇到。
結論
從以上的結果來看，非得要使用 ANSI 程式時，才會需要用到補完計畫，所以沒有特定需求，建議不要使用補完計畫，盡量使用支援 Unicode 的程式，如：XnView MP、Mp3Tag 等，避免之後還是會發生同樣的事。至於非 Big5 的 ANSI 程式，解決方法就是使用「AppLocal」，或是更改系統語系，有 Unicode 當然是最好的選擇，盡早脫離 「Unicode 補完計畫」的荼毒。
沒有留言:
張貼留言