ES_OEMCONVERT这个标志主要用在16位Windows系统上。以下是MSDN上的一篇文章对其的描述：ES_OEMCONVERT导致输入到编辑控件中的文本从ANSI转换为OEM，然后再转换回ANSI。这确保当应用程序调用AnsiToOem函数将编辑控件中的Windows字符串转换为OEM字符时，字符被正确转换。ES_OEMCONVERT对于包含文件名的编辑控件最有用。让我们把时间倒回到1992年1月31日，也就是上述文章发表的日期。此时，主要的Windows平台是Windows3.0。Windows3.1还有几个月的时间，而WindowsNT3.1则需要一年多的时间。主要的文件系统是16位FAT，为了方便讨论，FAT在这个时代的相关功能是文件名以OEM字符集存储在磁盘上。（我们在之前的文章中讨论了OEM和ANSI代码页分离背后的历史。由于GUI程序使用ANSI字符集，但文件名存储在OEM字符集中，GUI程序中唯一可以在文件名中使用的字符是两个字符集中都存在的字符，如果一个字符存在于ANSI字符集中，但不存在于OEM字符集中，则不能作为文件名使用；如果一个字符存在于OEM字符集中，但不存在于OEM字符集中ANSI字符集，则GUI程序无法操作它。编辑控件上的ES_OEMCONVERT标志确保仅使用ANSI和OEM字符集中存在的字符，因此注释“ES_OEMCONVERT对包含文件名的编辑控件最有用”。让我们快进到今天。所有流行的Windows文件系统都支持Unicode文件名，并且已经有十年了。从ANSI字符集转换为文件系统使用的字符集时，不再有任何数据丢失。有因此，无需过滤掉任何字符以防止用户键入在文件名中丢失的字符。换句话说，ES_OEMCONVERT标志在今天毫无意义。这是Unicode标准出来之前的遗物。事实上，如果你使用这个标志，你会让你的程序变得更糟，而不是更好，因为它不必要地限制了允许用户在文件名中使用的字符集。例如，运行美国英语版Windows的用户不允许输入中文字符作为文件名，即使文件系统完全能够创建名称包含这些字符的文件。总结今天这篇文章的意义，不是如何使用ES_OEMCONVERT，而是你在写接口代码的时候，看到这个标志，你是不会有任何感觉的。您现在的状态应该是：ES_OEMCONVERT对我的程序没有任何有用或有害的影响，我不需要使用它。
