※ 引述《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