1樓：netkiller
早期的作業系統都採用 L18N，包括 Linux 系統也是 L18N，Linux 經歷了痛苦的遷移，遷移到 i18n。微軟一直沒有狠下決心做i18n 遷移。
主要是相容性的問題。
2樓：
因為有大量的歷史遺留程式仍然在使用非Unicode編碼（比如小黃油啊）
而且這裡的歷史遺留指的不是程式作成的年代，是api和開發方式的年代，Windows SDK等不阻止你在2023年按照2023年的方式開發程式；然後有一些框架又把2023年的方式包裝起來流傳到了現在，從而導致有的2023年開發的程式還在以2023年的方式。
這構成了乙個雙向促進的死迴圈，跳出這個迴圈的方式只有：另起爐灶弄一套（binary意義上）全新的api（但是通過巨集定義隱藏細節，在開發看來只是設定乙個選項的事），然後舊的爛攤子原封不動。
3樓：tonjiji
現在win10，支援預設UTF-8編碼了，但是相容性問題一大堆，各種程式無法正常執行，有什麼用，現在預設雖然是GBK，但是處理Unicode文字及文字完全沒問題。
4樓：
我覺得是歷史遺留問題，微軟一開始沒有考慮到統一字符集，導致各個軟體開發商會根據相應字元編碼開發軟體，所以現在微軟很難把字符集統一成Unicode了，不然可能很多軟體都會出現亂碼或者無法正常使用。
5樓：lhelpme
win10可以試試，win10現在支援預設設定為utf8了
遇到乙個問題
系統登錄檔裡面的編碼都會改變，原來用gbk寫入的值，例如中文註冊碼之類的，沒處理好的都會有問題
6樓：momo owo
這個問題從提出到現在，已經過去5年了，沒有乙個人引用這本書裡的內容。它雖然有些老，但知名度不至於這麼低吧。人家在知乎誕生之前就已經回答過了。
下面是「我走的是流量捨不得看圖的文本版」：
19.11 為什麼不能把UTF-8設定為系統的ANSI編碼頁
如果你能夠把系統的ASCII編碼頁設定為UTF-8，那麼在程式中就能夠呼叫所有Win32函式的「A」版本，並且可以避免在呼叫W版本的函式時需要進行的從UTF-8到UTF-16的編碼轉換。程式將得到Unicode的所有好處而無需重寫。
我的同事Michael Grier指出了為什麼不能這麼做的一些原因。
首先，有些程式希望從編碼頁中得到當前地區的資訊。你可能首先會想到這種做法是不合理的，但有些人在程式中確實是這麼做的。「哦，預設的編碼頁是949？
那肯定是在南韓。」或者更為奇怪的需求是，「在編碼頁950中，第二個月份的名字是什麼？」但在UTF-8中並沒有包含任何當前地區的資訊，因為這個編碼頁並沒有和任何文化或者世界某個地區關聯在一起。
其次，有些情況可能更糟糕。在許多程式中都假設乙個字元的最大編碼長度是兩個位元組。換句話說，這些程式支援SBCS（單位元組字符集）和DBCS（雙位元組字符集），但不支援更為一般性的MBCS（多位元組字符集）。
如果在GetCPInfo函式中返回的CPINFO.MaxCharSize大於兩個位元組，那麼這個程式將無法執行。對於UTF-8來說，所返回的CPINFO.
MaxCharSize正是四個位元組。
有時候，這種對每個字元最多包含兩個位元組的依賴性是微妙的。例如，假設你正在編寫某個字元讀取函式，這個函式將從stdin中讀取字元並且轉換為Unicode。基本的演算法是：
從stdin中讀取位元組，並且在讀取完乙個字元後生成Unicode字元。在緩衝區的尾部可能有些位元組並不是某個字元的完整編碼，那麼就必須將這些位元組通過ungetch函式重新放回到輸入流中，以便在稍後進行處理。最終，當這個字元的完整編碼位元組出現時，函式將成功地從stdin中讀取這個（現在是完整的）字元，並將這個字元轉換為Unicode，然後再重複這些操作。
然而，如果在stdin中的字元使用的是UTF-8，那麼上面這個演算法將會失敗，因為每個UTF-8字元最多可以是四個位元組，這就可能需要把多達4-1=3個位元組放回到輸入流中。而ungetch只能放回乙個位元組。
而且，當字元是三個位元組或者四個位元組時，顯然第乙個位元組是前導位元組，最後乙個位元組則不是，但是中間的位元組該如何處理？很少有程式會對這些「中間位元組」進行處理。例如，大多數程式識別字元邊界的技巧是，通過查詢前導位元組序列，並根據這個序列的長度是奇數還是偶數來設定字元邊界。
這種方法在處理三位元組的UTF-8字元時將會崩潰。
如果能把ANSI編碼頁設定為UTF-8，那麼許多事情都將變得更加簡單，但遺憾的是不能這麼做，這實在是太糟了。因為，並不是你所想要的就總能得到。
當然了，這本書年頭也不短了，至於為什麼現在Windows可以把Unicode設成預設字符集了，可能是因為那種通過編碼頁來判斷區域的程式設計師都優勝劣汰了吧。
7樓：
他們都會回答的完美了。
然後我發現win10 1803支援unicode了但是電腦現在是各種亂碼
貼幾張圖。
1.魯大師
2.有道詞典
笑死，還有輸入法自己都能亂碼的。
大部分英文國家開發的軟體是沒有問題的，國內公司開發的軟體普通有些問題，有的很嚴重亂碼，有的就那麼幾個選項亂碼。
8樓：
這個我覺得有兩個原因，乙個是相容問題，utf-8出來的更晚，第二個是因為utf8乙個中文字元基本上是3個位元組，而gbk一般是2個，用gbk話效能比較好
9樓：
Unix 一家（包括 OS X 和 Linux）就是這麼幹的，結果對中文的支援跟 Windows 一比幾乎就是狗屎。支援 Unicode 本來沒錯，但只支援 Unicode 就 skateboard 了
10樓：yang leonier
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 字符集的。
11樓：
是的，主要還是相容性的原因。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 下的 API 做得更 安全 些？
冬芳 有啊，win10在這方面就下了功夫，比如uwp軟體，api守得死死的。還有就是win10每一次大更新都會修改和隱藏原本自己用的一些敏感api，用到這些隱藏api的軟體在更新之後就會崩潰。而這些api很多是拿來幹正事的，但是一把刀，可以切菜，也可以殺人，取決於用的人，微軟用來管理系統，被黑客拿來...
微軟為何不把XBOX ONE 變成一台帶PC功能的遊戲主機？
自定義丶 那麼多人把這個問題理解成 主機裡邊塞win。明明就是要在pc裡邊塞個遊戲主機。把主機做成乙個 win一樣的作業系統，用硬體裝上就可以了，主機並不一定要是個機器，是個軟體不就可以了。 不還手 這是市場佔據的問題 隨著360的時代落寞成為過去，one作為前代的替代品也應是乙個技術品質上的革新，...
如何看待微軟的 Windows 10 Cloud？
王不實 我倒是覺得這玩意是微軟打造商店 UWP生態 不知道用哪個詞語表達合適，反正就是類似蘋果的的生態，當然實際情況也是有差別的 的一步棋，如果這玩意能有比較大的使用者量對他的生態還是有很大幫助的，當然前提是如果。 實名反對某位的 RT打臉論 RT和Cloud都應該看作是微軟轉型的嘗試。其根本目的是...