為什麼這篇UTF 16 轉 中文鄉民發文收入到精華區：因為在UTF 16 轉 中文這個討論話題中，有許多相關的文章在討論，這篇最有參考價值！作者LPH66 ((short)(-15074))看板Programming標題Re: [問題] B...
就我對字元編碼的所知來回答看看
※ 引述《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
推 jeonjh:用心的文章... 122.124.129.74 01/29 11:45
※ horngsh:轉錄至看板 C_Sharp 01/30 13:39