之前在 programming 版也問過相關的話題，對這有興趣。 就我的認知提供一些看法...先承認因為版友貼的是英文，所以只有跳著喵幾眼而已， 有空的版友，還望您幫忙看有沒有講錯，感謝。 ※ 引述《jtmh ()》之銘言： : ※ 引述《elfkiller (沒有暱稱)》之銘言： : : 在寫網頁路徑變換程式 : : 而在網頁原始檔中有一段 %u5929%u4F7F ... 這樣的文字 : 　　這個算是 Unicode 表示法， : 　　都是以 %u 開頭， : 　　然後後面接著 4 個 16 進位數字。 : 　　例如「天使」這兩個字的 Unicode 碼位分別為 22825 和 20351， : 　　由 10 進位轉成 16 進位後就變成 5929 和 4F7F， : 　　再套入上述的表示法即為 %u5929 和 %u4F7F， 對這方面不熟，但我猜這 5929 跟 4F7F 應該是指 Unicode 中所謂的「code point」 也就是說今天有兩個字，外表長得像這樣：『天使』，那他們在 Unicode 的規範中， 分別是位於哪個位置？ ※實際上好像不是一個外表對應一個 code point？？而是分成好幾組，在某組 裡面有個長得像「天」這樣子的，其 code point 被定為 0x5929，也許另外一 組裡也有一個長得像「天」？這裡推薦一個網站 http://www.fileformat.info/info/unicode/char/search.htm 把你想要查 code point 的東西，也就是字或符號，貼上去按搜尋即可列出來。 「天」位於 0x5929，「使」位於 0x4F7F。知道位置後，要表示給人看時， 就牽涉到「編碼」。目前 Windows XP，以記事本 (notepad.exe) 的觀點， 一個檔案會有三種編碼： 1. ANSI編碼 2. UTF-8編碼 3. Unicode編碼 -- 關於「3. Unicode編碼」 若更正確來說，Unicode 比較常見的編碼至少有 UTF-8、UTF-16LE、UTF16-BE、 UTF-32LE、UTF-32BE...等，這裡的「3. Unicode編碼」不是準確的講法， 實際上應該是 Windows XP 預設採用的 UTF-16LE 編碼。 換言之，code point 為 0x5929 的「天」字，在記事本用微軟新注音打 `u 再打入對應 code point=5929，字出來後，存成「3. Unicode編碼」， 則其 raw data 會寫29 59 (LE = Little Endian)。 -- 關於「1. ANSI編碼」 這跟 Windows 控制台「地區及語言選項」的設定有關係。 簡單舉例看，raw data 寫 0x41 0xBA 0xCS 在簡體 Windows 記事本打開 會變「A好」；在繁體 Windows 打開會變「A疑」。 ANSI編碼是一種MBCS編碼，MBCS代表他裡面的任一個字，"不固定"由 1個 Byte 或 2 個 Byte 組成。好處是，因為CPU對MBCS編碼處理的單位是「1次1Byte」， 所以不會有Endian問題。CPU只有在處理像float這種，一次一定要「4個Bytes」 的資料時才必須考慮Endian。 UTF-8簡單講，在Unicode的編碼裡，他是屬於「1次1Byte」被CPU處理的那種， 跟ANSI編碼有一樣的優點。但 Windows 核心用的那種 UTF-16LE 編碼不是。 -- 重點來了，網路傳輸網址，用GET方法時，資料會放在URL內，譬如這兩個網站 http://www.yam.com/ http://wiki.livedoor.jp/sougouwiki/search?keywords= 其中 yam 首頁的是用強悍的 Big5 編碼，素人系総合 wiki 網頁是用 日文 EUC-JP 編碼 註：EUC-JP 編碼、Big5 編碼、簡體 GBK 編碼...等，都歸納為 ANSI 編碼。 我們在搜尋框輸入資料，如果是 ASCII 比如 abc 就直接轉成 ASCII 很快樂的送出 0x616263 這 3 個 Bytes。 那如果要打不在 ASCII 內的字呢？比如要搜尋「台」字，那就會有問題... 傳過去的封包，裡面 raw data 到底要不要考慮 endian？你傳了 2 Bytes 過去，還要 再額外講 endian 才能避免因為對方的 CPU 是敵營，而解讀錯資料。 所以最後變成，資料該怎麼解讀，不能由傳送方指導，而是接收方收到後，照自己使用的 編碼來解讀。而且只會用無 endian 問題的 ANSI 跟 UTF-8 編碼解讀。 那麼接收方就不用考慮 endian。傳送方用的瀏覽器要聰明到在 素人wiki 輸入「台」執行搜尋時，先判斷這張網頁的編碼是 EUC-JP，然後再把「好」轉成 EUC-JP 的編碼 0xC2E6 送過去。 同理「yam 首頁」搜尋「台」字會送 Big-5 編碼的 0xA578 過去。 -- % 存在的理由— 本來是不需要用到 % 這個東西，但搜尋完 yam 或素人wiki後，我們知道因為 get 可以 讓網址=後面的字對應搜尋框輸入的資料。 只要連上網址：http://wiki.livedoor.jp/sougouwiki/search?keywords=%C2%E6 就會重複在素人wiki搜尋「台」的動作。 keyword=後面接要搜尋的資料，那直接把網址變成 http://wiki.livedoor.jp/sougouwiki/search?keywords=台 會怎樣？如果你在一張空白網頁，說要連上這個網址，鬼才知道對方用什麼編碼 事實上不可能在keyword=後面打任何沒有在 ASCII 內的字去做get。 那怎麼轉換台字？所以這就是 % 符號存在的價值，為了能重現當初送 0xC2E6 那就 直接傳 raw data 就好，問題是直接打 keyword=C260，顯然又牴觸原本的 ASCII。 所以在每個編碼基本單位 Byte 加上一個 % 就解決。 當然如果像 Big5 的「台」編碼是 0xA578，因為 78 其實等於 ASCII 編碼下的「x」， 你跑 http://search.yam.com/wps?k=%A5x 依然等於在yam首頁輸入「台」字搜尋。 而現在的瀏覽器會在你網址有「?keyword=台」這種狀況時，預設轉成 UTF-8 編碼 這也就是為什麼我們直接在 google http://www.google.com.tw/search?&q= 的 q= 後面打個台字，就真的可以正確搜尋台字。 而在素人wiki的網址自己 DIY 打這樣 http://wiki.livedoor.jp/sougouwiki/search?keywords=台 卻不能變成搜尋台字的原因。 -- 終於打完了，好熱 --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 124.8.143.13 打字錯誤修正 ※ 編輯: zlw 來自: 124.8.143.13 (07/05 22:35)