把一张 DWG 直接拖进 ArcGIS，属性表里刷出来二十几列英文，Entity、Handle、LinetypeScale 混在一起，很多人第一反应是发懵。我带过几个新人，几乎每个人都会问同一句话：这些字段到底哪些有用、哪些能删、哪些能拿来筛选。说白了，ArcGIS 里的 CAD 字段就是 AutoCAD 实体属性在 GIS 侧的一份“翻译稿”，它决定了你后面能不能按图层批量提取、能不能按颜色还原出图风格、能不能用句柄追溯回原图。这篇内容适合三类人看：刚接手 CAD 转 GIS 的制图与规划从业者、需要批量处理图纸的数据工程师、以及被注记乱码和面要素消失折腾过的老手。我不讲教科书式的字段定义，直接把每个字段的真实取值规则、转换前后的变形、以及能直接抄的实操脚本摊开讲。

1. 先搞清 CAD 在 ArcGIS 里被拆成了什么

1.1 一次读取，四个要素类，图层躲进了字段里

这是理解所有 CAD 字段的前提，也是最多人绕不过去的第一个弯。你把一个 DWG 拖进 ArcGIS，展开那个数据集，看到的不是“道路层”“标注层”“水系层”，而是 Point、Polyline、Polygon、Annotation 四个要素类。也就是说，CAD 里的几何类型被提升为一级容器，而 CAD 里最直观的图层划分，被压缩成了一个叫 Layer 的文本字段。

这个设计带来的直接后果是：你没法通过“打开某个图层”来筛选数据，只能通过 Layer 字段做定义查询。想只看道路中心线，写Layer = '道路中线'；想排除图框，写Layer <> '图框'。而在 ArcMap 的内容列表里展开 CAD 要素类时看到的那些按图层分组的小图标，本质上是软件按 Layer 字段自动做的一次分组渲染，不是真的存在那么多个要素类。

我见过有人为了把 CAD 的每个图层拆成独立文件，手动一个一个做筛选再导出，几十个图层能耗掉一整个下午。这个动作完全可以批量化，第 4 节会给脚本。先把这层关系想明白：几何类型是“壳”，Layer 是“标签”，其余字段全是贴在实体上的属性。

1.2 为什么不按图层拆要素类

有人会质疑，按图层拆不是更符合 CAD 用户的直觉吗。站在 GIS 的角度，这个选择其实很合理。CAD 图层数量是不受控的，一张市政图几十上百个图层很常见，如果每个图层都生成一个要素类，数据源一加载就是几百个条目，符号系统、坐标系统、字段结构全部要重复管理，性能也扛不住。

统一成四类之后，字段结构是固定的，符号化可以按 Layer 做唯一值渲染，一次配置就能覆盖所有图层。代价就是所有“按图层操作”的动作都得落到 SQL 或者游标上。

还有一个隐性好处：同一图层里混着不同几何的情况在 CAD 里极其普遍，一条“围墙”图层里既有线又有块参照。如果强行按图层拆，这些混合几何就得处理成多要素类，反而更乱。按几何类型拆，天然就把这类问题解决了。

注意：如果你的业务强依赖“一个图层一个文件”，正确的做法是转成地理数据库之后，用 Layer 字段做要素类转要素类，而不是在 CAD 数据集上反复折腾，因为 CAD 源是只读的。

1.3 只读属性带来的一连串限制

CAD 数据集在 ArcGIS 里是只读的。这句话的含义比字面上更重：不只是图形不能编辑，字段值也不能改，连字段本身都不能删。你打开属性表，那些列全部是灰的。

这个限制会引出三个实操上的连锁反应。第一，任何字段清洗、改名、赋值都必须先转成地理数据库要素类或 Shapefile。第二，CAD 要素类的 ObjectID 是运行时生成的，刷新数据源、重开工程都可能变化，绝对不能拿 ObjectID 当业务主键，要唯一标识只能用 Handle。第三，多个 DWG 想合并成一张表，必须先转 GDB，否则你只能一个个加载再合并，字段对不齐的概率极高。

