提議 OpenJDK 的程式碼 UTF-8 化

Hacker News 上看到提議把 OpenJDK 的程式碼 UTF-8 化:「Make JDK source code UTF-8 (openjdk.org)」,原始的 jira ticket 在「Make JDK source code UTF-8」這邊。

主要是現在的 source code 沒有統一標準:

Currently, the source code in the JDK is in an ill-defined encoding. There is no official declaration of the encoding used. It is "mostly ASCII", but the relatively few non-ASCII characters used are not well-defined. In many cases, it is latin-1, but I am pretty certain other encodings are used for e.g. Asian translations.

而 mailing list 上看起來還是有想要維持 ASCII 的討論:「Making the source code utf-8」,不過他提出來的理由我覺得不太行,在 console 跑 vi 或是 emacs 我覺得不太是個好理由...

關於 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 格式的比較。