企业官网建设流程全解析

arcpy 把多个 dbf 合并到 Excel，这句话我自己读着就觉得亲切，因为这是我处理 GIS 数据时最常被问到、也最常亲自动手的事。某次项目里，几十个分幅图导出的属性表要汇总成一张总表给对接方，手动打开复制一遍根本不现实，我写了个 arcpy 脚本几分钟跑完，从那以后就总结了一套固定套路。这篇博文围绕 arcpy 将多个 dbf 合并到 Excel 的完整操作展开，把三种常见方案、核心代码、参数细节和现场排错都讲清楚，适合正在用 ArcGIS 处理批量属性表的同学，也适合刚接触 arcpy 想练手的新手。

先说结论：技术本身不复杂，但如果不注意 dbf 的来源、字段命名、编码和 Excel 行数上限，写好的脚本随时可能跑出诡异的结果。下面直接进入正题。

1. 整体思路：先分清 dbf 从哪里来

1.1 别把 shapefile 的属性表当成普通表

很多人一看到文件夹里有一堆.dbf，下意识就认为它们是“表格文件”，可以直接合并。这个理解对了一半。dbf 确实是 dBase 表格式，但它同时也是 shapefile 的核心附属文件之一。一个完整的 shapefile 由.shp、.shx、.dbf、.prj等文件组成，其中.dbf专门存属性信息。也就是说，你看到的某个.dbf很可能不是一个独立表，而是一个面图层的属性表。

区分这两件事很重要。如果业务方只要属性数据，那直接合并 dbf 没问题；如果最后还需要图形、坐标或者做空间关联，那光合并 dbf 是不够的，应该直接用arcpy.Merge_management把整个 shapefile 合并，或者用arcpy.Append_management做真正的空间数据追加。我在实际项目里就遇到过这种乌龙，脚本跑完了，Excel 也交出去了，对方问我“几何字段去哪了”，场面一度很尴尬。

所以动手之前先明确一件事：你要合并的是纯粹的属性表，还是形状图层的 dbf？前者走本文这套流程，后者建议换 Merge 处理整个要素类。

1.2 三种实现方案如何取舍

围绕“多个 dbf 合并到 Excel”，常用的实现路径有下面三条：

先说官方工具方案。核心是先用arcpy.Merge_management把多个 dbf 合并成一个临时表，再用arcpy.TableToExcel_conversion导出 Excel。整个链路都在 ArcGIS 的底层代码里跑，稳定，而且对字段映射有自动处理。缺点是中间产物必须放在 gdb 里，或者至少是某个工作空间，不能直接输出到 xlsx；如果你需要自定义输出列、加一个“来源文件”字段，用官方工具反而要多配一组字段映射，麻烦。

再说 arcpy + pandas。这是我自己最常用的方案。pandas 的优势在于把表当成 DataFrame 处理，pd.concat合并时字段不齐也能自动扩展，缺的填 NaN，后面想筛选、清洗、改类型都方便。配合 arcpy 的 SearchCursor 读取 dbf，相当于绕开了很多编码和字段类型的地雷。它比官方工具多写几行代码，但换来的是极大的灵活性。

最后是 dbfread + pandas。这个方案适合完全没有 ArcGIS 环境、只有 dbf 文件的人。它不依赖 ArcGIS 许可，读 dbf 的速度也还不错。但缺点很直接：dbf 的中文编码在不同软件里可能是 GBK、ANSI 或 UTF-8，日期字段和数值类型也需要自己转，踩坑概率不低。我一般只在给外部同事写一次性脚本时用这个方案。

1.3 为什么我最终推荐 arcpy + pandas

如果你去搜类似需求，网上最多的答案就是 Merge + TableToExcel 两步走。但我实际用下来，这个组合在“单纯汇总”时确实舒服，一旦涉及“合并前想清洗一下字段”“要标记每一行来自哪个文件”“两个表的字段顺序不一致”这些场景，就会觉得不够顺手。

arcpy + pandas 的组合，本质上把问题拆成了两层：读取由 arcpy 负责，数据加工和输出由 pandas 负责。dbf 读取过程中的字段类型、编码处理是 ArcGIS 内部逻辑，基本不用担心；pandas 这边则可以做任何你想要的表格操作。举个例子，我想在最终 Excel 里加一列“来源文件”，用官方工具方案我得去构造字段映射，用 pandas 方案只需要在循环里加一行赋值。对一个经常要处理“几十个表结构还不完全一致”的人来说，这种灵活度太重要了。