我在一个道路改造项目里就吃过这个亏。当时图省事，直接在 CAD 要素类上做符号化配置，想着反正只是出图。结果甲方中途换了一版图纸，文件名没变但内容全改了，ObjectID 重排，之前配好的个别要素覆盖样式全部错位。后来改成先转 GDB、用 Handle 建唯一索引，再没出现过这种问题。

2. 逐个拆解 CAD 标准字段的真实含义

2.1 Entity：判断几何来源的第一道开关

Entity 是整张表里信息密度最高的一个文本字段，它记录的是这个要素在 CAD 里原本是什么实体。常见取值包括 Polyline（轻量多段线）、Polygon（闭合多段线或面域转成的面）、Point（点实体）、Insert（块参照）、Text 与 MText（单行与多行文字）等等。

这个字段最大的价值在于它能告诉你几何是怎么来的，从而判断数据质量。举个典型场景：一个“建筑轮廓”图层，正常情况下应该全是 Polygon。如果你查一下Entity = 'Polyline'发现有几十条，那多半是画图的人没闭合，或者用直线一段段拼的。这些线在 CAD 里看着像闭合的，但 ArcGIS 认不出来，自然也不会生成面。

另一个高频用途是识别块参照。CAD 里的块在 ArcGIS 里会退化成一个点要素，Entity 值为 Insert，块的内部图形完全看不到。想在 GIS 里看到块的形状，只能在 CAD 端先炸开（Explode）再导出，或者用面提取的方式处理。

需要提醒的是，不同版本的 ArcGIS 对同一种实体的命名可能存在细微差异，比如文字实体在注记要素类里的取值，各版本表现不完全一致。用之前先打开字段视图，对着实际数据看一眼，别照抄网上的字段值列表。

2.2 Layer：唯一的图层抓手，也是中文最容易出事的地方

Layer 字段存的是 CAD 图层名，原样保留，包括中文、空格、特殊符号。它是你在 CAD 数据集上能做定义查询的唯一可靠字段，也是转 GDB 之后做分类统计、批量拆分的主要依据。

这里有个细节值得说：CAD 图层名允许出现|、$、-这类字符，某些老图纸还会用$0$前缀表示匿名块图层。这些名字在 ArcGIS 里能正常读取，但一旦你把它用作文件名、要素类名或者 SQL 的字符串条件，就可能出问题。我的习惯是转 GDB 之后统一做一次图层名清洗，把特殊字符替换成下划线，原值另存一个字段保留。

中文图层名的风险主要在编码环节。图纸如果在不同语言环境的机器之间流转过，Layer 字段可能出现乱码。判断方法很简单：打开属性表看图层名是否变成一堆问号或者生僻字。如果只是个别字段乱码而图形正常，基本可以定位到编码问题；如果整个属性表都异常，那更可能是文件本身损坏。

提示：CAD 数据源的文件路径同样建议用纯英文。路径里带中文或者空格，在某些版本的批处理工具里会直接报错，这个坑很隐蔽，因为手动打开完全正常。

2.3 Color 与 Linetype：符号化字段的取值规则和你想的不一样

Color 字段是整型，但它存的不是 RGB，而是 AutoCAD 颜色索引（ACI）。取值范围 0 到 256，其中0 表示 ByBlock（随块），256 表示 ByLayer（随层），1 到 255 才是具体的索引颜色。这一点极其关键，很多人看到 Color 字段里一大片 256，以为是空值或者默认值，其实它的意思是“这个实体的颜色由所在图层决定”。

这就解释了为什么你按 Color 做唯一值符号化，出来的图一片灰白——因为绝大多数实体的 Color 都是 256，真正有意义的颜色信息藏在图层定义里，而图层的颜色 ArcGIS 是不会单独给你的。想让颜色可用，要么在 CAD 端把颜色改成具体索引色，要么在 GIS 侧根据 Layer 手工配一套调色板。

真彩色（RGB）实体的表现更麻烦。CAD 里可以给实体指定任意 RGB 值，但 ArcGIS 的 Color 字段只能存索引值，真彩色实体在这个字段里往往退化成近似索引或者 0/256。这是个无解的结构性问题，只能靠前期规范：出图前要求 CAD 端统一用索引色，别在关键图层上用真彩色。

