應該已經偏版題很多了, 不過還是提一下我所知的資料
(本文同步轉錄 Programming 版)
: → uranusjr: UTF-8 也只有保證「目前」可以表示所有 Unicode 字元 XD 02/15 20:36
: → uranusjr: 尤其現在的 UTF-8 規範把上限下修到 4 bytes, 總有一天 02/15 20:38
: → uranusjr: 還是會用完, 到時候再看看他們打算怎麼辦 02/15 20:38
: → PkmX: UTF-8 4bytes可以表示到U+10FFFF (17 * 2^16 = 1114112) 02/15 20:50
: → PkmX: Unicode 7.0也才定義113021個codepoints 要用完應該還很久XD 02/15 20:51
: → PkmX: 就算17個planes真的用完 UTF8照規律也可以延伸到使用5 bytes 02/15 20:55
: → frankhsu421: 順帶一提 這code在真的linux上跑會runtime error 02/15 21:09
: → frankhsu421: linux上uintmax_t沒有比wchar_t大 02/15 21:10
: 推 LPH66: UTF-8 下修的原因是 Unicode 本來就定到 U+10FFFF 而已 02/15 21:17
: → LPH66: UTF-8 4byte 其實可以表示到 0x1FFFFF (32*2^16-1=2097151) 02/15 21:18
: → LPH66: 而 Unicode 只定到那裡的原因是 UTF-16 的 surrogate pairs 02/15 21:18
: → LPH66: surrogate pairs 的最後一個組合 U+DBFF U+DFFF 表示的 02/15 21:19
: → LPH66: 就是 U+10FFFF 再上去的話 surrogate pairs 就不夠了 02/15 21:19
: → uranusjr: 那是 UTF-16 的上限, Unicode code point 是無極限的 02/15 21:56
Unicode 最早最早是只有到 U+FFFF 的
(維基百科上有引用 Unicode 創立者之一 Joe Becker 在 1988 年發表的草稿文字
說是他當時認為 2^14 = 16384 個字應該夠用了
因此將 Unicode 定為一個 16-bit 編碼)
後來跟 ISO/IEC 10646 的合流才有把字碼表延伸出去的想法
(ISO/IEC 10646 是訂成一個 31-bit 編碼
它的其中一個表示法 UCS-4 即是用一個 32-bit 整數去裝這個編碼)
也因此到了 1996 年的 2.0 才新增了 surrogate pairs 的機制表示 U+10000 以後的字
而這個 surrogate pairs 的自然上限即是 0x10FFFF
所以要說那是 UTF-16 的上限也沒錯, 因為 Unicode 原本就是個 16-bit 編碼
之所以有"限定"下來一說可能是跟 ISO/IEC 10646 搞混了
因為被限定的其實是這個原本是 31-bit 編碼的 ISO/IEC 10646
因為跟 Unicode 合流的關係才把自己的字碼範圍限在 0x10FFFF 以內
(這個"限制"應該不是明文限制, 只是兩邊的標準組織講好這樣
注意到雖然我上面說合流, 不過那只是共同制定字碼相容的標準而已
Unicode 跟 ISO/IEC 10646 還是兩個標準; Unicode 多了許多字元顯示上的規定)
===
UTF-8 最早當它在一張餐巾紙的背面被寫下來時
它的目標編碼其實是 ISO/IEC 10646, 也就是那個 31-bit 的大編碼
因此在 1993 年初它發表的時候, 一個字最多可以表示成 6 byte
是到了 Unicode 跟 ISO/IEC 10646 合流有了 U+10FFFF 的限制之後
才有了 RFC 3629 這一條 RFC 把 UTF-8 限制在 U+10FFFF 以下
(也就是說, 實際上是因為 ISO/IEC 10646 自我限定字碼才有 RFC 3629 限定 UTF-8
而不是因為 UTF-8 定了限制才讓字碼限定在 U+10FFFF 的
RFC 3629 是 2003 年訂定的, 那時已經是 Unicode 4.0 了)
UTF-8 限定在 4-byte 以內是這個 RFC 的自然結果
而且也不是任意 UTF-8 的 4-byte 順序都是合法的
如我上面推文所說, UTF-8 的 4-byte 最多可以到 0x1FFFFF
RFC 3629 規定這段範圍裡超過 0x10FFFF 的都是不合法編碼
===
所以如果萬一真的用完了要延伸的話
應該會沿著 ISO/IEC 10646 原先定義的方向下去延伸
問題只有 Unicode 這邊要怎麼延伸字碼表示而已
UTF-8 倒是不必擔心, 原先的設計就足夠用到 31-bit
(到時大概會有另一個 RFC 出來說取代 RFC 3629 這樣)
===
至於現在 Unicode 裡定了多少字?
Plane 0 BMP (U+0000~U+FFFF) 雖然還有一點點空位, 基本上可以算是滿了
Plane 1 SMP (U+10000~U+1FFFF) 包含一些古代語言(eg.線型文字)跟哩哩扣扣的符號
大概只用掉這塊的兩成不到
Plane 2 SIP (U+20000~U+2FFFF) 包含古中文字、罕用中文字
這塊使用率目前還不錯, 已經用掉超過七成
很多罕用字大都能在 Ext.B (U+20000~U+2A6DF) 裡面找得到
Plane 3 預計是要留給像甲骨文、金文、小篆之類的字
不過現在 (as of Unicode 7.0) 還是空空的就是了
Plane 4~13 現在還是雜草一片
Plane 14 只有定義了大概百來個控制字元
Plane 15~16 則是更大一塊的 private use area (約有十三萬個字的空間的造字區)
所以其實這一百多萬個字碼要用完個人覺得還很久就是了
而且 Unicode 在定字時其實多少會簡單分析一下到底基本的"字"是什麼
所以字碼並不會太過膨脹 (可以看印度文就知道)
相對的最佔空間的字就是做的沒有這麼徹底的中文字
不過就算這樣, SIP 現在也才填了個七成而已, 要到佔滿所有字碼真的還早