在工程软件、CAD/CAM、数据互通等领域，格式转换是绕不开的基础能力。日常开发中，我们大多直接调用开源库或商业组件完成转换，很少深究内部实现。但如果抛开现成工具，从零实现一套两种格式间的可靠转换，应该遵循怎样的设计思路？
Open Cascade Technology（OCCT）作为工业级几何内核，其内置的STEP文件读写模块，给出了非常经典的架构范本。通过分析它的设计，我们可以提炼出一套通用的格式转换方法论。
一、OCCT的STEP转换：两套模型，双向映射
STEP是工业领域通用的三维数据交换标准，本质是基于EXPRESS语言定义的标准化实体集合，以文本形式存储模型的拓扑、几何与装配信息。OCCT的读取链路遵循清晰的分层执行逻辑：首先将STEP文件解析为内存中的STEP原生实体模型，通过StepGeom、StepShape等早绑定C++类完整还原STEP标准语义；再由StepToGeom层完成点、曲线、曲面等基础几何元素的等价映射，由StepToTopoDS层严格按照BRep层级（壳→面→环→边→顶点）逐步构建拓扑结构，最终输出OCCT原生的TopoDS形状对象，过程中还内嵌公差适配与模型修复逻辑，保障输出模型的有效性。
写入链路则是完全独立的逆向实现，与读取代码不存在复用关系，仅保持架构上的对称：它从OCCT原生的TopoDS形状出发，由TopoDSToStep层拆解模型拓扑层级，根据目标输出类型（如精确BREP、面片BREP、线框模型等）组织STEP拓扑实体；同时通过GeomToStep层将OCCT的Geom几何对象反向映射为STEP几何实体；最终将完整的STEP实体模型序列化为符合标准规范的STEP文件。
可以清晰地看到，整个转换体系的核心是两套完全独立的原生数据模型 + 中间的双向转换层：STEP实体模型忠实还原标准语义，OCCT几何拓扑模型服务于自身的几何计算能力，两者都不会为了适配对方而修改自身结构；所有的语义映射、数据转换、公差适配，全部集中在中间的转换层完成。同时转换层内部进一步做了拓扑与几何的解耦：几何层做纯数学映射，无状态、可复用；拓扑层负责结构组织与关系传递，只调用几何层能力，不关心几何实现细节。
这种设计带来的好处非常直接：新增一种STEP实体支持时，只需在对应层级添加实现，上层逻辑无需改动；调整拓扑构建规则时，也不会影响底层几何转换逻辑，可维护性与扩展性都很强。同时读写链路独立、分层对称，既保证了单向逻辑的清晰性，也便于同步迭代升级。
二、从零实现格式转换的通用方法论
从OCCT的设计中，我们可以提炼出一套可复用的设计逻辑，适用于绝大多数A格式到B格式的转换场景。
1. 先吃透两端模型，建立映射关系
动手编码之前，最核心的工作是彻底梳理两种格式的原生数据模型。要分别搞清楚：格式的核心语义是什么？数据分为哪些层级？有哪些实体类型？实体间的引用、共享、继承关系如何表达？
在此基础上，建立双向实体映射对照表，明确A的哪类实体对应B的哪类实体，哪些是一一对应、哪些是多对一、哪些需要近似降级处理。同时有意识地区分"数据层"（如几何定义、属性值、单位）和"结构层"（如拓扑层级、装配关系、组合逻辑），为后续分层实现打下基础。
2. 采用分层架构，严格隔离职责
一套健壮的转换模块，至少应分为三层，每层只负责单一领域的逻辑：
- 解析/序列化层：负责将磁盘文件解析为内存中的原生数据对象，或将内存模型序列化为输出文件。这一层只处理格式语法，不涉及任何业务语义与转换逻辑。
- 核心转换层：模块的核心部分，进一步拆分为数据映射和结构映射两部分。数据映射处理原子元素的等价转换，结构映射处理层级、引用、组合关系。遵循"结构调用数据，数据不依赖结构"的原则，保证底层数据映射的可复用性。
- 入口控制层：对外提供统一的调用API，封装参数配置、错误处理、结果聚合等能力，对调用者屏蔽内部实现细节。
3. 双向转换独立实现，保持架构对称
读取和写入是两条独立的单向链路，不要试图设计一套"双向通用"的转换逻辑。强制复用往往会导致边界模糊、逻辑混乱，后期维护成本极高。
正确的做法是：读取与写入各自独立实现，但保持分层结构一一对应，实体映射关系互逆，命名规范对齐。这样既保证了每条链路的逻辑清晰、易于调试，也便于同步扩展新的实体类型支持。
4. 维护实体映射表，保留共享关系
绝大多数结构化格式都存在实体共享机制：CAD模型中两个面共享同一条边，装配体中多个位置引用同一个零件，文档中多个节点引用同一份资源。如果每次遇到都重新生成目标实体，不仅性能低下，还会破坏原有的共享关系，导致目标文件体积膨胀、语义不一致。
工业级转换器的标准做法，是在转换上下文中维护一张"已转换实体映射表"：每转换完成一个源实体，就记录源实体与目标实体的对应关系；后续遇到相同的源实体时，直接复用已生成的目标实体。这一步是保证转换语义一致性的关键。
5. 内置容错机制，处理非理想输入
现实场景中的源文件，往往不严格符合标准，存在各种不规范、缺失、超范围的定义。一个可用的转换器不能只处理"完美输入"，必须设计完善的容错机制：
- 对可修复的问题，内置自动修复逻辑，尽可能输出可用结果；
- 对无法转换的实体，提供降级处理或跳过机制，避免单个实体错误导致整个文件转换失败；
- 保留完整的转换日志，记录警告与错误信息，便于问题定位与追溯。
6. 预留扩展能力，适配标准迭代
数据格式标准通常会持续更新，业务需求也会不断变化。好的转换架构应该具备良好的扩展性：新增实体类型时，只需在对应层级添加实现，无需修改上层框架；支持新版本协议时，可通过新增适配层完成兼容，不破坏原有稳定逻辑。
三、总结
格式转换的本质，从来不是"文本格式的直译"，而是数据语义的等价传递。从OCCT的STEP模块可以看到，一套优秀的转换架构，核心不在于算法多么精巧，而在于边界清晰、职责分离、分层合理。
理解这套底层设计逻辑，价值远不止于"自己从零写转换器"。哪怕日常工作中只是使用现成的开源库，这套思路也能帮我们更快定位转换问题、更合理地配置参数、更灵活地做二次开发。而当遇到小众格式、定制化转换需求时，这套方法论也能让我们快速搭出健壮、可维护的实现框架。