Linetype 是文本字段，存线型名，比如 Continuous、Dashed、DASHED2 之类。注意 CAD 的线型名通常是大写，ArcGIS 读取时个别版本会做大小写转换，做唯一值统计时可能出现DASHED和Dashed被当成两个值的情况，清洗时统一转小写比较稳。

LinetypeScale 是双精度浮点，对应 CAD 的全局线型比例因子。这个值直接影响虚线间隔的疏密，做图纸还原时有用，但对 GIS 分析基本没意义。

2.4 Handle、Elevation、Thickness：身份标识与第三维信息

Handle 是 CAD 实体的句柄，一个十六进制字符串，在同一个 DWG 文件内唯一。它是我认为整个字段列表里最被低估的一个。

为什么重要？因为它是唯一一个能稳定回溯到原图的标识。前面说过 ObjectID 不可靠，而 Handle 由 CAD 自己生成，只要图纸不重新生成，句柄就不变。用它可以在“GIS 发现问题 → 回 CAD 定位实体”这条链路上省掉大量时间。我在做数据质检时，会把有问题的要素 Handle 导成一个清单，交给制图方，他们直接在 CAD 里用句柄定位，比描述“第三张图右下角那条线”高效得多。

Elevation 是实体的标高，对应 DXF 组码 38，也就是 2D 多段线所在的 Z 平面高度。很多人以为这个字段能替代 Z 值，其实要分情况：2D 多段线的所有顶点共用一个 Elevation，而 3D 多段线的 Z 值存在每个顶点上，Elevation 字段可能恒为 0。判断数据到底有没有高程，最直接的办法是看要素类属性里有没有勾选“包含 Z 值”，而不是看 Elevation 字段。

Thickness 是拉伸厚度，对应组码 39，表示实体沿法线方向拉伸的高度。二维制图里这个值通常是 0，只有做三维建模时才有意义。LineWeight 是线宽，注意它的单位是 0.01 毫米，字段里存 25 表示 0.25 毫米，别直接当毫米用。

下面这张表是我常用的速查，字段名以实际读取为准，不同版本可能有增减：

2.5 Annotation 专属字段：注记能不能用，全看这几个

Annotation 要素类是四个里面最特殊的一个，它只有文字，字段结构和另外三个完全不同。核心字段包括 Text（文字内容）、TextSize（字高）、TextAngle（旋转角）、TextJustify（对齐方式）、Font（字体名）、FontStyle（字形）。

Text 字段有长度限制，超长文字会被截断，多行文字（MText）在部分版本里支持不完整，可能只读到第一行或者干脆读不到。我遇到过一张图纸的所有说明文字都是 MText，导入后 Text 字段全空，最后只能让制图方在 CAD 里把多行文字炸成单行文字重新导出。

TextAngle 的单位是个必须实测的坑。AutoCAD 的 DXF 组码 50 用弧度表示旋转角，而 ArcGIS 侧的 TextAngle 单位在不同版本里处理方式不一致，你可能会看到 1.57 这种明显是弧度的值，也可能看到 90 这种明显是角度的值。判断方法很土但有效：找一条你确定是 90 度的竖向标注，看字段值是多少，一眼就清楚了。

Font 字段存的是字体文件名，比如 simsun.ttc。这个字段的意义在于排查乱码——如果 Text 内容正常但显示成方块，是字体缺失；如果 Text 内容本身就是乱码，是编码问题，两者处理方式完全不同。TextJustify 用一个整数编码表示对齐方式，0 到 15 之间，业务上基本用不到，做注记还原时才有价值。

3. 字段在不同流转环节里的变形记

3.1 CAD 直读与 CAD 转地理数据库，字段名会变

很多人以为转成 GDB 之后字段还是一模一样，实际上会用“CAD 转地理数据库”工具处理之后，输出要素类的字段结构发生了明确变化。最典型的是新增了两个字段：CADType记录实体类型（替代原来的 Entity），DocPath记录源文件路径。

