> MicroSoft 认为 URI 若改成 IRI 时, 表示 binary data 的 %nn > 也是能表示 unicode 的, 可是 unicode 先天的汉字繁简问题, 造成混 > 淆的拉丁希腊字母问题, 由右向左的阿拉伯文问题等都没有完善解决, > 由於 IRI 包含 dns hostname , 仅解决 dns 并未能解决 AP 的问题. > 这个信息代表 MicroSoft 可能对 keyword search 仍然没有放弃, IRI > 还是跟 keyword search 更相关. ..... > 毕竟 multibyte code 与 single byte code 就如同字组合词跟单字 > 词在对字的辨识与处理需要不同看待, 整个看是一体有前後文的, 个别看 > 则不管这个符号发生在那个位置. 例如 80, 00 在 ASCII 常视为相同, > fx80fx 则有可能出现在 UTF-8 , 把 UTF-8 符号当成 byte 个别处理就 > 跟把繁简域名个个字个别处理会触犯一些不够周延的规则是同样的道理. ================================================================== 最近的一次 IE patch 把送给 proxy 的中文域名由 binary data 全都改为 %nn 的型式送给 proxy server, 如果不用 proxy port, Win2K 还是仍会在下层的 resolver 把域名改为 UTF-8 送出. 猜测其原因应该是 要用 %nn 来代替各种可能的 UTF-8 码通过 IE 内部, 避免发生误判域名 data 为 control code , 消除造成误动作所形成的漏洞. 这个动作跟 8 bit keyword 有点关系, 当VeriSign的 SiteFinder 把找不到的域名都拦到其 web pages 时, 可说群情激愤, 几乎动用 ICANN 要向其收回 .com 的代理权. 原因就是 8bit name 是有产品在使用的, 这 一拦就起了冲突. MicroSoft 这一更动, 当然会波及某些使用这个功能的 产品, 但显然还不是很严重, 因为以前也曾经这样用. Multi-Byte 8 bit data(含 UTF-8)在 ASCII 的世界果真有可能是 地雷重重, 因为原来的程式设计师都假设第 8 bit 用不到, 因此做记号时 可能就偷偷用上了. 另外就是那个 space 从来就没大量用过, 失误的经验 也无从累积, 宁愿转成 ACE (%hh 也是 ACE) 问题会避开一些. -- ◎ Origin: 中央松涛站□bbs.ee.ncu.edu.tw From: 140.115.6.234