關於 Non-null string 的處理...

上一篇「Filter Input & Escape Output...」有提到 Non-null UTF-8 string 的 filter,結果剛剛洗澡的時候想了想,好像寫錯了?

問題在於「到底是先 de-null 再 iconv(),還是先 iconv() 再 de-null」的問題。

這個問題其實跟 iconv() 成 UTF-8 時遇到不合法字元時怎麼實做有關,也就是 undefined behavior... 由於 \0 是合法的 UTF-8 character,所以我們假設某一種實做是當 iconv() 遇到不合法字元時會用 \0 帶進去:

先 de-null 再 iconv()

這是上一篇文章提到的方法。但在上面提到的 iconv() 實做下卻是有問題的方法。原因很簡單,de-null 後沒有 \0 的字串,卻會因為 iconv() 而產生 \0

先 iconv() 再 de-null

這邊要考慮的是最後 de-null 後會不會變成 invalid UTF-8 string。答案是不可能,因為 iconv() 轉出來後保證是 UTF-8 string (不論如何處理非 UTF-8 character 的部份),而 UTF-8 string 內的 \0 一定可以當 separator,所以切下去一定還是 UTF-8 string。(可以參考下圖關於 UTF-8 character 的規則)

所以?

可能以現在的 iconv() 實做來說,兩者都不會有問題,但寫程式的時候總是要避免 side-effect,所以後者的方法會比前者好。

非常經典的 UTF-8...

Hacker News 文摘上看到「UTF-8 – “The most elegant hack”」這篇。除了維基百科上的資料以外,Rob Pike 與其他人在 2003 年寫的 mail 也是相當重要的資料。

Ken Thompson 與 Rob Pike 兩位發展出來的 UTF-8 被譽為最優雅的 hack 真的一點都不為過。Unicode 1.0 在 1991 年 10 月公佈。之後就陸陸續續有表示的格式出來...

相容於 ASCII 0-127 的 UTF-1 在 1992 年被提出來,但 parsing performance 並不好。

1992 年 7 月,Dave Prosser 提出 FSS-UTF,很類似後來的 UTF-8 但缺乏 self-synchronizing 特性 (這個特性指的是,從字串中間可以很容易找到切割點)。

1992 年 8 月,Ken Thompson 改善了 FSS-UTF,讓 bit 使用效率低一點,但因此擁有 self-synchronizing 特性。之後在 1992 年 9 月,Rob Pike 與 Ken Thompson 將 UTF-8 實做到 Plan 9 上。而 UTF-8 正式公開發表則是在 1993 年 1 月的 USENIX 上。

UTF-8 的設計看起來很 hack,但卻有這些優美的特性:

與既有系統的相容性

只包含 ASCII 0-127 的字串是合法的 UTF-8 字串。

重點是 0 被保留下來,也就是本來的 NULL-terminated 字串處理全部都可以沿用,這使得從 C 語言的 strcpy(),到一堆網路上已經跑很久的通訊協定,都可以繼續沿用。

極高的辨識性

UTF-8 很容易被判斷出來,引用維基百科的數字:

The probability of a random string of bytes which is not pure ASCII being valid UTF-8 is 3.9% for a two-byte sequence, and decreases exponentially for longer sequences.

非 ASCII 字串只要稍微有長度 (四個中文字,12 bytes?),判斷字串是否為 UTF-8 的正確性應該跟各種服務的 SLA 有得拼...

與 Unicode 的順序對應相容

Unicode 的編號順序與 UTF-8 相容,也就是說連傳統的 strcmp() 都可以直接拿來用:

Sorting a set of UTF-8 encoded strings as strings of unsigned bytes yields the same order as sorting the corresponding Unicode strings lexicographically by codepoint.

避開 UTF-16 的 BOM

BOM 的 0xFE 與 0xFF 在合法 UTF-8 文件裡是看不到的,所以如果開頭有看到 BOM 時一定不是 UTF-8:

The bytes 0xFE and 0xFF do not appear, so a valid UTF-8 stream never matches the UTF-16 byte order mark and thus cannot be confused with it.

self-synchronizing 特性

由於 encoding 的特性,UTF-8 字串要找下一個斷點是很容易的:

找到符合這六種開頭的 string pattern 就是斷點。也因為如此,容錯率相當高。

可以容納所有 Unicode 字元

也因為 encoding 特性,UTF-8 理論值可以容納百萬個字元 (依照 RFC3629 的額外限制,是 1112064 個)。在還沒有找到很多外星文明之前,應該都還夠用。(2012 年發佈的 Unicode 6.2 也才十一萬個字元,110182 個字元)

