PALMisLIFE 討論區

搜索
鹹魚爸魅力四射舞蹈教室
查看: 10745|回復: 0

[分享] Zaurus 的 UTF-8 編碼

[複製鏈接]

218

主題

9

好友

3516

積分

我沒有頭銜!

  • TA的每日心情
    開心
    2011-8-12 07:38
  • 簽到天數: 110 天

    連續簽到: 3 天

    [LV.6]常住居民II

    文章
    2679
    發表於 2005-3-16 06:19 |顯示全部樓層
    本文章最後由 mfhsieh 於 2012-1-11 16:54 編輯

    使用 Zaurus 的人大都知道,系統預設的編碼是 UTF-8。不過,Windows 上的 UTF-8 與 Zaurus 上的 UTF-8 雖然大致相同,但卻有小異。

    可以參看 UTF-8 and Unicode FAQ for Unix/Linux 一文中的這一小節 What different encodings are there?,其中有一段:

    In order to allow the automatic detection of the byte order, it has become customary on some platforms (notably Win32) to start every Unicode file with the character U+FEFF (ZERO WIDTH NO-BREAK SPACE), also known as the Byte-Order Mark (BOM). Its byte-swapped equivalent U+FFFE is not a valid Unicode character, therefore it helps to unambiguously distinguish the Bigendian and Littleendian variants of UTF-16 and UTF-32.

    先說明一下什麼是 Byte-Order:在一些平台上,是把代表數值較大的 byte 放在前面,這稱為 Big Endian (BE) 的系統;有些平台則相反,是把代表數值較小的 byte 放在前面,稱為 Little Endian (LE) 的系統。像 Zaurus 是屬於 BE 的系統,而 wintel 架構則屬 LE。若同以 "中" 這個字來看,它的 Unicode 是 U+4E2D,故在 BE 上是以 0x4E 0x2D 來表示,而在 LE 上則以 0x2D 0x4E 來表示。

    在某些平台上 (特別是 Win32 系統),文檔習慣以 U+FEFF 這個字元 (慣稱為 BOM: Byte-Order Mark) 開頭,來辦識該文檔是採 BE 或 LE 的方式編碼。若採 LE 方式編碼,BOM 會表示為 0xFF 0xFE,而在 Unicode 的定義中不存在 U+FFFE 這個字元,所以若前兩個 byte 為 0xFF 0xFE,則一定是 LE 編碼的文檔;反之,若採 BE 方式編碼,BOM 會表示為 0xFE 0xFF,而 U+FEFF 是在 Unicode 中的有效字元,故為 BE 編碼的文檔。又因為 U+FEFF 字元,在 Unicode 中代表的是一個不佔空間的 space 符號,所以即使沒被解釋為 BOM,也不會對閱覽者產生錯誤的訊息。

    換句話說,若某文檔僅有一個 "中" 字。則採 BE 系統,且用了 BOM 字元時,該檔 Unicode 編碼的 binary 內容為:

    0xFE 0xFF 0x4E 0x2D

    採 LE 系統,且用了 BOM 字元時,該檔 Unicode 編碼的 binary 內容為 (wintel 架構下的典型情況):

    0xFF 0xFE 0x2D 0x4E

    但是在 Zaurus 上,習慣上並不用 BOM 字元,而是單純認定文檔採 BE 系統,所以該檔 Unicode 編碼的 binary 內容為:

    0x4E 0x2D

    但是,我們要談的是 UTF-8 編碼,它並不等同於 Unicode。若僅考慮 Unicode 從 U+0000 到 U+FFFF 的範圍,它是以下列的規則轉為 UTF-8 編碼:

    U+0000 - U+007F:0xxxxxxx
    U+0080 - U+07FF:110xxxxx 10xxxxxx
    U+0800 - U+FFFF:1110xxxx 10xxxxxx 10xxxxxx

    一樣以 "中" U+4E2D 為例,因為 0x4E 0x2D = 01001110 00101101,所以它的 UTF-8 編碼為

    11100100 10111000 10101101 = 0xE4 0xB8 0xAD

    同理可得 BOM 字元的 UTF-8 編碼為 0xEF 0xBB 0xBF。又,因為每個字元不見得剛好是 2 個 byte,所以不管是以 LE 或是 BE 為主的系統上,UTF-8 文檔大都採 BE 方式編碼。

    換句話說,若某文檔僅有一個 "中" 字。當用了 BOM 字元時,該檔 UTF-8 編碼的 binary 內容為 (wintel 架構下的典型情況):

    0xEF 0xBB 0xBF 0xE4 0xB8 0xAD

    而在 Zaurus 上,因為不用 BOM 字元,所以該檔 UTF-8 編碼的 binary 內容為:

    0xE4 0xB8 0xAD



    前面所提看來頗為無用,但是在某些情況下,直接從 wintel 平台轉出的 UTF-8 文檔,會無法在 Zaurus 下使用

    因 為 Unix 系統有所謂的 magic word,即是以檔案的前兩個 byte 來辨識該檔的性質。最簡單的例子就是 bash/perl/python 等 script 檔,開頭必定是 "#!"。若在 wintel 平台下轉出 UTF-8 文檔,則前兩個 byte 被 BOM 字元佔用,會導致 shell 無法判讀。

    那該怎麼做比較能確保檔案不會被誤轉呢?我沒什麼好方法,不過只要是從 PC 上轉出的檔案,我必定先在 Zaurus 平台上以編輯器 (我是用 ZEditor) 重新開啟並儲存一次,以確保 BOM 字元不會在檔頭出現。

    另外,雖然 Ultraedit 能夠讀懂 UTF-8 格式的文檔,而且在 menu 上也有把文檔轉為 UTF-8 的功能選項,但它實際上永遠是把 UTF-8 儲存成 Unicode 格式 (我在 Ultraedit v11 上測試多次,不管怎麼選擇,如何轉換,它實際上還是把檔案存成 Unicode 格式)。有興趣者可以下載安裝 WinHex, 直接看 ultraedit 輸出的 UTF-8 文檔,並與 Windows XP 的記事本軟體 (選擇另存新檔,即可選擇檔案格式) 輸出的 UTF-8 文檔比較。不過,因為 ZEditor 也可讀懂 Unicode 文檔,且在 Zaurus 上本來就要重新儲存一次,所以影響也不大。



    註 1:Windows XP 的記事本,處理 Unicode 及 UTF-8 比 Ultraedit 更精準。例如,Big Endian 的 Unicode 文檔,Ultraedit 會無法辨識,但記事本卻能正確解讀。不過,記事本只認 DOS 的換行模式。



    註 2:ZEditor (我用的是日文版) 會自行根據文本轉換內碼系統,在字少的狀況下容易誤判成 Shift JIS 編碼。例如,全文只有一個 "中" 字時。
    您需要登錄後才可以回帖 登錄 | 免費註冊

    與站長聯繫| PALMisLIFE 掌上生活      下載:更快、更棒、更好玩

    GMT+8, 2024-3-29 12:38 , Processed in 0.042834 second(s), 33 queries , Gzip On.

    Powered by Discuz!

    © 2001-2012 Comsenz Inc. style by eisdl

    回頂部