關於Windows的命令列多語言輸出

多語言支援是個古老的問題，牽扯到各個層面上的問題，包括作業系統、字元集、程式本身的支援等等。命令列下是否能夠完全支援多國語言呢，下面進行一些嘗試，用來打破一些既定的錯誤概念。

Visual Studio預設不支援UNICODE化的代碼文本與資源本文。

倘若VS做的那麼完美，還要命令列的編譯結構以及各種第三方輔助的開發工作作甚？VS預設情況下是和VS的語言環境綁定起來的。比如我在英文的Vista x64下使用的中文VS 2005，預設VS的地區只有兩個，“中文”或者是“與Windows相同”。而且，在這個環境下建立的代碼文本的編碼多半是本地代碼，如GBK，根本不是UNICODE，於是乎從底層支援UNICODE也無從談起。而Linux上的文字編輯器以及Code::Blocks預設就是UTF8，可以想象，在多地區多語言合作的軟體開發環境中VS的這個“特色”會有多麼的麻煩。

VS的資源編輯系統支援UNICODE的顯示，預設卻不將字串作為UNICODE編譯進程式。

是的，你沒有看錯，我差一點就被這個騙過去了。

添加一個字串，然後切換到德語IME輸入“Wörter”，其中“ö”是CP1252的字元，不是中文CP936字元。然後用LoadStringW（防止程式自己進行轉換）載入到程式，列印出來肯定是

0057 003f 0072 0074 0065 0072

其中3f就是那個“?”，ASCII中的問號一枚而已，根本不是我們想要的00f6。再以代碼方式開啟資源檔，是不是看到這樣的慘狀，

開始我還以為是由於沒配置好setlocal，反覆測試最後發現在病毒植入程式的時候VS就已經自作聰明的幫你轉換成了問號。這算VS的一個BUG呢？還是FEA呢？

曉得了這個問題，解決方案就有了：在所有的字串前加L轉換為寬字元串。可是一旦你按Ctrl+S儲存後，VS又自作聰明的去掉了L，真不是一般的愚蠢！對比了一下WxWidget，人家早就進化到了基於XML的資料檔案XRC。可是這個VS的這個特色估計已經延續了許多年了，MS還是沒有修複。

千萬別以為.net時代了，古老的WIN32、MFC程式就不需要維護了，事實上還是有許多程式依舊不是虛擬機器的，於是需要照顧更多。比如3dsmax，那個STRING_TABLE長得嚇人……

Windows命令列預設使用本地字元集。假如你沒有調用CHCP 1252切換到德語字元集，那麼那個字元即使16進位顯示是正確的，也無法列印出正確的字元。還是老老實實的先切換字元集吧，別瞎折騰了。

或者大家統統都寫英文程式吧，這個最一勞永逸。