Re: [問題] 似乎是big5編碼
之前在 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)
推
07/05 23:00, , 1F
07/05 23:00, 1F
推
07/05 23:09, , 2F
07/05 23:09, 2F
推
07/05 23:16, , 3F
07/05 23:16, 3F
推
07/06 17:38, , 4F
07/06 17:38, 4F
推
07/06 19:44, , 5F
07/06 19:44, 5F
討論串 (同標題文章)