C#无法直接解析STEP/IGES文件，必须依赖OCCT.NET等工业级库；STEP需处理AP版本、UTF-8路径编码、静默错误及内存释放；IGES还需手动校正单位、应对实体映射混乱。
STEP/IGES 文件在 C# 里不能直接用 System.IO 打开
它们不是文本或通用二进制格式，而是按 ISO 10303（STEP）或 ANSI Y14.26（IGES）标准组织的结构化数据，带语义层级和引用关系。C# 原生类库完全不支持解析——试图用 File.ReadAllText 或 BinaryReader 读取只会得到乱码或崩溃。
- STEP 文件常见后缀是
.stp、.step，本质是带 SECTION 和 EXPRESS schema 映射的 ASCII/UTF-8 文本，但字段顺序、引用编号（如#123 = PRODUCT(...)）、反向链接必须严格按标准解析 - IGES 文件（
.igs、.iges）更老，分 80 字符定长记录，有起始节（S）、全局节（G）、目录节（D）、参数节（P），缺一不可，且 P 节中数字常以科学计数法缩写（如1E-3），手写解析极易出错 - 所有商用 CAD 系统（SolidWorks、NX、Fusion 360）导出的 STEP/IGES 都可能启用不同 AP（Application Protocol），比如 AP203（几何+装配）和 AP242（含 PMI、轻量化），同一文件用不同 AP 解析器打开，结果可能差一个维度
必须依赖第三方 STEP/IGES 解析库，主流选型就两个
目前稳定可用、有 .NET 支持的工业级库只有 Open Cascade Technology (OCCT) 的 .NET 绑定（OCC.NET）和商业库 ACIS 的 C# 封装（如 Spatial ACIS）。开源纯 C# 实现（如 StepIo）只覆盖 AP203 子集，遇到带颜色/材质/PMI 的 STEP 文件基本挂掉。
-
OCC.NET是最现实的选择：免费、跨平台、支持 AP203/AP214/AP242，能提取拓扑（TopoDS_Shape）、几何（Geom_Curve）、元数据（TDataStd_Name），但需注意其 .NET binding 是 C++/CLI 封装，必须匹配运行时架构（x64-only，不支持 ARM64） - 别碰
netDxf或Assimp：前者只处理 DXF，后者虽号称支持 STEP，实际靠调用系统里安装的 OCCT，Windows 上默认不带，Linux/macOS 更难配，Assimp.ImportFile对.stp返回空模型是常态 - 如果项目已用 Unity 或需要 GPU 渲染，可考虑
Helix Toolkit+OCC.NET桥接，但Helix本身不解析 STEP，只是把OCC.NET导出的三角网格转成MeshGeometry3D
OCC.NET 读取 STEP 的最小可行代码要注意三处硬坑
官方示例喜欢堆砌封装，但真实项目里，光是“读进来”就卡在三个地方：路径编码、异常静默、内存泄漏。
Academic Press Release Writing
下载
学术新闻稿撰写专业工具。包含规范的五段式写作结构、全流程工作步骤、常见问题解决方案和效率提升技巧。**当以下情况时使用此 Skill**：(1) 需要撰写学术机构、科研团队的新闻通稿/宣传稿；(2) 需要将学术论文、科研成果转化为面向公众的科普性新闻稿；(3) 用户提到"学术新闻稿"、"科研宣传稿"、"论文新闻稿...
- STEP 文件路径含中文时，
STEPControl_Reader.ReadFile会静默失败——必须用Encoding.UTF8.GetBytes(path)转成字节数组再传给底层 C++，不能直接传string -
Transfer_TransientProcess的错误不抛Exception，而是存到内部日志，得主动调用TP.GetMessageList()并遍历GetMessage才能看到 “No entity found” 这类关键提示 - 每个
Handle_TopoDS_Shape必须显式调用Dispose()，否则 OCCT 内存不释放，连续读 10 个 50MB 的 STEP 文件大概率触发OutOfMemoryException
var reader = new STEPControl_Reader();
// 坑：path 必须 UTF8 编码字节流
var pathBytes = Encoding.UTF8.GetBytes(@"C:\模型\零件.step");
reader.ReadFile(pathBytes);
<p>var tp = reader.WS().TransferReader().TransientProcess();
if (tp.GetMessageList().Length() == 0) {
var shape = reader.OneShape(); // 才真正拿到模型
// ...处理后务必：
shape.Dispose();
}</p>IGES 比 STEP 更脆弱，连单位都可能错
IGES 没有强制单位字段，全靠 Global Section 中第 7 行（UNITS）和第 12 行（SCALE FACTOR）推断。但很多导出器（尤其是老版 AutoCAD）会把 UNITS 写成 1（inch），却把坐标存成 mm，导致模型放大 25.4 倍。
- 用
OCC.NET读 IGES 时，IGESControl_Reader不自动做单位校正，必须手动检查reader.Model().GlobalSection().Units()，再结合业务场景决定是否对顶点坐标乘缩放系数 - IGES 的实体类型映射比 STEP 更混乱：
128是 B-Spline Surface，144是 Trimmed Surface，但有些导出器会把曲面拆成几十个142（Curve on Surface），导致TopoDS_Face数量暴增，三角化变慢 - 别指望从 IGES 提取颜色或图层：IGES 标准里没有对应实体，所谓“颜色”只是某些 CAD 厂商加的私有扩展，在
OCC.NET里直接被忽略
事情说清了就结束。STEP/IGES 解析不是“读文件→得模型”这么线性，AP 版本、单位、内存、错误捕获，每一步都有隐性契约。没踩过坑的人，往往以为是代码问题，其实是标准理解偏差。
