爲什麼UTF-8不允許作爲「ANSI」代碼頁？

在Windows _setmbcp功能允許任何有效的代碼頁...爲什麼UTF-8不允許作爲「ANSI」代碼頁？

（除UTF-7和UTF-8，這是不支持）

OK，不支持UTF-7品牌意義：字符具有非唯一表示，並且會引入複雜性和安全風險。

但爲什麼不是UTF-8？根據我的理解，Windows API函數的「ANSI」版本將它們的參數轉換爲UTF-16，調用等價的「W」函數，並將輸出中的任何字符串轉換爲「ANSI」。這是我一直在做的手動。那麼爲什麼Windows不能爲我做？

2010-06-08 dan04

您是否知道CP65001是Windows'UTF-8的名稱？雖然在'WriteFile（）'中有一些錯誤，但它沒有很好的記錄，但是你可以在很多地方使用它。 – hippietrail 2011-04-01 14:18:21

「ANSI」代碼頁基本上是遺留的：Windows 9X時代。無論如何，所有現代軟件都應該是Unicode（即UTF-16）。基本上，當最初設計Ansi代碼頁的東西時，UTF-8甚至沒有發明出來，因此對多字節編碼的支持相當雜亂無章（即大多數Ansi代碼頁是單字節的，除了一些東亞代碼頁是一個或兩個字節）。無論如何，當所有的新開發應該以UTF-16完成時，增加對「適當的」多字節編碼的支持可能被認爲是不值得的。

來源

2010-06-08 06:09:45

+15

我同意所有新的開發應該在* Unicode *。但我有理由建議使用UTF-8而不是UTF-16。（1）我的團隊在任何人對此不屑一顧之前寫了一百萬行非Unicode感知代碼，現在要將所有基於char的字符串更改爲基於wchar_t的字符串將是一項巨大的努力。（2）我們計劃將我們的產品移植到Linux上，而UTF-8更傾向於Linux。 – dan04 2010-06-08 06:53:36

_setmbcp()是一個VC++ RTL函數，而不是Win32 API函數。它隻影響RTL解釋字符串的方式。它對Win32 API A函數沒有任何影響。當他們在內部呼叫對方W時，A函數始終使用MultiByteToWideChar()和WideCharToMultiByte()指定代碼頁0（CP_ACP）以使用系統默認的Ansi代碼頁進行轉換。

來源

2010-07-21 22:00:00

Microsoft是否明確說明了這一點？如果他們真的這樣做，那麼我看不出有什麼理由不應該以某種方式告訴運行時在使用ANSI函數時使用CP_UTF8。 – Calmarius 2014-10-08 11:32:28

微軟的國際化專家Michael Kaplan試圖回答這個問題on his blog。

基本上他的解釋是即使Windows API函數的「ANSI」版本是爲了處理不同的代碼頁，歷史上有一個隱含的期望，即字符編碼每個代碼點最多需要兩個字節。 UTF-8不符合這種期望，現在改變所有這些功能將需要大量的測試。

來源

2014-02-03 09:42:31 jamesdlin

ANSI代碼頁不限於Windows中的兩個字節。 char的進展是SBCS-> DBCS-> MBCS，對於wchar_t則是UCS2-> UTF16。我沒有看到MBCS不能使用UTF8代碼頁和char的理由。 – evoskuil 2014-05-21 00:58:46

@evoskuil什麼是Windows支持的ANSI代碼頁的示例，每個代碼點使用兩個以上的字節？ AFAIK，對於Windows，MBCS表示DBCS（而DBCS表示1或2個字節的字符），而http://msdn.microsoft.com/en-us/library/cwe8bzh0.aspx顯然證實了這一點。 – jamesdlin 2014-05-21 02:22:56

請參見[代碼頁標識符]（http：// msdn。microsoft.com/en-us/library/windows/desktop/dd317756(v=vs.85).asp）我上面貼出： Windows XP及更高版本：GB18030簡體中文（4字節）您發佈的參考狀態：「支持在所有平臺上稱爲雙字節字符集（DBCS）的多字節字符集（MBCS）形式。」 IOW稱爲DBCS的表單是MBCS的一個子集。這是針對「所有平臺」的。進一步查看頁面上的內容：「在支持MBCS的Windows操作系統版本上運行時[工具]完全支持MBCS。」 – evoskuil 2014-05-21 06:41:11

爲什麼UTF-8不允許作爲「ANSI」代碼頁？

回答

相關問題