Office 365 Access重音字符匹配：排序规则与编码能力问询

一、Office 365 Access 支持的编码与排序规则 #

• 存储编码：Access的Short Text（短文本）和Long Text（长文本）类型默认采用**UTF-16（兼容UCS-2）**存储，每个基础多语言平面（BMP）字符占用2字节，符合官方文档中“每个字符占2字节”的描述，欧洲重音字符均属于BMP范围，无需额外处理。
• 排序规则：Access的排序规则绑定Windows系统区域设置，排序顺序下拉列表中的选项对应Windows的区域排序变体，例如：
  • General：遵循当前系统默认区域的默认排序规则（默认重音敏感）；
  • Accent-insensitive：对应区域的重音不敏感排序，启用后Dvorak与Dvořák会被判定为相等；
  • 其他选项如Case-insensitive、Binary等分别对应大小写不敏感、二进制字节级比较规则。
    这些规则底层依赖Windows的CompareStringEx API实现，并非SQL Server那样独立的排序规则体系。

二、VBA的字符集与Access的一致性 #

VBA在Office 365中使用UTF-16编码的字符串类型，与Access的存储字符集完全一致。VBA的String变量直接存储UTF-16字符，无需在Access数据与VBA变量之间进行编码转换，保证了字符传递的完整性。

三、VBA处理重音字符的兼容性问题 #

日常处理重音字符时，只要遵循以下注意事项，基本不会出现转换或兼容性问题：

• 避免使用旧版ANSI相关函数：如Asc、Chr这类函数会将UTF-16字符转换为系统默认ANSI编码（通常是Windows-1252），若字符不在Windows-1252范围内会导致丢失；应使用AscW、ChrW这类直接操作UTF-16字符的函数。
• 字符串比较的规则差异：VBA默认的字符串比较（如=运算符）遵循系统区域的默认排序规则（重音敏感），若需重音不敏感比较，可使用StrComp函数并结合自定义逻辑，或调用Windows API实现特定排序规则的比较。
• ODBC连接注意事项：通过ODBC连接Access时，需确保驱动使用UTF-16编码模式（Office 365的Access ODBC驱动默认已配置），避免出现编码转换错误。

内容的提问来源于stack exchange，提问作者Wayne Erfling