PDF编码将字符164映射为braceleft而非currency的原因咨询

这种字符码对应字符名和实际显示字形不符的问题，是子集嵌入字体的典型生成缺陷，根源来自PDF格式的渲染优先设计逻辑：

• 样例中的字体为Type1格式子集嵌入字体（字体名带SUBSET前缀），绝大多数常规PDF生成器在做字体子集化处理时，仅校验「字符码→字形轮廓」的对应链路正确性——只要该链路无错，文档的屏幕显示、打印输出就不会出现视觉异常。而「字符名→Unicode语义」的映射关系不参与渲染流程，大部分生成器不会对这部分做正确性校验。
• 码位164被映射为braceleft而非标准currency，通常来自两类生成环节的bug：
  1. 编码表计算偏移：构建Differences编码差异表时，工具内部的字符索引计算出现错位，本应绑定货币符号对应/currency名称的164码位，被错误填入左大括号对应的/braceleft名称，由于该错误不触发渲染报错，会被直接保留在最终输出的PDF文件中。
  2. 源字体元数据错误：如果源文档使用的是第三方非标准自定义字体，字体文件本身的字形命名就不规范，货币符号的字形在原字体内部就被错误标记为braceleft，PDF生成器直接读取原字体的字形名填入编码表，未做语义层面的匹配校验，直接继承了源字体的元数据错误。
• 这类问题在老旧办公软件导出PDF、小型格式转换工具生成的文件中极为常见：PDF规范本身未强制要求字符名必须和字形语义完全匹配，只要渲染链路正确，文件就符合格式标准，文本提取时的语义识别错误属于生成器默认忽略的非核心场景问题。

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