> 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