2. 动手前的硬准备：环境、字段名与编码

2.1 环境依赖检查：别等代码报错才想起缺库

先说最容易忽略的第一步。用 arcpy + pandas 方案前，一定要确认当前 Python 环境里同时有arcpy、pandas、openpyxl三个库。ArcGIS Pro 自带的 Python 环境一般已经装好了 pandas 和 openpyxl，但有些精简安装或自定义环境并不一定有。

检查方法很简单，在 ArcGIS Pro 的 Python 窗口或脚本工具里执行：

import arcpy import pandas as pd print(pd.__version__) import openpyxl print(openpyxl.__version__)

如果提示ModuleNotFoundError，就打开开始菜单里的 Python 终端，执行pip install pandas openpyxl。这里我额外提醒一句：尽量不要直接往 ArcGIS 自带的 Python 环境里猛怼第三方包，优先用 conda 克隆一个虚拟环境，把项目依赖装进克隆环境里。这样可以避免哪天某个包升级把 ArcGIS 的内部环境搞坏，这是我踩过一次坑后的经验。

2.2 dbf 字段名的先天缺陷：合并前先看清列名

dbf 是一个非常老的格式，字段名有不少历史遗留限制。最直观的一点是字段名长度往往只有 10 个字符，而且老版本的 ArcMap 输出中文或超长字段名时会自动截断，甚至变成F1、F2_1这种命名。字段别名又是另一回事，你在 ArcMap 里看到的中文列名大多是字段别名，底层实际字段名可能是一堆字母加下划线。

这就导致很多人在写脚本时，凭 ArcMap 里看到的“列名”去写代码，结果 SearchCursor 直接报“字段不存在”。我的建议是，不管需求文档里写的是什么列名，先跑一段小程序把所有 dbf 的字段打印出来：

import arcpy import os folder_path = r"D:\data\dbf_files" for f in os.listdir(folder_path): if f.lower().endswith(".dbf"): dbf_path = os.path.join(folder_path, f) fields = [fld.name for fld in arcpy.ListFields(dbf_path)] print(f, fields)

这一步花不了两分钟，却能省掉后面一小时的排查时间。脚本里写字段名时，一定要以这里打出来的实际字段名为准。

2.3 编码问题：老 dbf 和新 dbf 混着来是最大隐患

编码问题属于典型的不出问题则已，一出问题就是满屏乱码。dbf 文件的编码取决于生成它的软件。老版本 ArcMap 在 Windows 中文环境下导出的 dbf，大概率是 GBK/ANSI 编码；新版 ArcGIS Pro 输出的 dbf，很多默认是 UTF-8；某些第三方 GIS 软件导出的 dbf 还可能是 Latin-1 或其他编码。

如果你用 arcpy 的 SearchCursor 去读，这一层基本被 ArcGIS 内部处理掉了，中文能正常读出来，这就是我推荐 arcpy 方案的原因之一。但如果你走 dbfread 方案，就必须在读取时指定编码：

from dbfread import DBF table = DBF(dbf_path, encoding="gbk")

问题在于，你没法保证这一堆 dbf 都是同一种编码。可能是某台旧电脑导出的 GBK，另一个同事用新软件导出的 UTF-8，放在一个文件夹里混着用。dbfread 不会自动识别，所以看到乱码别慌，先确认这个文件到底是哪个编码，再决定统一切换还是单独重新导出。我见过最稳的做法是：在合并之前，把所有 dbf 统一用 ArcGIS 环境重新读取一遍，再另存为标准表，这样后续处理就不受原始编码干扰。

2.4 输出目标：xlsx 还是 xls，先想清楚

最后还有一个细节要在写代码前定下来：输出 Excel 的格式是.xlsx还是.xls。这俩的容量上限完全不同。老版.xls格式单表最多 65536 行，而.xlsx是 1048576 行。如果你合并的数据量超过六万行，还硬要写.xls，Excel 直接报错或者截断数据，到时候都不知道丢了多少。

我现在的默认输出都是.xlsx，除非接到明确要求必须给老系统的.xls。另外，如果你需要在一个工作簿里拆分多个 sheet，用 pandas 的 ExcelWriter 可以很好控制，这个后面实操部分会讲。

3. 完整代码实现：从两步官方工具到通用脚本

3.1 官方工具写法：两步走，适合快速完成任务

如果你不需要加工字段，也不需要加来源列，只想最快速度把一堆 dbf 汇总成一个 Excel，那官方工具方案是最省事的。完整代码如下：

