我有两个来自 v30 的二进制 Parasolid 文件(内部建模器字符串为 3000226，模式字符串为 SCH_3000226_30000_13006)。 在其中，旧类型的嵌入式模式信息如我拥有的 Parasolid XT 格式参考的最新副本中所定义。 但是，对于实体类型 204(在 28101 架构之后引入)，嵌入式架构格式完全不同。 幸运的是，它有很多字符串，所以很容易对它的基本形式进行逆向工程：
unsigned byte: number of fields
short string: nodename
short string: description
then for each field
short string: fieldname
five bytes: maybe somehow correspond to <transmit 1/0> <node class> <n_elements> ?
byte: (field) type
byte: possibly <variable 1/0> ?
然后实体本身按预期开始。
问题是这似乎是二进制版本的可行解析，但不知道五个神秘字节实际上对应于什么，我不知道如何在 Parasolid 文本文件中实现对此的支持。 它可能是两个短整数和一个无符号字符，可能是一个 4 字节整数和一个无符号字符。 哎呀，因为在这两个例子中，我的前三个神秘字节都是零，甚至可能有一个某种字符串，在这种情况下恰好是 0 长度，在这种情况下，当然，它并不总是真正的五个字节，但在我的两个示例中恰好是五个字节。
有谁知道神秘字节中发生了什么？
此外，我假设此方案对于实体类型 204 及更高版本将处于活动状态。 我不知道的是实体类型 203。 我不相信我曾经见过带有这种类型的 Parasolid 文件。
(另外，有没有人知道为什么他们会对仅用于支持向后兼容性的功能进行非向后兼容的更改？
偶然发现了自己问题的答案。 事实证明，我应该意识到他们不会在这里进行向后不兼容的更改。 事实上，我遇到的是有记录的，只是非常糟糕。 以下是我已经弄清楚的规则：
这种"新"形式的嵌入式架构是当您具有架构 13006 中不存在的实体类型时获得的。 (所以类型185及以上，我相信。 在这种情况下，格式为
unsigned byte: number of fields
short string: type name (aka nodename)
short string: description
then for each field
short string: name
short int: ptr_class
positive integer: n_elts
if ptr_class == 0
short string: type
if n_elts == 2
logical: xmt_code
笔记：
- "对于每个字段"代码与合并的字段数据相同 在编辑序列中的插入和附加(I 和 A)代码中 版本。
- 二进制中的"正整数"类型类似于指针 索引类型，如果整数小于 32767，则为 2 个字节，并且 否则为 4 个字节。 由于我从未在这里看到过高于 2 的值， 并且无法开始想象什么样的实体会有一个固定的 大小和超过 2 到 15 个元素，我还没有实现这个 还。
- 此外，此n_elts字段似乎比 在标准架构中找到的等效n_elements字段。(这是 在上面的 n_elts == 2 测试中清晰可见 - 根据 文件格式规范，它应该是 n_elts == 1，但这在 全部。
减去我在这里的警告，这些基本说明确实出现在 文件格式的 2016 版，第 14 页。 然而， 格式完全被破坏，与 文档的较旧 V15 版本 - 应该有两个级别 项目符号点，不是一个，表格的第一行是错误的 变成了头！
我还必须注意，虽然我的代码适用于实体类型 204，但我以前似乎从未在 X_T 文件中见过新类型，这就是为什么我从未注意到代码中的这个漏洞。 所以我不能保证这在一般情况下有效 - 我所知道的是它在204型情况下有效。