→ tinlans:我一直想說你們這幾篇都在幹嘛，原來還是聽過 ICU 的嘛.. 02/06 15:17
推 Ebergies:這幾篇在 Unicode 觀念釋疑啊 LOL 02/06 17:11
→ asoedarren:ICU有點肥 02/06 19:27
Big5 雖爛，但功能強大的 Unicode 也不簡單...
假設我們用 wchar_t buf[] 陣列存放了文字檔的內容，然後接受使用者的指示，
要隨機印出第 N 個字。
第 N 個字到底存在哪？選 buf[N] 是否可以？
如同前面文章版友提過，
當 unicode code point 超過 U+FFFF 時，會使用 surrogate pair，這就使得
第 N 個字的指標不一定是 buf + N。
有個 Windows API 叫 CharNextW(wchar_t *src)，它會返回下一個字元的指標，理論
上重覆做數次就能取得正確位置...
但根據微軟員工的這篇文章：CharNext(ch) != ch+1, a lot of the time
http://blogs.msdn.com/b/michkap/archive/2005/01/14/352802.aspx
...CharNext and CharPrev do not currently handle surrogate pairs properly...
而且同篇文章的例子也顯示出，肉眼看起來是一個字元 (Glyph)，
實際上卻是組合字，需要用到 3 個 Unicode Code Point，
它 1 個字在 UTF-16 下，要佔 6 個位元組。
聽說有個跨平台的函式庫叫 ICU，不知道裡面的函數能不能解決上面的問題？
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 124.8.134.217