windows - 使用 MME 和 DirectMusic 时的 ANSI 或 OEM 代码页?

标签 windows character-encoding midi codepages directmusic

我注意到,当从 MME 读取 MIDI 端口名称时,名称是使用 ANSI 代码页编码的多字节字符串,我的应用程序默认使用该代码页。从 DirectMusic 驱动程序接收这些名称时,这些名称是使用 OEM 代码页编码的宽字符字符串。参见 this article by Raymond Chen快速回顾代码页。

在我的德语系统上,这意味着当使用当前代码页时,结果是 ANSI 代码页,我从 MME 得到“Audiogerät”,从 DirectMusic 得到“Audiogeröt”,后者是错误的。当我将姓氏视为 OEM 编码时,此问题得到解决。

那么我怎么知道用哪个代码页来解码这些名字呢?为什么来自 DirectMusic 的名称编码不同?它来自USB驱动程序吗? COM 框架?直接音乐? 在读取我的 MIDI 端口名称时,我如何确定要使用哪个代码页?

信息:

  • 我使用 MultiByteToWideChar()WideCharToMultiByte() 函数执行转换,使用 CP_ACPCP_OEMCP 作为要使用的代码页的参数。
  • 我使用 midiInGetDeviceCaps() 从 MME 子系统获取 MIDI 端口信息...
  • ...并使用 CP_ACP (ANSI) 代码页转换 MIDIINCAPS.szPname
  • 我使用 IID_IDirectMusic8::EnumPort() 从 DirectMusic 获取端口信息...
  • ...并使用 CP_OEMCP 代码页转换 DMUS_PORTCAPS.wszDescription

最佳答案

我不确定为什么 DirectMusic 框架会使用一组代码页,而 MME 会使用另一组代码页,但是您这边的解决方案可能是构建一个抽象层,然后为每个 API 进行特定的实现。这样,您的软件的更高级别就不需要关心这样的细节。

也就是说,端点名称肯定来自操作系统。 USB MIDI 设备仅指定端点类型(即,输入或输出,以及数量),但操作系统可以根据需要自由解释它们,这就是它们被本地化的原因。

没有特定的 API 调用(据我所知)来找出框架将在哪个代码页中传递其字符串。但是,DirectMusic 似乎确实使用带有 OEM 代码页的双宽字符作为一般约定,尽管我无法在任何 MSDN 文档中找到明确说明的内容。在MSDN DirectMusic documentation about MIDI port capability structures ,描述类型明确定义为 WCHAR,并且 Game Audio Programming这本书似乎也表明这种类型是 API 范围内的约定。虽然假设 OEM 是这些字符的默认编码是危险的,但我找不到任何其他说明(谷歌搜索“DirectMusic codepage”现在将此页面列为 HitTest 门)。

编辑:检查这个stackoverflow question on determining the current OS codepage . DirectMusic API 可能以这种方式设置代码页。

关于windows - 使用 MME 和 DirectMusic 时的 ANSI 或 OEM 代码页?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/1069013/

相关文章:

c# - 撇号通过 C# 中的过滤器

html - html5 音频标签是否非正式地包含 .mid (MIDI)?

c++ - CoInitializeEx 用于 boost::test::unit_test

c++ - cURL Windows 构建配置的说明

character-encoding - 浏览网站时出现奇怪的字符集编码

linux - 编码 : unrtf SYMBOL. 字符映射需要更改

c - windows下编译win32 api c程序实例(命令行方式)

windows - 是否可以使用 AWS 运行普通的 Windows 10 机器?

ios - 当 MIDI 目标或源更改时收到通知

java - 如何关闭 MIDI 设备?