[心得] UNICODE

看板Soft_Job作者lihgong ( )時間6月前 (2023/11/06 13:26)推噓19(19推 0噓 25→)

留言44則, 23人參與討論串1/1

寫嵌入式軟體，離人類世界遙遠，我只知道英文字ASCII code是1byte 小時候用倚天中文，BIG5編碼每個字2byte UNICODE似乎是2byte，可以表示全世界的文字，矇矇懂懂閱讀Joel On Software的第四章 https://www.books.com.tw/products/0010467041 這篇文章也可以在這裡看到 https://www.cnblogs.com/AlphaAI/articles/3960296.html ---- 原來UNICODE有個Code Point的概念制定（橋）出這張code point的前輩，真的是偉大的成就人類終於有一個共同的表示法，紀錄每個字所以用BIG5編碼的文件，可以讀入以後，"DECODE"成上述的編碼（我覺得是UCS2）在wchar_t的domain (u16)做字串處理最後儲存的時候，再"ENCODE"成其他格式，例如UTF-8 之前用Python的UNICODE感覺encode/decode難以理解現在總算搞懂UTF-8是什麼，整理一份note記下來 https://lihgong.blogspot.com/2023/11/utf-8-unicode-utf-32-big5.html ---- patch, thanks to ybite, 更新UTF16 surrogate pair的資訊這東西的概念是這樣 1. UNICODE 0xD800 ~ 0xDFFF大家講好不放東西；所以出現這種字元必定有詐！一般狀態是 2byte代表一個字，這種狀態變成4byte代表一個字很多地方都有類似的招數 2. 要把UNICODE的U+10000 ~ U+10FFFF編進去，先把數值扣掉0x10000 看看他在16bit定址範圍外的offset多少，這裡的值域是0xFFFFF, 20bit 3. 編碼規則如下 byte0 = offset[19:10] + 0xD800 byte1 = offset[9:0] + 0xDC00 4. 這種編碼結構好處是self-synchronization，因為開頭和結尾的值域固定下來了如果中間有小錯誤也能偵測出來缺點就LIB解析時，還有些額外的邏輯要弄，還真的有點麻煩；不過比起用4byte字串的記憶體開銷相比，應該勉勉強強能接受；反正現在電腦效能過剩，小事啦！ ---- 後記3 感謝 *Dracarys 推薦的兩篇文章，過了20Y，和Joel當初的文章互相輝映！ * https://tonsky.me/blog/emoji/ * https://tonsky.me/blog/unicode/ 原來UNICODE有Extended grapheme cluster A上面多帶一個圈，可以是U+00C5或是U+0041 U+030A 我看過芬蘭人的鍵盤，他們能打出某些特殊的上下標，亞洲人的我難以想像所以A多帶個圈（兩個code point，符合我看他們鍵盤的感覺）或是一個code point直接代表這個字，反應人類描述文字這件事，自帶的複雜度直觀來看，所有文字都可以用UTF-32來表示？還是不行，有上述那些複雜的cases 所以作者說，處理UNICODE請用LIB，而且要按時更新的LIB（每年都會修訂）以我來說，就是體認UNICODE有自帶的複雜度，不是像C的字串那麼簡單的東西這兩篇文章確實看完就打通任督二脈，非常感謝 ---- 後紀4 關於UNICODE BOM (byte-order mark) 有個u16的數值，0xFE FF 這個數值用little-endian表示(大多數的電腦)，在記憶體裡會是0xFF 0xFE 如果用big-endian表示，會是0xFE 0xFF 一份文件用UTF-16儲存，編輯器打開，不知道這份文件的endian 假如開頭是0xFF 0xFE，那就是little-endian 假如開頭是0xFE 0xFF，那就是big-endian 我覺得上面的例子很爛，因為FE/FF實在長得太相似寫AA/BB可能更容易看清楚，不過標準就長這樣... 具體的資料可以看下面WIKI連結，有標準的BOM定義 https://reurl.cc/GKYxrW 另外更general的問題是，這兩種endian的好與壞，可以參考下面文章 https://hackmd.io/@chenishi/BJRaOrGCX?type=view 網路傳輸裡，先傳送big-endian天生是比較順的比如有筆u32資料0xaabbccdd，傳輸協定規定從MSB to LSB做CRC 假如是little-endian的機器，那就得這樣灌入CRC 注意陣列的順序是倒置的... data[3](0xaa) -> data[2](0xbb) -> data[1](0xcc) -> data[0](0xdd) 如果這台機器是big-endian，這樣灌入CRC就很順了 data[0](0xaa) -> data[1](0xbb) -> data[2](0xcc) -> data[3](0xdd) 操起for-loop，big-endian就是順（直覺）很多 for(i=0; i<4; i++) { calc_crc(data[i]) } -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 61.220.100.151 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1699248406.A.A68.html

推

wsad50232

11/06 16:42, 6月前 , 1^F

11/06 16:42, 1^F

推

now99

11/06 23:40, 6月前 , 2^F

11/06 23:40, 2^F

推

wuyiulin

11/06 23:41, 6月前 , 3^F

11/06 23:41, 3^F