※ [本文轉錄自 Programming 看板] 作者: LPH66 ((short)(-15074)) 看板: Programming 標題: Re: [問題] Big5跟UTF-8不需要考慮endian跟相容ASC … 時間: Mon Jan 26 17:52:24 2009 就我對字元編碼的所知來回答看看 ※ 引述《zlw (洞房不敗)》之銘言： : 大家好 : 我對於 Big5 似乎不需要考慮 endian 這點感到疑惑，想請教一下。 : -- : 比如AB兩個字，其 ASCII Code 為 41 42 (16進位)，而 Unicode codepoint 為 U+0041 : 跟 U+0042。 : 如果 Little Endian 的電腦存一份內容為AB的文件，編碼成UTF16，因為 UTF16 基本單位 : 是 2 Bytes，所以不考慮BOM情況下，內容最後會成 41 00 42 00 (16進位) : 當傳送到 Big Endian 的電腦時，解讀出來的內容就變成 U+4100 U+4200 兩字，而非AB : -- : 我的問題是，Big5也以 2 Bytes 為一個字的基本單位，但似乎不需要考慮endian。這是 : 因為Big5向下相容ASCII，所以CPU只會當成一堆ASCII去存，跟UTF-8一樣，基本單位變成 : 1個byte 才可以不用考慮endian？ 這部份可能是對的 由於 unicode 本身並不是 DBCS/MBCS 的編碼 不需要相容於原有的編碼之中 因此才必須自己決定要用什麼方式來儲存編碼 (因其每個編碼的大小是 16-bit = 2 byte 等於你要想辦法存一個 C 語言中的 short 那麼大的數字 當然要考慮 endianness 了) 而 DBCS/MBCS 的編碼為了要能相容於舊編碼 (在此即ASCII) 因此需要有一個頭的機制來分出從哪一個開始 當然基本單位就變成和舊編碼 (ASCII) 一樣是 1 個 byte 了 以 UTF-8 的機制為例就是看到一個 byte 範圍在 0xC2~0xF4 之間表示一個頭的開始 而 Big-5 則是 > 0x7F 做為頭這樣 所以嚴格說起來 UTF-16 也可以算是 D"B"CS (或許該改叫 DCCS, Double-Codepoint Character Set?) (←這是我胡謅的詞別當真XD) 因為 UTF-16 有所謂的 surrogate pair 的設計 用來表示 U+10000 以上的字元 而這個設計是以 U+D800~U+DBFF 做為頭 U+DC00~U+DFFF 做為尾的設定 和 DBCS 其實還滿像的 只不過這裡的基本單位是 2 byte 因此還是得考慮 endianness (也就是為什麼會分出 UTF-16LE UTF-16BE 的原因了) : 等到開啟文件內容，比如為 A7 41 41 (16進位) 時，記事本逐一搜尋發現A7大於ASCII : 理論上最大的7F時，才更改判別此文件是所謂的 DBCS？(這我不太懂，不確定) : 然後因為Windows當時設定，在控制台->地區及語言選項->進階->非Unicode程式的語言 : 裡面是設成中文(台灣)，所以才進一步判定為Big5編碼，並且顯示出繁體中文「你A」來 : 整個的流程、原理是這樣嗎？ 這要稍微扯到 Windows 的判定規則了 沒有特別處理的話 就我所知 Windows 是將 native 的編碼視為所謂 "ANSI" 編碼 (就是記事本的 "ANSI" 存檔選項) 這 native 的編碼應該就是相容於過去所謂的 code page 的東西 像 Big5 => CP950, GB2312 => CP936, Windows的西歐字母 => CP1252 這樣 也因此系統裡會留著一份各個 code page 的對照表 (C:\Windows\System32\C_xxx.nls 就是了 UAO (aka. unicode補完) 也是改動這裡的 C_950.nls) 在需要時 (下面會提到) 會自動抓這裡的對照表來轉碼 而記事本其實它是一支 unicode 程式 (你可以在記事本裡打一些這裡打不出來的字符和組合 例如你可以在同一篇文件中參雜繁中簡中日韓四種文字都沒問題) 只是它內建有 unicode 偵測 當開檔的時候會自動偵測它是不是 unicode 如果它判定是 UTF-16LE/UTF-16BE/UTF-8 三者之一的話 就會以那種格式來開啟文件 否則就會判定為 ANSI 才會讓系統以目前的預設編碼來找 code page 轉碼 這時才會去看系統設定非 unicode 程式用什麼編碼來找 (以我這台 Vista 的選項來說 中文(繁體，台灣) 就是 CP950 同理 中文(簡體，中國) 就是 CP936 ) 順帶一提, UTF-8 也是一個 MBCS 的編碼 所以它也有自己的 code page 號碼: CP65001 不過因為 UTF-8 稍微特殊 它並沒有對應的 C_65001.nls 在系統裡 而是直接在系統程式裡解決掉了 : -- : 另外有些不支援Unicode的軟體，平常只能讀英文及繁體中文的目錄，但是把「非Unicode : 程式的語言」這個設定改成韓文後，就能開啟韓文命名的目錄。我想查這部份的資料， : 為什麼會有這種狀況，以及要如何改善，想請教有什麼關鍵字？ : 謝謝大家。 這單純就是轉碼的問題而已 原因只是因為 Big-5 沒有韓文 程式要向系統抓目錄 系統看到程式使用了非 unicode 的(舊式) API 就把抓來的名字轉成 "ANSI" 編碼送給程式 這裡的 "ANSI" 編碼一樣視控制台的那個設定而定 那因為 Big-5 裡沒有韓文 所以韓文目錄就變成 ????? 了 那當程式要開啟叫做 ????? 的目錄時 因為程式給系統的是 "?????" 這個名字 系統自然回說找不到目錄 所以開啟失敗 當你把設定改成韓文後 系統抓來的名字轉成 "ANSI" 編碼時就會去抓 EUC_KR (CP949) 來轉碼 而 EUC_KR 裡面就有韓文 所以程式收到了正確轉成 EUC_KR 的韓文字 再用這些韓文字向系統要求開啟目錄 系統從非 unicode 的 API 收到的字串就由 EUC_KR 轉回 unicode 就正確的開啟了目錄 也就是說, 系統在發現程式和他溝通是使用舊的 API 時 就知道這支程式想要舊的行為 因此會自動把送來的字串先過一次轉碼轉成 unicode 再送給後端 後端回來的字串再過一次轉碼轉成 "ANSI" 編碼才送回去給程式 這就是上面提的"需要時轉碼"那個"需要時" 而控制台的設定就是設定這裡要轉成哪一個 code page 而已 -- [LPH] Oops, your OOP's a problem? 說: 你現在還是看不到狗? ************* 說: 看得到 只是 他們不會跑 就一直呆呆在那邊 一直在起點 [LPH] Oops, your OOP's a problem? 說: 你要按"ㄅㄧㄤˋ"它們才會跑啊@@" --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 122.254.20.82 --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 59.126.240.23