自定义类JSON语法中STRING Token定义的修正咨询

嘿，这个问题我之前也碰到过类似的情况，咱们一步步来捋清楚～

你当前的问题核心在于：你的STRING规则没有定义明确的终止边界。在标准JSON里，字符串是被双引号包裹的，解析器很容易知道什么时候开始和结束；但你的语法里是“裸字符串”，没有引号，而你原来的STRING规则(ESC | SAFECODEPOINT)+会匹配几乎所有字符——包括语法里用作分隔符的=和,，还有结构符号{、}。这就导致解析器会把foo=123,bar整个当成一个STRING Token，完全没法拆分键名、分隔符和值。

解决这个问题的关键，就是让STRING规则明确排除那些属于语法结构的特殊字符，具体来说就是=、,、{、}这些用来区分键值对、分隔元素的符号。

给你一个具体的修改方案：

STRING
  : (ESC | ~[=,{}])+  // 匹配转义字符，或者任何不是=、,、{、}的字符
;

这样修改后，当解析器遇到=的时候，就会立刻停止当前STRING的匹配，从而正确识别出键名foo；接着处理=这个键值分隔符，再匹配值123；之后碰到,，就知道要结束当前键值对，开始处理下一个bar=abc。

另外还有个补充注意点：如果你的业务场景里，字符串（键名或者值）需要包含这些特殊字符（比如键名是foo=bar），那你需要同步调整你的转义规则ESC，让转义后的特殊字符可以被包含在STRING里，比如：

ESC
  : '\\' [=,{}]  // 允许转义=、,、{、}这些特殊字符
;

这样当你输入{foo\=bar=123}的时候，解析器会把foo=bar识别为一个完整的键名，而不会被中间的=拆分。

总结一下：裸字符串的语法必须明确界定“哪些字符不属于字符串”，也就是语法里的结构符号，这样解析器才能正确拆分各个Token，完成预期的解析逻辑。

备注：内容来源于stack exchange，提问作者fluter