Fw: [討論] Unicode (was: [問題] gcc對非英文…

[LPH66 (1597463007)]

※ [本文轉錄自 C_and_CPP 看板 #1KuD_w8l ]

作者: LPH66 (1597463007) 看板: C_and_CPP
標題: [討論] Unicode (was: [問題] gcc對非英文
時間: Mon Feb 16 02:05:42 2015


應該已經偏版題很多了, 不過還是提一下我所知的資料

(本文同步轉錄 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 現在也才填了個七成而已, 要到佔滿所有字碼真的還早

--
  'You've sort of made up for it tonight,' said Harry. 'Getting the
sword. Finishing the Horcrux. Saving my life.'
  'That makes me sound a lot cooler then I was,' Ron mumbled.
  'Stuff like that always sounds cooler then it really was,' said
Harry. 'I've been trying to tell you that for years.'
                               -- Harry Potter and the Deathly Hollows, P.308

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 123.195.39.85
※ 文章網址: https://www.ptt.cc/bbs/C_and_CPP/M.1424023546.A.22F.html

※ 發信站: 批踢踢實業坊(ptt.cc)
※ 轉錄者: LPH66 (123.195.39.85), 02/16/2015 02:06:10
推 AmosYang: 推整理 orz
推 alibuda174: 推整理 讚
推 carylorrk: 記得幾年前光是爲了判定 CJK 就翻了好
→ carylorrk: 久XD
推 abcdefghi: 擔心字碼被用完真的有點杞人憂天, 原始
→ abcdefghi: 的16bit不夠用,就跟10646整合,一樣叫
→ abcdefghi: unicode,未來找到外星人和宇宙接軌,再
→ abcdefghi: 定個64bit/128bit的版本就好了,連
→ abcdefghi: regional indicator symbol都會出現,
→ abcdefghi: 所謂的規格/標準,只是大廠願不願意支持
→ MOONRAKER: 外星人的bit會不會比地球人的大8倍 >_<
推 azureblaze: 外星人會不會用medium-endian
推 monoceros629: 真是很認真的了解unicode
→ MOONRAKER: 連endian都不一樣真是糟透了 XP