import arcpy import os folder_path = r"D:\data\dbf_files" workspace_gdb = r"D:\data\temp.gdb" out_excel = r"D:\data\merge_result.xlsx" # 第一步：收集所有 dbf 文件 dbf_list = [ os.path.join(folder_path, f) for f in os.listdir(folder_path) if f.lower().endswith(".dbf") and os.path.isfile(os.path.join(folder_path, f)) ] if not dbf_list: raise SystemExit("文件夹里没有dbf文件，请检查路径") # 第二步：合并所有 dbf 到 gdb 临时表 output_table = os.path.join(workspace_gdb, "all_tables") if arcpy.Exists(output_table): arcpy.Delete_management(output_table) arcpy.Merge_management(dbf_list, output_table) # 第三步：把临时表导出为 Excel arcpy.TableToExcel_conversion(output_table, out_excel) print("完成，输出：", out_excel)

这段代码有两个细节值得说明。一是arcpy.Merge_management的输出不能直接写进 xlsx，需要先落到 gdb 或某个工作空间，因为 Merge 本身是数据管理工具，它的输出必须是表或要素类。二是输出表如果已存在，要先用arcpy.Exists判断并删除，否则第二次运行会报错。

Merge 在合并时会做自动字段映射，规则简单讲就是：字段名相同的列会被合并到同一列；某一个表没有的字段，合并后这些位置的值为空。这个特性在某些场景很好用，尤其是几个 dbf 字段结构大同小异时。但如果几个表字段名不一样，哪怕含义一模一样，也会被当成不同列处理，最终 Excel 里会出现好几列内容接近但列名不同的数据，这个“同义不同名”的坑需要提前规避。

3.2 通用脚本：arcpy + pandas 的完整实现

接下来是我个人最常用的版本，也是这篇文章的核心代码。它做的事情很简单：遍历文件夹里的所有 dbf，逐个用 arcpy 读取成 DataFrame，合并后加一个“来源文件”列，最后写入 xlsx。

# -*- coding: utf-8 -*- import arcpy import pandas as pd import os folder_path = r"D:\data\dbf_files" out_excel = r"D:\data\merge_result.xlsx" # 收集所有 dbf 文件 dbf_list = [ os.path.join(folder_path, f) for f in os.listdir(folder_path) if f.lower().endswith(".dbf") and os.path.isfile(os.path.join(folder_path, f)) ] if not dbf_list: raise SystemExit("文件夹里没有dbf文件，请检查路径") all_dfs = [] for dbf_path in dbf_list: # 读取字段名列表 fields = [fld.name for fld in arcpy.ListFields(dbf_path)] # 用 SearchCursor 读取所有行 rows = [] with arcpy.da.SearchCursor(dbf_path, fields) as cursor: for row in cursor: rows.append(list(row)) # 转成 DataFrame df = pd.DataFrame(rows, columns=fields) # 加一列来源文件名，方便追溯每一行数据的出处 df["来源文件"] = os.path.basename(dbf_path) all_dfs.append(df) print(f"已读取：{os.path.basename(dbf_path)}，行数：{len(df)}") # 纵向合并所有 DataFrame merged = pd.concat(all_dfs, ignore_index=True, sort=False) # 空值统一处理，避免 Excel 里出现孤零零的 NaN merged.fillna("", inplace=True) # 写入 Excel merged.to_excel(out_excel, index=False, sheet_name="合并结果") print("合并完成，总行数：", len(merged))

逐个看几个关键点。

arcpy.ListFields用来取 dbf 的全部字段名。注意这里拿到的顺序不一定是你在 ArcMap 属性表里看到的顺序，所以后面pd.DataFrame(rows, columns=fields)这一步必须把字段名和行数据一一对应。如果某些字段名是 pinyin 缩写，或者被截断成 F1、F2，这里会原样显示，正好能在合并前发现问题。

arcpy.da.SearchCursor是读取行数据的主力。它有两个优点：一是按字段名读取，不会因为字段顺序变化而出错；二是游标对象支持 with 语法，用完自动释放连接，不会把文件锁住。很多初学者喜欢用 arcpy.SearchCursor，那个老版本游标在批处理时容易锁文件，尽量别用。

rows.append(list(row))这一步看起来多余，但很关键。SearchCursor 返回的 row 对象不能直接传给 DataFrame，转成 list 以后才能正常构建表格。我在第一次写这段代码时直接df = pd.DataFrame(cursor)，结果报错，后来才意识到 row 对象不是标准集合。

