小弟是一個月前才終於從XP換成了WIN7(64位元)又以前都有安裝UAO因此文字檔基本上都是ANSI那現在沒裝UAO就出現問題了，日文、簡中看不了所以現在必須要轉換那些本應 ... ... <看更多>
「ansi編碼big5」的推薦目錄：
- 關於ansi編碼big5 在 Re: [問題] Big5跟UTF-8不需要考慮endian跟相容ASC 的評價
- 關於ansi編碼big5 在 ANSI編碼文字檔的BIG5日文/簡中如何正常轉成Unicode？ 的評價
- 關於ansi編碼big5 在 darkthread/CEAD: BIG5/GB2312編碼快篩 - GitHub 的評價
- 關於ansi編碼big5 在 土包的工作日誌- Notepad++滿猛的編碼模式... | Facebook 的評價
- 關於ansi編碼big5 在 [問題] 如何把ANSI編碼的CSV讀入Python? - PTT數位生活區 的評價
- 關於ansi編碼big5 在 批次切換BIG-5與UTF-8 的評價
ansi編碼big5 在 darkthread/CEAD: BIG5/GB2312編碼快篩 - GitHub 的推薦與評價
BIG5 GB2312繁簡編碼快篩. BIG5 與GB2312 是繁體中文與簡體中文最常採用的ANSI 形式編碼，當代系統多已改採Unicode ，但在涉及傳統系統整合的情境中，仍有處理中文ANSI ... ... <看更多>
ansi編碼big5 在 土包的工作日誌- Notepad++滿猛的編碼模式... | Facebook 的推薦與評價
Notepad++滿猛的編碼模式如果選擇轉換至Ansi碼格式，我的"啦"文字就會是本機碼(Big5)組成，也就是\xB0\xD5 如果選擇轉換至UTF-8碼格式，我的"啦"文字 ... ... <看更多>
ansi編碼big5 在 [問題] 如何把ANSI編碼的CSV讀入Python? - PTT數位生活區 的推薦與評價
各位好在這裡想請問大家Python裡有沒有什麼方法可以讀ANSI編碼的CSV 我不想用convert的方式換成其他編碼方式因為讀大檔案 ... 若你說的中文，是說檔案內本身編碼為big5. ... <看更多>
ansi編碼big5 在 批次切換BIG-5與UTF-8 的推薦與評價
檔案編碼格式不統一一直是令人抓狂的問題，因此可以用一個在Linux的指令套件iconv 來 ... 各國採用的ANSI編碼，其中包括GB2312、BIG5等中文編碼方式 ... ... <看更多>
ansi編碼big5 在 Re: [問題] Big5跟UTF-8不需要考慮endian跟相容ASC 的推薦與評價
※ 引述《LPH66 ((short)(-15074))》之銘言：
: 就我對字元編碼的所知來回答看看
: 這部份可能是對的
: 由於 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 的原因了)
感謝前輩提供這麼多資訊，對我很有幫助。查了一些資料跟做了一些測試後，比較確定了
閒聊一下。原本對DBCS跟MBCS的名詞不太熟悉，看了一些資料後發現，原來這個名詞的
定義是有爭議的，真的是一團混亂。我想在此補充給還不知道的人
一般多數人認為的 DBCS 就是像 Big5、GBK 這類編碼，對於ASCII原有的字照樣顯示
一個位元組，而ASCII沒有的文字，基本上就是把第一個位元組的最高位元改成1，使其
變成lead byte，後面再接一個位元組，兩個位元組變成一個對應的字。
可是，像Big5字元集裡面，不是每個字都是2 Bytes而會變動，所以有人主張改叫MBCS
(但比較少人用)
又有人主張DBCS就應該是每個字都是2 Byte才算，所以Big5又變成不算DBCS，
反而Unicode才是DBCS (也是比較少數看法)
: 這要稍微扯到 Windows 的判定規則了
: 沒有特別處理的話 就我所知
: Windows 是將 native 的編碼視為所謂 "ANSI" 編碼
: (就是記事本的 "ANSI" 存檔選項)
: 這 native 的編碼應該就是相容於過去所謂的 code page 的東西
: 像 Big5 => CP950, GB2312 => CP936, Windows的西歐字母 => CP1252 這樣
查了資料寫說，由於 ANSI 是古早提出 codepage 之類的組織如何如何...
所以對 Windows 使用者來說，ANSI這個字可能不是指那個組織，而就是象徵
windows code page 這東西。
但我不太明白這個 ANSI 編碼，是不是指現在不流行 code page 這個概念，
現在強調資料的編碼？
所以記事本預設編碼是 ANSI，這等於預設編碼是採用過去的 code page 概念，
也就是說當編碼為ANSI時，則隱含文件開啟時會依照控制台的地區設定，然後去找
對應的 code page 對照表來解讀，是這樣嗎？
: 也因此系統裡會留著一份各個 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 在系統裡
: 而是直接在系統程式裡解決掉了
: 這單純就是轉碼的問題而已
: 原因只是因為 Big-5 沒有韓文
: 程式要向系統抓目錄 系統看到程式使用了非 unicode 的(舊式) API
: 就把抓來的名字轉成 "ANSI" 編碼送給程式
: 這裡的 "ANSI" 編碼一樣視控制台的那個設定而定
: 那因為 Big-5 裡沒有韓文 所以韓文目錄就變成 ????? 了
: 那當程式要開啟叫做 ????? 的目錄時 因為程式給系統的是 "?????" 這個名字
: 系統自然回說找不到目錄 所以開啟失敗
: 當你把設定改成韓文後
: 系統抓來的名字轉成 "ANSI" 編碼時就會去抓 EUC_KR (CP949) 來轉碼
: 而 EUC_KR 裡面就有韓文 所以程式收到了正確轉成 EUC_KR 的韓文字
: 再用這些韓文字向系統要求開啟目錄
: 系統從非 unicode 的 API 收到的字串就由 EUC_KR 轉回 unicode
: 就正確的開啟了目錄
所以像大陸人用的 Windows，因為他們的code page裡面包含日文，那同樣一個日文假名
目錄放在同樣硬碟，用同樣一個「不支援Unicode」的套裝軟體去開啟。
他們的Windows可以正確把UTF-16目錄名稱轉成對應的GBK名稱給那個軟體，也就是對應的
一連串 byte 假設像是 0xFF 0x01 0xFF 0x02。那個軟體只要把 0xFF 0x01 0xFF 0x02
傳給 Windows 就又能轉回正確 UTF-16 目錄名稱存取了。
但我們Windows因為code page不包含假名，Windows沒辦法轉換，只好轉成一堆 '?'給
該套裝軟體。而因為'?'本來就可以對應到UTF-16，所以軟體傳回去，Windows就會轉成
錯誤的路徑。
但是裝了UAO後，因為現在Windows可以在Big5的code page找到對應的位置了，假設是
0xFF 0x03 0xFF 0x04，軟體再傳回去給Windows時就能找到正確的目錄。然後造成由於
可以轉換日文，而使原本明明不支援Unicode的軟體，變得好像支援Uniocde了
: 也就是說, 系統在發現程式和他溝通是使用舊的 API 時
: 就知道這支程式想要舊的行為
: 因此會自動把送來的字串先過一次轉碼轉成 unicode 再送給後端
: 後端回來的字串再過一次轉碼轉成 "ANSI" 編碼才送回去給程式
: 這就是上面提的"需要時轉碼"那個"需要時"
: 而控制台的設定就是設定這裡要轉成哪一個 code page 而已
謝謝您的說明，查了些 Windows API 資料跟測試了一下，已經搞懂這個了
補充如下
--
#include <windows.h>
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR
lpCmdLine, int nCmdShow){
MessageBoxW(NULL, L"測試 Hello World", L"123", MB_OK);
/*寬字元版本(wchar_t)。字最終被編譯器存成 Unicode 編碼
*/
MessageBoxA(NULL, "測試 Hello World", "123", MB_OK);
/*原始版本(char)。還是存成 C-Style String，但程式運行時OS會依地區設定
解讀，比如用Applocale以簡體開啟，會得到簡體字的「代剛」
*/
return 0;
}
--
Windows API 是用C語言編寫，所以跟 ANSI C 一樣是用 wchar_t 這所謂的寬字元來支援
Unicode，寬字元目前情況下就是等於 unsigned short (2 Bytes)
因此 Windows API 的那些函數很多都分成兩個版本，名稱結尾A表示ANSI，就是之前說的
code page。而W結尾表示wide character，表示可以處理Unicode。
我把那些要改地區設定才能開啟韓文目錄的軟體，用 Dependency Walker 去查詢有
Import 進去的 Windows API 函數，發現都是以A結尾，所以才會那樣沒錯。
雖然說如果是透過 LoadLibrary、GetProcAddress 從dll裡面呼叫的函數是沒辦法從
Import 函數裡面找到，但是像一般開檔應該不是這樣呼叫的。
所以大概能用 Dependency Walker 這類程式去判斷一個軟體使用ANSI還是寬字元
的函數，判斷該軟體屬於支援 Unicode 還是不支援 Unicode。
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 124.8.150.197
... <看更多>