DocPath 这个字段是批量作业的宝藏。当你把十几个 DWG 一次性转进同一个 GDB 时，所有要素混在一起，靠什么区分来源？就是 DocPath。做数据统计、按图纸批次回溯、按来源做符号区分，全指望它。如果手工一个个转，这个字段就白丢了。

另一个变化是字段类型和长度会被规整。CAD 源里的文本字段长度是固定上限，转 GDB 时可能被拉长或截断。我一般会在转完之后立刻跑一遍字段清单比对，确认关键字段（Layer、Handle、Text）没有被截断。

注意：转换工具里的“参考比例尺”参数直接影响注记要素类的字号换算。设小了注记巨大无比，设大了注记小得看不见。这个参数要和最终出图比例尺对齐，别随手填默认值。

3.2 转 Shapefile 的字段截断与曲线致密化

Shapefile 是个好东西，兼容性无敌，但它的字段限制会狠狠咬你一口：字段名最长 10 个字符，文本字段最长 254 个字符。

10 个字符的限制意味着 LinetypeScale 变成 LinetypeSc 之类，多个字段还可能因为前 10 位相同而冲突，被自动改名成 Linetyp_1、Linetyp_2，转完之后你自己都分不清哪个是哪个。文本字段 254 的上限则会让长注记直接被砍掉尾巴。

更隐蔽的问题是曲线。ArcGIS 的地理数据库支持真曲线，CAD 里的圆弧读进来会保留为圆弧段。一旦转成 Shapefile，曲线必须被打散成折线，一条平滑的圆弧可能变成上百个顶点，文件体积暴涨，后续做拓扑和叠加分析也会变慢。

我的建议很明确：中间过程一律用文件地理数据库，Shapefile 只在最终交付且对方明确要求时使用。如果必须转，先在 GDB 里把字段名改成 10 字符以内的短名，把长文本字段拆分或截断，把曲线用要素转线的方式预先致密化，别指望转换工具帮你兜底。

3.3 坐标单位与空间参考：字段解决不了的两个硬伤

CAD 文件本身没有坐标系概念，它只有图纸坐标（World 坐标）。ArcGIS 读进来之后，要素类会处于“未知坐标系”状态，你得自己定义投影。

这里有个经典的单位陷阱。国内大部分 CAD 制图以毫米为单位，而 GIS 分析普遍以米为单位。直接把 CAD 数据定义成某个投影坐标系，一条 1000 米的路会变成 1000 公里。正确做法有两种：一是在 CAD 端把图纸缩放 0.001 再导出，二是在 ArcGIS 里用要素类转要素类工具，环境里设置 XY 缩放因子 0.001。

另一个硬伤是坐标原点太远。有些图纸的 World 坐标原点在几百万米开外，导入之后图形显示异常、缩放卡顿，甚至不显示。这种情况需要把 CAD 图形整体平移到原点附近再导出，平移到 GIS 之后再用“移动”工具搬回正确位置。

这两个问题都不是字段能解决的，但它们会伪装成字段问题——比如你发现 Layer 字段只有部分要素有值，一查发现是部分图形跑到极远坐标去了，被裁剪掉了。

4. 拿字段干活：四个能直接抄的实操场景

4.1 用 Layer 加 Entity 做批量筛选与提取

这是最高频的需求：把 CAD 的几十个图层拆成独立的要素类。手工点几十次不现实，用 arcpy 循环几分钟搞定。

import arcpy import os dwg = r"C:\data\sample.dwg" out_gdb = r"C:\data\out.gdb" arcpy.env.workspace = dwg # CAD 工作空间下只有四个要素类 fcs = arcpy.ListFeatureClasses() print("读取到的要素类:", fcs) for fc in fcs: if fc == "Annotation": continue # 注记单独处理 layers = set() with arcpy.da.SearchCursor(fc, ["Layer"]) as cur: for row in cur: if row[0]: layers.add(row[0]) for lyr in layers: safe_name = lyr.replace("|", "_").replace("$", "_").replace("-", "_") out_fc = os.path.join(out_gdb, f"{fc}_{safe_name}") # 用要素类转要素类，通过 SQL 表达式过滤 arcpy.conversion.FeatureClassToFeatureClass( fc, out_gdb, f"{fc}_{safe_name}", where_clause=f"Layer = '{lyr}'" )