Unicode 與 UTF-8 之間的轉換很方便

再次因為 encoding 特性,轉換幾乎是 bit 運算就可以操作完畢。(注意 Last code point 的值都切齊)

因為太多好處,變成超級標準了...

這是一個幾乎找不到缺點的 standard,所以早期很多 programmer 選擇的原因是「看了就喜歡」,於是就有大量的 library。接下來有大量的 standard (這還包括 XML standard) 直接挑明講 UTF-8 的處理能力是必要條件。

總結...

UTF-8 encoding 怎麼看都很 hack (看起來很隨意的把不同 Unicode 區段切割到不定寬度字集內,感覺不到特別的處理),但卻很完美的解決了「如果可以處理 8bits 時,要與現有系統相容」的問題。也因為這個 encoding 把問題解決得很乾淨 (UTF-8 解決不了的,其他人都解不乾淨),於是就變成超級主流 encodoing...

Google 在 2012 年 2 月時就寫過一篇「Unicode over 60 percent of the web」,這還是扣掉 ASCII 的 20%!

現在是 2013 年快年尾了,可以預期之後是 UTF-8 萬萬歲了...

如果想要了解更細,可以參考維基百科的「Comparison of Unicode encodings」,裡面有與其他 Unicode 格式的比較。

把 screen 的 BIG5 換成 UAO (Unicode-At-On,Unicode 補完計畫) 版本...

目前 Ptt 上使用者用的編碼不是單純的 BIG5,而是 BIG5 加上 Unicode 補完計畫的版本 (拿了 BIG5 的造字區去對應某些常用的缺字)。

如果用 BIG5 去看假名就會變這樣:

所以在 Ubuntu (系統內建的 Terminal) 或是 Mac OS X (用 iTerm2) 上 Ptt (以及 Ptt2) 時都是用 BIG5-HKSCS 編碼,可以顯示日文假名:

不過還是可以看出來漢字不太行,所以還是去找了 UAO 的方案...

第一個想法是直接換掉系統的 BIG5,反正只剩下 BBS 用途要用了,就一次換掉。不過找了半天沒看到現成的工具,雖然在「Mozilla 系列與 Big5 中文字碼」有表可以轉,但還是懶的改...

另外一個是 GNU Screen patch,依照「Screen + Unicode-At-On」這篇的方式,可以生出一個 UTF-8 terminal + converter (GNU Screen),效果就是這樣:

可以看到漢字也出現了... 來找看看要怎麼把 patch 包進 FreeBSD ports 好了...

MySQL 的 Unicode 支援程度

MySQL 5.5 之前的版本只支援 Unicode 3.0 (1999 年 9 月發表),但自從 MySQL 5.5 版開始支援 Unicode 5.0 (2006 年 7 月發表),對於常用的 utf8 encoding 就有一些變化要注意...

參考維基百科上對 Unicode 版本的說明:「Unicode#Versions」,以及 MySQL 5.5 的文件:「MySQL :: MySQL 5.5 Reference Manual :: 10.1.10 Unicode Support」。

在 MySQL 5.5 之前,UTF-8 的設計最多吃 3bytes,因為 1byte 有 128 種組合 (7bits),2bytes 有 2048 種組合 (11bits),3bytes 有 65536 種組合 (16bits),共 67712 個空間可以用,但 Unicode 3.0 只用掉 49259 個。

而從 MySQL 5.5 開始支援的 Unicode 5.0 需要 99089 個空間,所以需要用到 4bytes 的版本,也就是增加 4bytes 的 2097152 種組合 (21bits),共 2164864 個空間。

但為了相容性,MySQL 5.5 的 utf8 encoding 還是使用 Unicode 3.0 版本。只有當特別指定 utf8mb4 encoding 時才會用到 Unicode 5.0 版本。使用 utf8mb4 encoding 時,要注意 client 端也要支援,不然會讀不到東西...

Perl 與 Python 在 Unicode 的處理

我試著在 上找到 Perl Regular Expression 有提供的 General Category Property,不過沒有找到。而且發現 沒有使用

先參考 上的文件, 這篇,在 Regular Expression 裡使用 General Category Property 指的是 \p{Lu} 這種用法,前面的範例表示大寫字母 (Uppercase Letter),我在用 切詞的時候用了兩次這種 Regular Expression。

替代的方案是依照 裡的說法去找對應的範圍,然後自己寫 Regular Expression。

Update 比較清楚,直接把 Hex Start 與 Hex End 列出來。