PDF如何区分字符串与操作符/语法？括号不可靠时的识别规则

作为常年跟PDF底层结构打交道的开发者，我来给你拆解这个问题——其实PDF的文本绘制逻辑并没有你想的那么依赖括号计数，核心是操作符与操作数的语法规则，而非单纯的括号匹配。下面我会一步步讲清楚识别逻辑，再针对你给出的场景做具体分析。

一、核心区分逻辑：词法扫描+栈式执行 #

PDF本质是一种基于栈的轻量编程语言，所有内容都被拆分为「操作数」（比如字符串、数字、数组）和「操作符」（比如BT、ET、Tm、T*、TD这些预定义命令）。解析器的处理流程从词法拆分开始，天然就能把两者区分开：

1. 操作符的识别规则 #

操作符是PDF规范预定义的关键字，由字母、数字或特定符号组成，但绝对不会被任何操作数的语法标记（比如(、<、/）包裹。解析器在扫描时，会把连续的非操作数起始字符识别为一个token，再去匹配预定义的操作符列表——匹配上就是操作符，否则可能是名称对象等其他类型，但绝对不是字符串。

2. 字符串操作数的识别规则 #

字符串有两种形式，各自有明确的边界判定逻辑，完全不需要靠括号计数：

• 字面字符串：以未被转义的(开头，解析器会逐个字符扫描，遇到\就跳过下一个字符（把它当作普通文本，不做语法处理），直到找到第一个未被转义的)，此时字符串结束。内部的任何(或未转义的)都会被当作字符串内容的一部分，不会触发语法边界。
• 十六进制字符串：以<开头，到对应的>结束，内部只处理十六进制字符，不需要考虑转义，边界判定更简单。

二、针对你给出的特殊场景的具体分析 #

场景1：多字符串+位置参数的正常情况 #

[( Hello world ! )] [( Hello ) 45 ( the ) 45 ( world )]

解析器的处理步骤非常清晰：

1. 遇到[：标记数组开始，压入栈
2. 扫描到(：开始解析字面字符串，直到找到第一个未转义的)，得到字符串Hello world !，压入栈
3. 遇到]：把栈内的字符串打包成数组，压入栈
4. 接下来的[再次标记数组开始，依次解析：
   • ( Hello )得到字符串Hello，压栈
   • 数字45作为独立操作数压栈（它不在任何()包裹范围内，是合法的数字token）
   • ( the )得到字符串the，压栈
   • 数字45压栈
   • ( world )得到字符串world，压栈
5. 遇到]：把栈内的Hello、45、the、45、world打包成数组，压入栈
6. 后续如果遇到文本显示操作符（比如TJ），就会取出这个数组执行：字符串直接绘制，数字用来调整字符间距（这里的45就是字符间距调整值）

这里的45之所以被识别为位置参数，完全是因为它的语法位置——不在字符串标记内，是独立的数字操作数，和字符串天然区分。

场景2：字符串内部包含未转义括号的异常情况 #

[( Hel(lo ) 45 ( the ) 45 ( wor)ld )]

很多人会觉得这个场景里括号计数失效，但实际上PDF解析器根本不会用计数来判断：

1. 遇到[：数组开始，压栈
2. 扫描到(：开始解析第一个字符串，逐个字符处理：
   • Hel是普通文本，接着的(未被转义，直接作为字符串内容保留
   • 直到遇到lo后面的)——这个)未被转义，所以第一个字符串结束，内容是Hel(lo
3. 数字45作为独立操作数压栈
4. ( the )解析为字符串the，压栈
5. 数字45压栈
6. 扫描到(：开始解析下一个字符串，直到遇到wor后面的)——未被转义，所以这个字符串结束，内容是wor
7. 剩下的ld )会被解析器判定为语法错误（因为)没有对应的起始(），严格来说这是不符合PDF规范的内容，解析器通常会尝试容错，但不会把它归到前面的字符串里

三、关键总结 #

• 永远不要用括号计数来区分字符串和操作符，PDF解析的核心是词法扫描+栈式执行
• 字符串的边界由「起始标记+转义处理+第一个未转义的结束标记」决定，和内部的括号数量无关
• 操作符是预定义的关键字，解析器在词法拆分阶段就会把它们和操作数（字符串、数字等）明确区分开

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