為何微軟不把 Windows 的默認字符集設置成 Unicode ？

12-30

Unicode已經發展了這麼多年，已經成熟。且windows自己本身也完成了Unicode化，API也基本都提供了Unicode版本。UTF-8作為Unicode的一種流行的編碼，但為何windows不把系統的默認字元編碼設置成UTF-8，而仍然使用內碼錶來解決不同的編碼問題。這不僅導致開發程序複雜，並且出現亂碼也嚴重影響了windows的使用。

其實根本就沒有「默認字符集」這種概念。Windows的內核就是用unicode編碼的，而對於應用程序Windows允許使用不同的字符集。如果應用程序本身就是unicode的，那麼一切ok；如果應用程序是non-unicode的，那麼才需要用到「默認字符集」概念，但是請仔細看控制面板相關選項，這裡的「默認字符集」其實是「non-unicode默認字符集」。就是說，這東西本身就是用於配置「非unicode程序」的，當然沒法設置成unicode。

所以，正如 @時國懷所說的，都是兼容性惹的禍，因為微軟不能說：「老子支持unicode了，以後不支持unicode的程序都給我滾粗。」只能撅著屁股讓這些老掉牙的程序仍然可以運行，於是只好給他們提供一個「默認字符集」。

@趙冬毓說的顯然不是根本原因，在日本銷售的Windows，「默認字符集」是shift-jis，難道也是為了遵循中國政府的規定？

是的，主要還是兼容性的原因。Unicode and Microsoft Windows NT 微軟從WinNT 3.1就開始支持UTF-16了，但unicode和code page一直都是同時支持的。字元處理相關的API一般都有A和W兩個版本。

msdn文檔是鼓勵新開發的程序使用unicode的。但在某些情況下，比如你的程序需要和不支持unicode的程序交互時，可能還是會需要用到code page。

Windows設置里的默認字符集，是指在字元不是unicode編碼的情況下，Windows默認應該使用哪種字符集來處理。你的程序可以根據這個設置來選擇相應的code page，處理非unicode編碼，但它並不影響你在你的程序中使用unicode。

都是因為萬惡的兼容性。

Windows內核中默認使用的是UTF-16，如果你寫內核驅動就知道了，在內核里幾乎都是以UTF-16的方式處理字元串的。

對於運行在應用層（用戶態）的代碼，Windows允許用戶通過配置確定非Unicode字元的顯示方式，可以是中文，也可以是BIG5，也可以是其它字符集。

為什麼這麼設計？因為是考慮到兼容性的問題，現在Windows7里，仍然能運行大量Windows 98時代的程序，WindowsXP里甚至能運行不少Windows3.x甚至更古老的程序，原因就是為了兼容性。

題主喜歡UTF-8，應該從Linux開發轉過來的吧？Linux默認我記得是UTF-8（好像JSP也是？），UTF-8和UTF-16哪個更好我就不細說了，這方面的爭論至今都沒有結果。但是Windows可以把應用設置成UTF-16，之後的開發幾乎沒有太多的改變，我也沒遇到過「這不僅導致開發程序複雜」的情況，至少C語言開發是這樣的。所以，我看不出來UTF-16帶來多少開發程序的不便。

為什麼用UTF-16？好像UTF-16出現的比UTF-8要早一些，微軟內核選擇了UTF-16，再大改內核是非常困難的，大概是這樣的。

如果題主是想討論UTF-8和UTF-16哪個更好，建議再開個題目。

補充，反對 @趙冬毓的回答，國家標準中只強調支持，而沒有強調必須默認使用，「must conform」是「要求符合」，而沒有強調默認使用（default）這個字符集，工信部的那個規範里也沒有強調默認使用這一點。

遵循國家標準，也可以是把國家標準作為操作系統的子集，因為Linux、MacOS均支持GB18030，並且這個默認支持的行為不需要每次開機都提示，只需要在安裝時告之即可。而且微軟也做過類似的事情：在歐洲銷售的WindowsXP在安裝的時候都有瀏覽器的選擇，並提供了Firefox等其它瀏覽器的下載鏈接，這也是微軟為了提供告之義務以規避當地的反壟斷法規。而且微軟即使保持對GB18030默認支持，對於兼容性來說也沒有問題，既遵守法律，又保持兼容性，未嘗不可。

另外，附上標準全文：信息處理產品中文要求認證實施規則

以及維基百科上的說明：GB 18030

以及檢測標準：

檢測一般要求如下：
　　●字彙完整性：產品的字彙範圍應是國家標準GB 18030中所有給出字形的字元；
　　●體系正確性：產品必須能夠正確識別和處理按照國家標準GB 18030進行編碼的文本文件。

Windows 在 16 位時代（版本1.0，2.x）和 16 / 32 位混合的時代初期（3.x），是不存在 Unicode 這個東西的。因此，早期的 Windows API 中，所有字元串都視為 ANSI 編碼。Windows 3.0 中 / 日 / 韓文版引入了雙位元組字符集的概念，使得 Windows 開發中 ANSI 編碼被稱為所謂本地字元，並出現了 Windows 多區域支持（NLS）。從 Windows NT 3.1 和開始，Windows 內部開始使用 UTF-16 作為字元串編碼方式 (wchar_t)，但是為了保證和以往 API 的兼容性，大多數和字元串有關的 API 函數都有 A 和 W 兩個後綴的不同版本，A 代表傳統的本地字元編碼處理，W 代表UTF-16處理。在使用 C 語言進行 Windows 編程的時候，一般不直接使用後綴來選擇不同版本的 API，而是通過在 & 相關文件中通過處理宏 UNICODE 來選擇。同時，NLS 也擴展到可以在多種內碼之間互相轉換，而 Unicode 的幾種存儲形式（UTF-16、UTF-8、UTF-7）也被 NLS 所支持。

雖然微軟早已提供了原生的 UTF-16 支持，但是早期此支持僅僅在 Windows NT 系列操作系統中完整存在，而當時的主流是 16 / 32 位混合的 Windows 9x 系統，大多數 W 後綴的 API 調用都是不支持的，僅僅支持通過 NLS API 進行內碼之間的轉換。另外，同樣為了保持和以往 API 的兼容性， wchar_t 類型的字元串在微軟的 C 運行庫里採用了一套不符合 ANSI C 標準的新函數（比如 sprintf -&> swprintf, strcpy -&> wcscpy）等來處理，不符合絕大多數 C 程序員的習慣。因此，當時很大一部分程序，甚至包括微軟自己的 Office 系列都沒有使用 Windows NT 的原生字符集 UTF-16，需要處理 UTF-16 時只是通過 MultiByteToWideChar 之類的 NLS 相關 API 進行轉換。而為了兼容在這個傳統下寫出來的老應用程序，之後所有的 Windows 系統都同時存在和使用兩套原生支持的字符集，NT 原生字符集（UTF-16）以及本地字符集。當然，在現代的 Windows 編程規範中，都是明確推薦使用原生 UTF-16 字符集的。

其實Windows NT系本來就是Unicode優先主義的設計，地域內碼是為了相容於不支援Unicode的應用程式。

這個我覺得有兩個原因，一個是兼容問題，utf-8出來的更晚，第二個是因為utf8一個中文字元基本上是3個位元組，而gbk一般是2個，用gbk話性能比較好

Unix 一家（包括 OS X 和 Linux）就是這麼乾的，結果對中文的支持跟 Windows 一比幾乎就是狗屎。支持 Unicode 本來沒錯，但只支持 Unicode 就 skateboard 了