Re: [問題] Unicode, 控制字元

看板Programming作者etwas (i'm only dust)時間15年前 (2010/06/02 11:32)推噓0(0推 0噓 1→)

留言1則, 1人參與討論串3/3 (看更多)

※ 引述《ggg12345 (ggg)》之銘言： : ※ 引述《etwas (i'm only dust)》之銘言： : : 標題: [問題] Unicode, 控制字元 : : hi : : 小弟讀了一些unicode的資料 : : ... : : 推 buganini:UTF-8是ASCII-compatible的 220.135.231.23 06/01 20:24 : ================================================================== : 網路的收送兩端模組假如是能分辨 ASCII 的控制碼(ASCII-aware), 對於 : binary data 就會做區分的處理(譬如 ESCAPE indication), 若 binary : data 是 UTF-8 就會在傳輸前後, 被做預處理與後處理復原, 因此不會被 : 誤判, 也就不會對 UTF-8 字串的控制碼起不當反應. : 假如送端是能分辨 UTF-8 , 因之對 UTF-8 裡的控制碼(octet) 不做預處 : 理, 但收端卻不能分辨 UTF-8 只能分辨 ASCII , 此時欠缺預處理的 binary : data 就會被收端誤判. : 程式模組間的呼叫, 傳遞參數與資料就相當於收送兩端進行送收資料, 兩模 : 組對資料形式與表達的認知應該一致, 才不至於對 binary data 產生誤動作. : 常用UTF-8是 3 bytes 一組, ASCII 則是7個bit(當一個byte)一組, 跟 2 : bytes 的中文碼(如 BIG5) 會遇到的問題是一樣的. : 由於歷史發展次序與前後相容的需要, 傳送端不能假設接收端已都被更新到能 : 認知新的分辨規則. : 即使把 multi-bytes 的多國語言碼轉換成 ASCII compatible 的表示法, 新 : 的這串 ASCII 仍然需要有一個預處理過的標幟做為區分, 才能分辨出開始與 : 結束的 "multi-bytes multi-lingual character string". : 處理這些不同資料段的方法就如同網路的上下多層協定及封裝分區塊的表 : 示法. 非常感謝您清楚的解答我想是因為文章後來講UTF沒有提到預/後處理的部份我還以為這部份可以被神奇地直接解決所以像這個非BMP的字U+10008 UTF-16 code units: D800 DC08 而 DB 00 DC 08 中00 和08都是C0 contral char network drivers/protocols收東西進來對header處理內容部分都直接往上層丟而上層的程式需要選對或是判斷對編碼才不會誤解這樣的理解對吧? -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 114.137.41.177