我注意到当从MME读取MIDI端口名称时，名称是使用ANSI代码页编码的多字节字符串，我的应用程序默认使用该代码页。从DirectMusic驱动程序接收这些名称时，名称是使用OEM代码页编码的宽字符字符串。有关Codepages的快速复习，请参阅this article by Raymond Chen。
在我的德语系统中，这意味着当使用当前代码页时，结果是ANSI代码页，我从MME获得“Audiogerät”，从DirectMusic获得“Audioger ö t”，后者是错的。当我将该姓氏视为OEM编码时，这会得到修复。
那我怎么知道用哪个代码页来解码这些名字呢？为什么来自DirectMusic的名称编码方式不同？它来自USB驱动程序吗？ COM框架？的DirectMusic？ 如何确定在读取MIDI端口名称时使用哪个代码页？
有关信息：
MultiByteToWideChar()和WideCharToMultiByte()函数执行转换，CP_ACP和CP_OEMCP作为要使用的代码页的参数。midiInGetDeviceCaps()从MME子系统获取MIDI端口信息...... MIDIINCAPS.szPname（ANSI）代码页转换CP_ACP。IID_IDirectMusic8::EnumPort()从DirectMusic获取端口信息... DMUS_PORTCAPS.wszDescription代码页转换CP_OEMCP。答案 0 :(得分：0)
我不确定为什么DirectMusic框架会使用一组代码页，而MME会另外使用，但是你最终的解决方案可能是构建一个抽象层，然后为每个API进行特定的实现。这样，您的软件的更高级别不需要关注这样的细节。
也就是说，端点名称肯定来自操作系统。 USB MIDI设备仅指定端点类型（即输入或输出，以及数字），但操作系统可以根据需要自由解释它们，这就是它们被本地化的原因。
没有特定的API调用（据我所知）来找出框架将提供其字符串的代码页。但是，DirectMusic似乎确实使用带有OEM代码页的双宽字符作为一般约定，尽管我无法在任何MSDN文档中找到这一点。在MSDN DirectMusic documentation about MIDI port capability structures中，描述类型明确定义为WCHAR，而Game Audio Programming书似乎也表明此类型是API范围的约定。虽然假设OEM是这些字符的默认编码是危险的，但是我找不到任何其他说法（并且谷歌搜索“DirectMusic代码页”现在将此页面列为最高命中）。
编辑：查看此stackoverflow question on determining the current OS codepage。 DirectMusic API可能以这种方式设置代码页。
答案 1 :(得分：0)
实际上并没有一种自动方式来判断哪些代码页用于这些类型的数据。见这里：How can I detect the encoding/codepage of a text file