这段脚本的核心思路是先遍历 Layer 拿到底有哪些图层名，再逐个用 SQL 过滤导出。注意 where_clause 里的字符串拼接，如果图层名里带单引号会直接崩，严谨的做法是用arcpy.AddFieldDelimiters处理，或者先做一次字符替换。

同样的思路可以用在 Entity 上。想快速找出所有未闭合的多段线，对 Polyline 要素类做Entity = 'Polyline'的筛选，再叠加一个长度校验，短于某个阈值的要素基本就是碎线，可以批量清理。

4.2 用 Handle 做主键去重与溯源

块参照的重复插入是 CAD 数据的常见问题。同一个井盖块被复制了两次、叠在同一个位置，GIS 里就是两个完全重合的点，做统计时数量翻倍。

用 Handle 去重是靠谱的做法，因为每个插入的块参照有独立的句柄。但如果想找出“几何位置相同但句柄不同”的重复项，就得先按坐标分组再比对。更实用的场景是溯源：把 GIS 里筛选出的问题要素 Handle 导成 CSV，交给制图方在 CAD 里查。

import arcpy fc = r"C:\data\out.gdb\Point_井盖" bad_list = [] with arcpy.da.SearchCursor(fc, ["Handle", "SHAPE@XY", "Layer"]) as cur: for handle, xy, layer in cur: # 示例：坐标落在图框外的要素 if xy and (xy[0] < 0 or xy[1] < 0): bad_list.append((handle, layer, xy)) with open(r"C:\data\handle_check.csv", "w", encoding="utf-8") as f: f.write("Handle,Layer,X,Y\n") for h, l, xy in bad_list: f.write(f"{h},{l},{xy[0]},{xy[1]}\n")

这套流程我在好几个项目里复用，效果很稳。制图方拿到 Handle 列表，在 CAD 的命令行里输入(handent "句柄号")就能定位到实体，比任何文字描述都准。

4.3 用 Color 和 Linetype 还原出图样式

甲方经常提一个要求：GIS 出的图要和原 CAD 图看起来一样。这个需求单靠 ArcGIS 默认符号化基本做不到，但用字段能还原个七八成。

思路是按 Layer 做唯一值符号化，颜色不要从 Color 字段取，因为它是 256 随层。正确做法是打开 CAD，把每个图层的颜色记下来，或者用脚本导出图层颜色对照表，在 ArcGIS 里手工配一套图层到颜色的映射。线型同理，Linetype 字段能告诉你这条线是实线还是虚线，但虚线的间隔比例还得配合 LinetypeScale 调。

一个省事的技巧：在 CAD 里先把所有图层的颜色改成索引色，导出后按 Color 字段做唯一值渲染，配色能自动对应上。前提是图层内部颜色统一，别一个图层里混着好几种颜色，那样渲染出来会花。

4.4 字段清单盘点：接手陌生图纸的第一件事

拿到一份别人做的 CAD 图，别急着画图，先花五分钟做一次字段盘点。这个习惯帮我避开了无数次返工。

要盘点的内容就三样：每个要素类有哪些字段、Layer 有多少个唯一值各有多少要素、Entity 的类型分布。这三项能快速告诉你数据质量如何——图层数超过两百通常意味着图层管理混乱，Entity 里混着 Insert 和 Polyline 说明图层没有按几何类型分层。

import arcpy from collections import Counter dwg = r"C:\data\sample.dwg" arcpy.env.workspace = dwg for fc in arcpy.ListFeatureClasses(): desc = arcpy.Describe(fc) print(f"=== {fc} | 几何类型: {desc.shapeType} | 要素数: {arcpy.GetCount_management(fc)}") fields = [f.name for f in arcpy.ListFields(fc) if f.type != "Geometry"] print("字段:", fields) if "Layer" in fields: with arcpy.da.SearchCursor(fc, ["Layer"]) as cur: for k, v in Counter(r[0] for r in cur).most_common(10): print(f" {k}: {v}")

跑完这段，图纸的家底基本就清楚了。再决定哪些图层要提、哪些要删、哪些需要人工核对，心里有数。

