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