pd.concat(all_dfs, ignore_index=True)是合并的核心。ignore_index=True 的作用是让合并后的行号重新从 0 开始，否则 DataFrame 会保留每个子表的原始索引，最后 Excel 里出现一堆不连贯的行号，看着很乱。

sort=False的作用是保持合并前的列顺序，不自动按字母排序。如果你不设置这个参数，pandas 在合并不同字段的表时可能会把列名自动排序，导致最终 Excel 的列顺序是乱的。

最后merged.fillna("", inplace=True)是所有数据清洗里最常用的一个操作。dbf 里的空值在 SearchCursor 读出来是 None，写进 Excel 就成了 NaN，下游的人打开表格会看到大量“NaN”字样，误以为数据有问题。统一替换成空字符串，至少视觉上是干净的。

3.3 进阶：只保留需要的字段并统一类型

实际项目中，几个 dbf 的字段结构往往不是完全一样的，可能大部分表都有NAME、CODE、AREA，但少数表多出几个无关字段，还有个别表缺某个关键字段。这时候直接pd.concat会把所有字段的并集都保留下来，最终 Excel 里出现一堆空列是常有的事。

解决办法是提前定义“要保留的字段列表”，读取时只取这些字段，同时跳过缺失字段。这样不仅能控制输出列，还能在合并前就过滤掉不必要的数据量。参考写法如下：

required_fields = ["NAME", "CODE", "AREA", "DATE"] for dbf_path in dbf_list: existing_fields = {fld.name for fld in arcpy.ListFields(dbf_path)} use_fields = [f for f in required_fields if f in existing_fields] if not use_fields: continue rows = [] with arcpy.da.SearchCursor(dbf_path, use_fields) as cursor: for row in cursor: rows.append(list(row)) df = pd.DataFrame(rows, columns=use_fields) df["来源文件"] = os.path.basename(dbf_path) all_dfs.append(df)

这段代码里的重点是我用了一个集合existing_fields来快速判断字段是否存在。因为不同 dbf 的字段名可能有细微差异，比如一个是AREA，另一个是AREA_1，如果不做这层判断，SearchCursor 会直接报错，整个脚本中断。

类型统一是另一个常见需求。dbf 里同一个含义的字段在不同表中可能是完全不同类型：A 表的CODE是字符串，B 表的CODE是数值，合并后 pandas 会把整列转成 object，虽然能用，但在 Excel 里做筛选统计时会别扭。更常见的是日期字段，有的表是真正的日期类型，有的表是文本格式的 “2024-01-01”，合并后怎么处理都麻烦。我的做法是读取后统一转换：

if "DATE" in merged.columns: merged["DATE"] = pd.to_datetime(merged["DATE"], errors="coerce").dt.strftime("%Y-%m-%d")

errors="coerce"表示遇到无法解析的值就转成 NaT，后面再统一填空字符串。这样即使某些表里日期格式五花八门，最终 Excel 里的日期也能统一成YYYY-MM-DD的字符串格式。这里要提醒一句：如果日期字段里混杂了20240101这种纯数字文本，pd.to_datetime默认会解析成正常日期，解析规则可能和你预想的不一致，最好提前判断一下格式再转换。

3.4 运行结果与性能说明

这段脚本的运行速度，主要取决于数据量和字段数量。我见过比较典型的场景是三十多个 dbf，每个几千行、十几个字段，整个流程跑下来基本几秒到十几秒，体感非常快。如果你处理的是几百个表、上百万行数据，就要关注内存了。

pandas 在合并大表时会把所有 DataFrame 同时放在内存里，数据量一大，内存占用会直线上升。碰到这种场景，我一般会改用官方工具方案，Merge 走底层 C++ 合并，比 pandas 循环读取省内存得多。或者，如果你必须用 pandas，也可以分批写入 Excel 的多个 sheet，避免一次构建超大的 DataFrame。

4. 常见问题与排查思路

4.1 字段类型不一致导致合并后列混乱

这是合并 dbf 时最典型的报错，报错信息通常是“字段类型不一致”或者“表结构不匹配”。我在实际中遇到最多的情况是：A 表的面积字段是浮点型，B 表的面积字段因为导出设置问题变成了文本型，C 表干脆没有这个字段。此时pd.concat不一定会报错，但列的类型会被自动提升为 object，统计求和时结果就很怪。

