Ada程序文本实际字符集定义位置及GNAT字符校验问题咨询

标准层面的字符集定义 #

Ada 2012参考手册（ARM）的字符集规则不存在定义模糊的问题，规则分为两个层级：

• 语法规则层面：ARM 2.3节明确了标识符的字符构成逻辑：标识符首字符需属于Unicode Letter大类（含Lu大写字母、Ll小写字母、Lt首字母大写、Lm修饰字母、Lo其他字母），后续字符除Letter大类外，还允许使用Number大类（Nd十进制数字、Nl字母数字、No其他数字）、Pc连接标点类字符。你看到的希腊字母、西里尔字母标识符示例，完全符合这一层的语法规则。
• 实现适配层面：ARM明确说明不强制要求所有实现支持全部Unicode对应类别的字符，编译器可根据自身适配情况收窄实际允许的源字符集范围。你看到的“实现用于Ada程序文本可视化表示的实际图形符号集未作规定”就是这一层规则的说明，不是没有判定依据。

GNAT 2021字符校验逻辑说明 #

GNAT 2021的字符校验没有错误，你遇到的非ASCII字符报错是默认配置导致的：

• GNAT默认采用ASCII-only的标识符校验规则，所有非ASCII字符都会被判定为非法，这是出于兼容性、降低标识符混淆风险的默认选型，完全符合ARM给实现留的适配空间要求。
• 如果需要使用非ASCII标识符，需要显式添加两个编译开关：
  • -gnatW8：指定源文件编码为UTF-8
  • -gnatiw：开启宽字符标识符支持，允许所有Unicode Letter类、Number类字符出现在标识符中
    你贴的第二个可运行示例就是加了这两个开关才可以正常构建，你第一次测试希腊、西里尔字母标识符时没有加这两个开关，自然会报非法字符错误。
• 针对你提到的其他Unicode Pc类字符（如全角下划线、波浪连接符等），即使开启宽字符支持，GNAT也不会将其判定为合法标识符字符，仅认可ASCII下划线_（U+005F）作为合法的连接标点。这个处理属于实现层面的合理收窄，这类字符在实际Ada工程中几乎没有合法使用场景，放开反而会提升同形字符混淆、恶意代码注入的风险。

tree-sitter解析器实现建议 #

如果你开发的解析器需要对齐主流Ada开发场景的实际使用习惯：

• 默认模式下，标识符仅允许ASCII字母、数字、下划线，和GNAT默认行为保持一致
• 可增加宽字符标识符支持的配置项，开启后允许Unicode Letter、Number大类字符出现在标识符中，但仍仅保留U+005F作为合法的Pc类连接符，不要放开全部Unicode Pc类字符
• 如果需要做严格贴合ARM标准的宽松解析模式，可单独做配置项放开全部规则允许类别的Unicode字符，但需要明确提示用户该模式可能和主流编译器行为不兼容

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