简介：这份文档面向需要处理加密CAD图纸的设计人员与制图学习者，聚焦多重插入引用这一常见图纸加密技术，提供可落地的炸开与解密思路。内容围绕AutoLISP脚本展开，涵盖通过加载wjjm文件、使用加密插件命令以及自定义lsp程序三种途径，并延伸讲解ENTSEL、ENTGET、DEFUN等命令在块转换中的实际用法，帮助读者理解加密块与普通块之间的结构差异。资源包共1个doc文件，约18KB，以文字说明与代码片段为主，便于随查随用。目前已有455人学习下载，适合希望摆脱图纸锁定困扰、提升CAD二次开发能力的中级用户参考，也可作为AutoLISP入门练手的实例素材。
1. 多重插入引用：为什么一个块能“炸不开”
你拿到一张图纸，选中图块，敲explode，命令行弹出一句“无法分解多重插入块”，然后就没有然后了。这不是软件抽风，也不是图纸损坏，而是这张图被人为加了一层结构性的锁。多重插入引用（MInsertBlock）在 CAD 里本来是个正经功能——它把同一个块按行列阵列重复插入，省内存、省文件体积，但正因为它的数据结构比普通块多出几个字段，就被人拿来当成了“加密”手段。搞懂它为什么炸不开，本质上就是搞懂 DXF 组码里那几个数字在管什么。这份资源围绕的就是这个机制：它不教你怎么画图，而是把“锁”和“钥匙”同时摊开给你看，让你明白加密图到底锁在哪、解锁又改了什么。
2. 多重插入引用的数据结构：锁到底加在哪个字段上
2.1 INSERT 与 MINSERT 的组码差异
在 DXF 层面，普通块引用和多重插入引用都叫INSERT实体，区别藏在组码里。普通块引用的组码 70 通常是 0，组码 71 也不参与阵列语义；而多重插入引用会把组码 70 置为 1（表示这是一个阵列），组码 71、44、45 分别承载列数、行间距、列间距。更关键的是，实体类型标记里会出现AcDbMInsertBlock这个子类标记，而不是普通的AcDbBlockReference。
常见的实现思路是：CAD 在渲染时看到AcDbMInsertBlock，就按阵列方式展开显示，但在编辑命令的分发逻辑里，explode对这类实体直接拒绝，因为阵列展开后的子实体归属关系在内部并没有被完整建立。换句话说，它不是“不让你炸”，而是“炸了之后不知道该把结果挂到哪”。这就是为什么单纯反复点分解没有任何效果——命令在入口处就被拦截了。
2.2 组码 70/71/44/45 各自管什么
把这四个组码拆开看，才能理解后面那段 LISP 为什么只改这几个位置就能解锁：
| 组码 | 普通块引用 | 多重插入引用 | 作用 |
|---|---|---|---|
| 70 | 0 | 1 | 标识是否为阵列插入 |
| 71 | 通常缺省 | 列数 | 阵列的列数量 |
| 44 | 通常缺省 | 行间距 | 阵列行方向步距 |
| 45 | 通常缺省 | 列间距 | 阵列列方向步距 |
解锁的核心动作，就是把 70 和 71 归零、把 44 和 45 归零，同时把子类标记从AcDbMInsertBlock换回AcDbBlockReference。一旦这四个字段回到普通块的状态，explode的命令分发逻辑就会把它当成普通块处理，分解自然就通了。这里有个容易忽略的点：只改组码 70 而不改子类标记，某些版本会认为实体自相矛盾，直接丢弃或报错，所以两者必须一起动。
2.3 为什么“加密”其实只是改类型标记
很多人以为加密图用了什么高深的加密算法，其实从这份资源给出的 LISP 看，所谓加密就是把普通块“升级”成多重插入块，解密就是反向降级。它依赖的不是密码学，而是 CAD 内部对实体类型的命令白名单机制。这也解释了为什么方法二里一句CYN-命令就能转换——插件做的无非也是同一件事，只是封装成了命令。理解到这一层，你就不会再把它当成黑匣子，而会把它看成一个可以被entget读出来、被entmake写回去的数据结构问题。
3. AutoLISP 解锁逻辑：entget、subst、entmake 三步走
3.1 从选择集到实体表：ENTSEL 与 ENTGET
解锁脚本的起点是ENTSEL，它返回一个列表，第一个元素是实体名（ename），第二个是点选位置。拿到 ename 之后，ENTGET把它转成关联表（association list），也就是一串(组码 . 值)的配对。这个关联表就是实体的完整“体检报告”，后面所有的修改都是在这张表上做替换。
(setq stm (car (ENTSEL "\n点取多重块"))) (setq e (entget stm)) (setq stlx (cdr (assoc 0 e)))上面三行的含义分别是：取实体名、取关联表、取组码 0 的值（实体类型）。assoc按组码查找，cdr取值，这是 AutoLISP 操作实体表的标准套路。判断stlx是否等于"INSERT"，是为了防止用户误选到直线、圆之类的非块实体，避免后续替换时把无关实体改坏。
3.2 subst 替换组码：把阵列参数抹平
真正的解锁动作集中在几个subst调用上。subst的语义是“用新值替换表中所有等于旧值的项”，所以要先assoc把旧项取出来，再拿它当匹配目标：
(setq r_zm70 (assoc 70 e)) (setq c_zm71 (assoc 71 e)) (setq r_dist_zm44 (assoc 44 e)) (setq c_dist_zm45 (assoc 45 e)) (setq e (subst (cons 44 0) r_dist_zm44 e)) (setq e (subst (cons 45 0) c_dist_zm45 e)) (setq e (subst (cons 70 0) r_zm70 e)) (setq e (subst (cons 71 0) c_zm71 e))这里把 44、45 置 0，把 70、71 置 0。注意顺序并不影响结果，因为每个subst只针对一个组码。置 0 而不是删除，是为了保持关联表结构完整，避免entmake时因为缺项而生成不合法实体。这一步做完，实体在数据层面已经“看起来像”普通块了，但还差最后一道类型标记。
3.3 子类标记替换与 entmake 重建
(setq e (subst (list 100 "AcDbBlockReference") (list 100 "AcDbMInsertBlock") e)) (entmake e) (entdel stm)组码 100 是子类标记，它告诉 CAD 这个实体属于哪个内部类。把AcDbMInsertBlock换成AcDbBlockReference，等于把实体的“身份证”换掉。随后entmake用修改后的关联表新建一个实体，entdel删掉原来的多重插入块。一建一删之间，图纸里留下的就是一个货真价实的普通块引用，explode自然不再拦截。
提示：
entmake成功后原实体并不会自动消失，必须显式entdel，否则图上会重叠出两个块，看起来像没生效。
3.4 lockb 的反向逻辑：普通块如何被“加密”
资源里还给了反向函数lockb，逻辑正好对称：把 70 和 71 置 1，把子类标记换成AcDbMInsertBlock。它没有设置 44、45 的间距，这在某些版本里会导致阵列退化为 1 行 1 列，但类型标记已经变了，explode照样会被拦。这也侧面说明：拦截判断主要看类型标记和组码 70，间距值只是渲染参数。理解这个对称关系，你就能自己判断一张图是被哪种方式锁的——用entget看一眼组码 70 和 100 就清楚了。
4. 避坑与排查：解锁过程中最容易翻车的几件事
4.1 现象：脚本加载成功，但输入命令提示“未知命令”
原因通常是 LISP 文件没有真正加载进当前文档，或者文件编码带了 BOM 导致DEFUN解析失败。解决方式是走“工具→加载应用程序”显式加载，加载后先在命令行敲函数名看是否有响应；如果仍无响应，用文本编辑器把文件另存为无 BOM 的 ANSI 或 UTF-8，再重新加载。血泪经验是：直接拖拽文件进窗口有时只加载到临时上下文，换一张图就失效。
4.2 现象：点选后命令行报“bad argument type”
这多半是ENTSEL返回了 nil（用户点了空白处或按了 Esc），而脚本没有做空值判断就直接car。原始脚本用while stm循环，但第一次ENTSEL在循环外，如果第一次就点空，stm为 nil，后续entget会直接报错。解决方式是在ENTSEL后加一句判空，或者在循环结构上把选择动作放进while条件里，让空选自然退出。
4.3 现象：转换后块还在，但 explode 依然失败
检查两点：一是组码 100 是否真的被替换，有些图纸里存在多个 100 子类标记（比如还带AcDbBlockReference之外的扩展记录），subst只替换匹配项，可能漏掉；二是块本身是否被外部参照或图层锁定，锁定图层上的块即使类型正确也无法分解。排查时先用entget把转换后的实体表打出来，逐项核对 70、71、100，再看图层状态。
4.4 现象：批量处理时部分块被跳过
原始脚本的循环依赖用户逐个点选，如果中途点到了非 INSERT 实体，if判断会跳过但循环继续，看起来像“没反应”。更隐蔽的问题是：某些多重插入块的组码 71 缺失，assoc返回 nil，subst拿 nil 当匹配目标会匹配到表中所有 nil 项，造成意外替换。稳妥做法是在subst前判断assoc结果非 nil，缺失的组码直接用append补上(cons 71 0)，而不是硬替换。
4.5 现象：解锁后图纸体积暴涨或显示错乱
entmake重建实体时，如果原实体带有扩展数据（XDATA，组码 -3）或反应器，关联表里这些项会被一并复制，但新实体类型可能不兼容这些附加数据，导致显示异常。解决方式是在重建前过滤掉 -3 组码，或者转换后对结果做一次audit检查。我一般会先在小样本图上跑一遍，确认显示正常再批量处理，避免整张图翻车。
5. 从解锁到理解：类型标记机制的设计取舍
把这段 LISP 拆完，会发现一个有意思的设计取舍：CAD 用“子类标记 + 组码组合”来表达实体语义，而不是给每种实体单独一个类型码。好处是扩展性强，新增一种块行为只需要加子类标记和几个组码，老版本读到不认识的标记还能降级处理；代价是语义分散在多个字段里，任何一个字段不一致，实体就处于“半合法”状态，命令分发逻辑只能靠白名单保守拦截。多重插入引用被拿来当加密手段，恰恰是利用了这个保守性——它不需要真的加密数据，只需要让实体落在explode的白名单之外。
这也解释了为什么解锁脚本必须同时改 70、71、44、45 和 100：只改一个字段，实体在内部校验时仍会被判定为阵列类型，拦截逻辑照旧生效。反过来，lockb只改 70、71 和 100 就能“加密”，说明拦截判断并不依赖间距值是否合理，间距只是渲染参数。理解这个不对称，你就能判断哪些“加密图”其实是纸老虎，哪些可能真的叠加了其他保护（比如外部参照绑定或代理对象）。
验证方法很直接：拿一张普通块图，用lockb转一次，再用exm转回来，对比转换前后的entget输出，看哪些组码变了、哪些没变。这个对照实验比读十篇教程都管用，因为它把“锁”和“钥匙”的差异量化了。进阶一点，可以把exm改造成批量版：用ssget按实体类型过滤出所有INSERT，循环处理，省去逐个点选。改的时候注意ssget的过滤条件要写(0 . "INSERT")，并且对每个实体单独做entget/entmake，不要在同一个关联表上反复subst。
从那以后我每次拿到来源不明的图纸，都会先用entget看一眼组码 70 和 100，确认它是不是被“升级”过的块，再决定要不要动脚本。这个习惯帮我省掉了不少反复试错的功夫。希望帮到你。
本文还有配套的精品资源，点击获取