这类问题没有偷懒的办法，最实用的策略是读取时统一类型。如果你明确知道某个字段应该是数值，就在循环里先转一遍数值，转不过去的填 0 或空，再丢进合并列表。反之，如果业务上所有列都只是展示用，统一转成字符串最省事，反正 Excel 里显示效果一样。

4.2 dbf 读出来全是乱码

读出来的中文全是锟斤拷或????这种，基本可以断定是编码没对上。用 arcpy 方案时很少遇到这个情况，因为 ArcGIS 内部会按生成该 dbf 的编码规则去解析。用 dbfread 方案时乱码概率很大，尤其是各个文件来源不统一时。

排查思路是先确认单个文件的编码。可以用记事本打开 dbf，或写一小段代码尝试不同编码读取，看看哪个能正常显示中文。如果是老 ArcMap 生成的，先试encoding="gbk"；如果是新版软件生成的，试encoding="utf-8"。确认后把所有文件统一转换或重新导出，再走合并流程。别想着通过一个编码参数兼容所有文件，同一文件夹里混编码的 dbf 不能靠一次性脚本搞定，必须先统一源文件。

4.3 日期字段变成一串数字

写入 Excel 后，日期列显示成45292这种数字，实际上是 Excel 的日期序列号。这个问题的根源是你写入 DataFrame 的日期被 pandas 识别成了 datetime 类型，Excel 底层用序列号存储日期，界面显示格式不对时会直接露出序列号。解决办法有两个：要么写入前把日期统一转成字符串2024-01-01，要么写入后用 openpyxl 设置单元格格式为日期。前者更简单直接，大部分场景我都推荐转字符串。

但如果业务方需要在 Excel 里用日期函数做筛选，字符串会给后续操作添麻烦，那就用 xlsxwriter 或在 Excel 里重新设置单元格格式。这个取舍根据实际需求来，没有标准答案。

4.4 dbf 文件太多，脚本跑到一半内存不够

文件数量超过几百个，或者单个 dbf 就有十几万行时，第一版 pandas 脚本很容易内存占用过高。我遇到过最极端的情况是合并完 90 万行数据，脚本直接卡死，最后发现是all_dfs列表里保留了全部子 DataFrame 的副本。

改进思路有三个方向。第一，在循环内及时删除不再用到的临时变量，用del df释放引用。第二，不一次性合并所有数据，分批处理：每读十个文件合并一次，把结果先写入一个临时文件，最后再汇总临时文件。第三，干脆切换官方 Merge 方案，让 ArcGIS 底层做数据合并，再把最终表导出 Excel。从我的经验看，一旦总行数超过 50 万行，官方方案更稳。

4.5 Excel 行数上限：合并完才发现文件打不开

.xlsx格式单 sheet 最多 1048576 行，这个数字你可能听过，但真等脚本跑完才发现超限时就晚了。我第一次做大型合并时就踩过这个坑，脚本输出完，Excel 提示文件损坏，打不开，最后重新拆成多个 sheet 才解决。

如果你预估总行数可能接近一百万行，写脚本前就做好拆分策略。常见做法是每个 dbf 写入一个独立 sheet，或者按某个业务字段分类拆 sheet。pandas 里可以用 ExcelWriter 控制多个 sheet：

with pd.ExcelWriter(out_excel) as writer: for name, df in sheet_dict.items(): df.to_excel(writer, sheet_name=name, index=False)

这里还有个细节：sheet 名不能重复，也不能超过 Excel 的字符限制。批量生成 sheet 名时最好统一加编号，防止重名报错。

4.6 我的经验速记

最后分享几条自己摸爬滚打后留下的习惯。

合并前先把原始 dbf 复制一份到独立目录，不要直接在原始数据文件夹里反复读写。脚本写得不小心时，可能把源文件搞坏，尤其是有其他程序正开着这些 dbf 时，文件锁定导致的报错非常难排查。

脚本里每读一个文件就打印文件名和行数。现在觉得多余，但数据量大了以后，这行输出是定位问题最快的线索。某个 dbf 读出来是 0 行还是报错，一眼就能看到。

给每个合并表加“来源文件”列，是我最想推荐的一个好习惯。时间久了你会明白，它能帮你少回答无数个“这行数据是哪个文件来的”这种问题。

处理好空值。dbf 的空值在 Excel 里默认会变成NaN，下游人看不懂。合并之后统一fillna("")，观感和专业性都会好很多。

如果你只是偶尔合并一次，官方工具方案完全够用；如果以后还要反复处理类似的数据整理任务，就认真把 pandas 方案吃透，它能应对的变化比官方工具多太多。