ASN.1 PHP解析器开发：IMPORTS、OBJECT IDENTIFIER等元素实现问询

一、IMPORTS元素的实现思路 #

1. 模块加载机制 #

• 设计模块查找策略：维护一个模块搜索路径列表（比如用户配置目录、内置标准ASN.1模块目录），当解析到IMPORTS语句时，根据导入的模块名去路径中查找对应的.asn文件。
• 递归加载与依赖管理：用一个全局集合记录已加载的模块名，避免重复加载；如果当前导入的模块还未加载，先加载该模块（包括其自身的IMPORTS依赖），加载完成后再处理当前模块的导入逻辑。若检测到循环依赖（如A导入B，B又导入A），直接抛出解析错误。
• 模块存储结构：每个加载的模块需要保存其命名空间下的所有元素（类型、值、OID、宏等），以及模块自身的标识符信息（如MODULE IDENTIFIER）。

2. IMPORTS语句的解析逻辑 #

• 语法拆解：解析IMPORTS语句时，提取三个核心信息：导入元素的类型（如TYPE、OBJECT IDENTIFIER、VALUE）、元素名称列表、来源模块名。例如IMPORTS MyType, MyOID FROM MyModule，要拆出类型（默认类型和OID都包含，除非显式指定）、元素名MyType/MyOID、来源模块MyModule。
• 元素映射与冲突处理：将来源模块中的指定元素复制（或建立引用）到当前模块的命名空间中。如果当前模块已有同名元素，需按照ASN.1规范抛出冲突错误；若支持模块前缀引用（如MyModule.MyType），则可以保留前缀避免冲突。
• 类型区分存储：不同类型的导入元素（类型定义、OID值、宏）要存储到解析器的不同数据结构中，比如类型存到类型注册表，OID存到OID映射表，确保后续解析时能正确识别。

二、OBJECT IDENTIFIER与IDENTIFIED BY的实现 #

1. 模块中OBJECT IDENTIFIER的解析 #

• 绝对与相对OID处理：模块内定义的OID分为两种：
  • 绝对OID：直接以根节点开头（如{ iso(1) member-body(2) us(840) }），解析时直接按BER/DER编码规则处理即可，无需额外拼接。
  • 相对OID：基于模块自身的MODULE IDENTIFIER中的OID前缀，比如模块的MODULE IDENTIFIER是{ iso(1) member-body(2) us(840) myModule(1) }，模块内定义mySubOID OBJECT IDENTIFIER ::= { 2 3 }，则完整OID为1.2.840.1.2.3。解析时需先读取模块的基础OID前缀，再将相对部分拼接成完整OID。
• 模块级OID存储：将模块内定义的所有OID（包括绝对和拼接后的相对OID）存入全局OID注册表，关联其名称和所属模块，方便后续引用查找。

2. IDENTIFIED BY的配合处理 #

• 映射关系存储：IDENTIFIED BY的作用是给ASN.1元素（类型、值、宏等）绑定一个OID，例如MyCustomType ::= OCTET STRING IDENTIFIED BY { myModuleOid 4 }。解析时，需要在该元素的存储结构中添加一个oid字段，记录绑定的OID值（需先解析这个OID的完整值，参考上面的模块OID处理逻辑）。
• 编码无差异：绑定OID后，元素本身的BER/DER编码规则不变——比如MyCustomType的编码还是按OCTET STRING的规则来。这个绑定的OID主要用于场景：比如在需要用OID标识类型的上下文（如类型引用的显式编码、注册到OID数据库），可以直接取出该元素关联的OID进行编码。
• 反向查找支持：如果需要支持通过OID查找对应的元素，还需要维护一个反向映射表（OID值 → 元素），方便后续解析或查询使用。

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