5. 常见问题与排查实录

5.1 注记读不出来或者全是乱码

这是出现频率最高的问题，成因至少有四种，得逐一排除。

第一种，注记是 MText 多行文字，版本兼容问题导致读不到内容。验证方法是打开 CAD，看这些文字是不是多行文字实体。解决办法是让制图方炸成单行文字，或者在 CAD 里用文字转换命令批量处理。

第二种，字体缺失。Text 字段有内容但显示成方块或者问号，说明字体文件在系统里找不到。这时候改字段没用，得装字体或者把文字样式换成通用字体。

第三种，编码不匹配导致内容本身是乱码。这种情况 Text 字段里就是一堆异常字符。处理思路是把图纸另存为兼容性更好的 DXF 版本，或者统一在相同语言环境的机器上做导出。

第四种，注记要素类的参考比例尺设置不当，字小到看不见，误以为没读出来。这个最容易排查，把参考比例尺调大调小试一下就知道。

5.2 明明看着是闭合的面，转过来却没有

这是 CAD 与 GIS 的几何认知差异导致的。ArcGIS 生成面要素的条件比较严格：必须是首尾点完全重合的闭合多段线，或者 Hatch、面域这类本来就是面的实体。视觉上看着闭合但差了几微米的线，一律不会生成面。

排查方法很直接：打开 Polyline 要素类，对 Entity 做统计，如果面图层对应的线大量落在 Polyline 里，基本可以确认是闭合问题。处理手段有两种，一是在 CAD 端用闭合命令修复，二是在 GIS 里用要素转面工具，把线强制转成面，但要注意容差设置，容差太大会把不该连的线连起来。

还有一种情况是面确实生成了，但落在 Polygon 要素类里被其他数据盖住了，缩放范围看看就能确认。

5.3 字段是空的、字段少了、字段名对不上

三个症状对应三类原因。字段全空但图形正常，通常是数据源损坏或者读取时编码异常，换个文件版本重新导出试试。字段数量比预期少，最常见的原因是 CAD 文件里压根没有这类实体，比如没有块参照，Point 要素类就不会有 Insert 相关的值；也可能是版本差异导致某些字段不再单独暴露。

字段名对不上，八成是经过了中间转换。转 Shapefile 会被截断成 10 字符，转某些格式会被自动重命名。做字段比对时永远以当前要素类的实际字段清单为准，别拿记忆里的列表对照。

下面这张表是我整理的高频问题速查，遇到问题先扫一眼：

5.4 几条踩过坑之后才明白的经验

第一条，不要试图在 CAD 数据集上做任何持久化的工作。符号化配置、字段计算、数据清理，全部先转 GDB。CAD 数据集就是一个临时的读取通道，把它当成只读的“预览层”来看待，心态会好很多。

第二条，接图先问三件事：单位是毫米还是米、图层命名有没有规范、有没有用外部参照和块。这三个问题问清楚，能省掉后面 80% 的返工。我现在的习惯是拿到图纸先跑一遍 4.4 节的盘点脚本，把结果发给制图方确认，双方对齐之后再动手。

第三条，Handle 列表要养成随手导出的习惯。每次做完质检，把问题要素的句柄存一份 CSV 归档，后期扯皮的时候这就是证据。文件名带上日期和图纸版本号，比什么记忆都可靠。

第四条，别迷信网上抄来的字段值列表。CAD 版本、ArcGIS 版本、文件编码，任何一个变量都会让实际取值产生偏差。花三十秒打开字段视图看一眼真实数据，永远比查文档快。

第五条，如果项目周期长、图纸会反复更新，建议在 GDB 里建一套固定的字段映射规则：Layer 清洗后的标准名、Handle 唯一索引、来源图纸批次号。这套规则一旦定下来，后面每一版图纸都按同样流程走，数据可比性会好非常多。

这套东西说穿了不复杂，难的是每次都按规矩来。我前几年图快，跳过转换直接在 CAD 源上操作，前后返工的时间够我把整个流程重做三遍。现在宁可多花半小时做规范化转换，也不愿意在中途被数据问题打断。