原文链接：https://devblogs.microsoft.com/oldnewthing/20050719-12/?p=34893
The ES_OEMCONVERT edit control style is a holdover from 16-bit Windows. This ancient MSDN article from the Windows 3.1 SDK describes the flag thus:
编辑控件的 ES_OEMCONVERT 样式是从 16 位 Windows 中继承下来的。下面这篇在 Windows 3.1 SDK 中古老的 MSDN 文章对这个标志是这样描述的：
ES_OEMCONVERT causes text entered into the edit control to be converted from ANSI to OEM and then back to ANSI. This ensures proper character conversion when the application calls the AnsiToOem function to convert a Windows string in the edit control to OEM characters. ES_OEMCONVERT is most useful for edit controls that contain filenames.
ES_OEMCONVERT 标记会将输入到编辑控件的文字从 ANSI 编码转换到 OEM 编码，然后再转回 ANSI 编码。通过这样操作，可以保证应用程序调用AnsiToOem 将编辑控件中的字符转换为 OEM 编码的字符时，可以获得恰当的结果。ES_OEMCONVERT 在包含文件名的编辑控件中最有裨益。
Set the wayback machine to, well, January 31, 1992, the date of the article.
让我们把时间倒回1992年1月31日，也就是上面那段文字那时候。
At this time, the predominant Windows platform was Windows 3.0. Windows 3.1 was still a few months away from release, and Windows NT 3.1 was over a year away. The predominant file system was 16-bit FAT, and the relevant feature of FAT of this era for the purpose of this discussion is that file names were stored on disk in the OEM character set. (We discussed the history behind the schism between the OEM and ANSI code pages in an earlier article.)
那个时候，占据主导地位的 Windows 平台是 Windows 3.0。Windows 3.1 还得再过几个月才会发布，而 Windows NT 3.1 还得再等一年。那时占主导地位的文件系统是 16 位 FAT，而与此处讨论相关的 FAT 文件系统的设计，则是磁盘上存储的文件名使用的是 OEM 字符集。（我们在早先的一篇文章中讨论过有关 OEM 和 ANSI 代码页之间的分崩离析。）（译注：链接已失效，无法查证）
Since GUI programs used the ANSI character set, but file names were stored in the OEM character set, the only characters that could be used in file names from GUI programs were those that exist in both character sets. If a character existed in the ANSI character set but not the OEM character set, then there would be no way of using it as a file name; and if a character existed in the OEM character set but not the ANSI character set, the GUI program couldn’t manipulate it.
由于 GUI 程序用的是 ANSI 字符集，而文件名是用 OEM 字符集存储的，所以在 GUI 应用程序中使用的文件名，其字符集只能是在两种字符集中共存的那些。如果某个字符在 ANSI 字符集中存在，但并不存在于 OEM 字符集中，那么就不能讲这个字符用在文件名中；反之，如果某个字符在 OEM 字符集中存在，但在 ANSI 字符集中不存在，那么 GUI 应用程序也搞不定它。
The ES_OEMCONVERT flag on a edit control ensures that only characters that exist in both the ANSI and OEM character sets are used, hence the remark “ES_OEMCONVERT is most useful for edit controls that contain filenames”.
编辑控件中的 ES_OEMCONVERT 样式可以保证只有在 ANSI 和 OEM 两种字符集中共存的字符才能使用，也就印证了『ES_OEMCONVERT 在包含文件名的编辑控件中最有裨益』的说法。
Fast-forward to today.
回到现在。
All the popular Windows file systems support Unicode file names and have for ten years. There is no longer a data loss converting from the ANSI character set to the character set used by the file system. Therefore, there is no need to filter out any characters to forestall the user typing a character that will be lost during the conversion to a file name. In other words, the ES_OEMCONVERT flag is pointless today. It’s a leftover from the days before Unicode.
如今所有流行的 Windows 文件系统都支持 Unicode 文件名，并且已经如此十年了（译注：原文发布时间为2005年7月19日，Windows 3.0 发布时间为1990年5月22日），在将（文件名中的字符从）ANSI 字符集转换为文件系统使用的字符集（Unicode）不会再有数据丢失的问题了。因此也没有必要再预先将用户录入文件名时，可能在后期转换中丢失的字符过滤掉了。换句话说，ES_OEMCONVERT 这个样式标记已经毫无意义了，只是一个在 Unicode 年代之前的遗留而已。
Indeed, if you use this flag, you make your program worse, not better, because it unnecessarily restricts the set of characters that the user will be allowed to use in file names. A user running the US-English version of Windows would not be allowed to enter Chinese characters as a file name, for example, even though the file system is perfectly capable of creating files whose names contain those characters.
实际上，如果你非要用这个样式标记不可，只会让你的程序更糟糕而不是更优秀，因为对用户在文件名中允许使用过的字符集进行限制已经毫无必要。例如，（在你经过这样设计的应用程序中，）使用美国英语版本 Windows 的用户就不能输入中文字符作为文件名了，即便是文件系统可以完美支持创建包含那些（中文）字符的文件名也一样。
远嚣 Comment