易爆物

接下來我想實際操作比空談更容易理解，首先感謝杜子美先生提供的測試案例：

// in ex1.c -- encoded in Big5
...
printf("功蓋三分國，名成八陣圖。\n");

先用Big5儲存程式碼，然後在 Windows 上使用 MinGW gcc 編譯：

gcc ex1.c

在預設的情況下 gcc 會假設原始碼採用 UTF-8 編碼，但就算假設錯誤，gcc 仍然會繼續以 byte 為單位讀入原始碼。因「功」和「蓋」含有「\」標記，卻沒有緊跟著合法的 escape sequence，所以編譯過程中會發出 warning。雖然最後還是可以產生執行檔，但是輸出結果顯然和預期的不太一樣。

這純粹是編譯方式搞的鬼，如果在執行階段才從外部讀入「功蓋三分國...」，編譯器沒有插手的餘地，這個現象就不會發生。

前面提過 Source character set 還會影響其他語彙元素，這裡舉個邪惡的例子：

// in ex2.c -- encoded in Big5
...
if (done) { // 執行成功
    printf("ok.\n");
    ...

若上面這段程式採用 Big5 編碼，並且和前面一樣用 gcc 預設值編譯，「功」這個字的第二 byte 就是「\」，在 C/C++ 裡面代表延續註解到下一行，所以接下來的 printf("ok.n"); 也會被視為註解的一部分。

gcc 的字集選項

其實會有上面這些問題，都是因為使用者不熟悉 gcc 字集設定的緣故。gcc 各階段的字集由這幾個選項控制：

-finput-charset=charset

輸入檔的字集，即前述 Source character set，預設為 UTF-8。

-fexec-charset=charset

經處理過的 string literal 和 character constant 最終會被轉換成的編碼方式，即前述的 Execution character set，預設也是 UTF-8。

-fwide-exec-charset=charset

類似前者，但影響的是寬字元的 string literal 和 character constant，像是 L"wide string"。預設值可能是 UTF-16 或 UTF-32，視 sizeof(wchar_t) 而定。

所以只要編譯時加上「-finput-charset=Big5」，gcc 就會以 Big5 字碼做為讀取單位，前述 ex2.c 邪惡註解的問題果然就不再發生了。

但在同樣的編譯設定下，「功蓋三分國...」似乎被輸出成一堆怪東西，因為這次 gcc 終於讀懂string literal 的內容了，所以有辦法正確轉換成預設的 Execution character set，即UTF-8。反過來說，如果我們一開始使用 UTF-8 儲存程式碼，並且採用 gcc 預設值編譯，也會發生同樣的情形。

我們寫的程式很忠實地把 UTF-8 字串丟給 console，但 console 卻不認得，所以顯示成亂碼，這個情形就像以前 DOS 時代必須先執行倚天系統才能顯示中文字型一樣。只要先用指令「chcp 65001」切換 console 內碼表至 UTF-8，然後再執行前面的程式，那麼「功蓋三分國...」就能被正常顯示。

若不想做「chcp 65001」這個動作，也可以在編譯時另外指定「-fexec-charset=Big5」，那麼 gcc 就會改用 Big5 做為 Execution character set。再做個實驗以凸顯 Execution character set 的影響，同樣使用 Big5 做為原始碼的編碼方式：

// in ex3.c -- encoded in Big5

char msg[] = "白日依山盡";
printf("%u\n", sizeof(msg));

如果用以下選項編譯，結果會顯示 sizeof(msg) 的值為 16，這表示每個中文字碼被編成 UTF-8 的 3 byte，而非 Big5 的 2 byte。：

gcc -finput-charset=Big5 ex3.c

改用下面方式編譯的話，結果會顯示 sizeof(msg) 的值為 11：

gcc -finput-charset=Big5 -fexec-charset=Big5 ex3.c

這告訴我們，如果有人喜歡在 string literal 裡面使用中文，配置記憶體時又老是以每個中文字佔 2 byte 為前提，那麼在運氣很背的情境下有可能撞鬼。

以上僅以 gcc 為例，其他編譯器概念上是相同的，移植程式碼時應多留意相關設定。C++11 可直接在程式碼中以 u8 前綴指定 string literal 使用 UTF-8 編碼，如：

char s[] = u8"This is a UTF-8 string.";

就我的理解，其他的前綴如 L、U、u 等，指定的只是儲存單位寬度，至於具體編碼方式在標準中沒有明定（頂多算是暗示）。

結論？

其實這裡沒有什麼堪稱結論的見解，畢竟現實中的程式語言、相關工具實在太多樣化了，應該不會有什麼一體通用的方案。

需要解讀原始碼的工具，我能想到的大概就有：編譯器/直譯器、文件生成、程式重構、靜態分析（這是非常大的一類）、程式碼生成等等。另外還有一群比較通用型的工具，如：文字編輯器（通常含一堆非官方支援的 plugin，或可視為獨立程式？）、模板、搜尋、比較、補丁等等，低階工具的多數功能可能不受編碼影響，但難免有踩到地雷的時候。

如果想要在原始碼裡面使用英文以外的語言，確認一下相關工具的支援程度會幫自己省下很多事。如果不確定因素很多，或許比較保守的策略還是乖乖用英文。工具的限制固然是必要考量，同樣重要的是誰會讀這個程式，畢竟程式碼是寫給人看的。若是連作者自己都不太讀的隨用即丟程式碼，只要跑起來沒問題就好了，註解也沒什麼好寫的，管他的。

至於原始碼的編碼方式，我個人認為第一順位是無 BOM 的 UTF-8，因為 UTF-8 具有某些良好的特性，很多以 byte 為單位的軟體即使沒有特別處理 UTF-8，往往還是能夠得到正確的結果。其中一個惱人的例外是那些不支援非 ASCII 的 Regex 引擎，但同樣的情形發生在 Big5 這類的 MBCS 身上也沒好到哪裡去（GNU Flex 就是這樣的例子，使用者必須額外花心思）。而且支援 UTF-8 的軟體資源會越來越多，其他的「本地」編碼很難說。

這裡提供一個不要 BOM 的理由：Unix-like 環境會根據純文字文件開頭的 #! 標記來選擇該文件的解釋器，這是個很方便的功能，我手邊的 bash、python、gnuplot 等等腳本常會這樣寫，BOM 會破壞這個機制。不幸的是許多 Windows 平台的編輯器並沒考慮到這一層，即使在記事本或 Visual Studio 選擇了 UTF-8 存檔，它們不讓使用者選擇就擅自加 BOM。（不過應該沒有正常人用記事本寫程式吧，世界上有太多專業的純文字編輯器可以選）