ES_OEMCONVERT 這個標志，主要是用在 16 位 Windows 系統上。下面是一篇 MSDN 上的文章中對它的一段描述：ES_OEMCONVERT 會導致輸入到編輯控件中的文本從 ANSI 轉換為 OEM，然后再轉換回 ANSI。這可確保在應用程序調用 AnsiToOem 函數將編輯控件中的 Windows 字符串轉換為 OEM 字符時正確轉換字符。ES_OEMCONVERT 對于包含文件名的編輯控件最有用。

讓我們將時間返回到1992年1月31日，即上面這篇文章的日期。

此時，主要的 Windows 平臺是Windows 3.0。Windows 3.1距離發布還有幾個月的時間，而 Windows NT 3.1 還有一年多的時間。主要的文件系統是 16 位 FAT，為了討論的目的，這個時代的 FAT 的相關功能是文件名以 OEM 字符集存儲在磁盤上。（我們在前面的文章中討論了 OEM 和 ANSI 代碼頁之間分裂背后的歷史。

由于 GUI 程序使用 ANSI 字符集，但文件名存儲在 OEM 字符集中，因此 GUI 程序中文件名中唯一可以使用的字符是兩個字符集中存在的字符。如果 ANSI 字符集中存在某個字符，但 OEM 字符集中不存在，則無法將其用作文件名;如果 OEM 字符集中存在某個字符，但不存在 ANSI 字符集，則 GUI 程序無法操作它。

編輯控件上的 ES_OEMCONVERT 標志可確保僅使用 ANSI 和 OEM 字符集中存在的字符，因此備注 “ES_OEMCONVERT” 對于包含文件名的編輯控件最有用”。

讓我們快進到今天。

所有流行的 Windows 文件系統都支持 Unicode 文件名，并且已經有十年的歷史了。從 ANSI 字符集轉換為文件系統使用的字符集不再有數據丟失。因此，無需篩選出任何字符來防止用戶鍵入在轉換為文件名期間將丟失的字符。換句話說，ES_OEMCONVERT 這個標志在今天毫無意義。這是 Unicode 標準出來之前的產物。

事實上，如果你使用這個標志，你會讓你的程序變得更糟，而不是更好，因為它不必要地限制了允許用戶在文件名中使用的字符集。例如，運行美國英語版本的 Windows 的用戶不允許輸入中文字符作為文件名，即使文件系統完全能夠創建名稱包含這些字符的文件。

總結

今天文章的意義，不在于如何使用 ES_OEMCONVERT ，而是，在你吭哧吭哧編寫界面代碼的時候，如果看到了這個標志，你不至于一點感覺都沒有。
現在你的狀態應該是：ES_OEMCONVERT 對我的程序沒有任何有用或者有害的影響，我不需要使用它。