一份合同或报表的 PDF，正文页用识别转 Word 没问题，表格页却会转成一堆对不齐的文字。这不是识别错了，是选错了工具：逐行提取文字和还原行列结构，是两个不同的接口在做的事。

为什么转 Word 保不住表格

扫描件PDF转Word 的能力边界写得很直接：不还原版面。分栏、表格线、图片位置、页眉页脚与字体样式都会丢失，输出的 .docx 只保证文字可复制、可编辑。

对表格来说，这意味着每个单元格的文字被按行顺序摊平。原来三列十行的数据，出来后是三十行文字，靠人工再敲回 Excel。表格越密，越接近不可用。

正确的两步：先出图，再识别表格

关键点在于 表格识别转Excel 只收图片，不支持 PDF，所以必须拆两步：

  1. 用 PDF 转图片 把表格所在页导出成 JPG。每页一张图片，与识别相同的 150 DPI 口径。只需要那几页就先拆分，别整本导出。
  2. 把表格图片上传到表格识别。它按行列位置重建单元格，跨行跨列的合并单元格也会重建；一张图里识别出多个表格时按顺序排列、空一行分隔。

额度是分开算的：第 1 步走的是普通转换的每日次数（免费 5 次，VIP 会员不限），不消耗识别点数；第 2 步数的是页、扣的是点，一张图片算 1 页，而表格识别每页扣 2 点（印刷体文字入口才是 1 点/页）。所以 10 张表格图是 10 页、消耗 20 点，估量时别按「一点一页」算。

三件事必须提前知道

识别到的是文字，不是公式。 合计行、百分比都会以结果文本出现在单元格里，需要计算必须在 Excel 中重新填公式。这和 想把 PDF 里的表格变成 Excel？绕一下路，反而最快 里说的绕路逻辑是同一件事。

数字不一定存成数值。 默认按文本写入，只有能无损存成数字的内容（无前导零、不超过 15 位有效数字）才存为数值。这是故意的：长编号、身份证号、带前导零的编码一旦被当数字处理就会变形。求和发现是 0 时，参考 单元格里明明是数字，求和却是 0？文本型数字批量转回。

无边框表格容易错行错列。 印刷表格如果只有横线没有竖线，或者列间距很松，识别会猜错边界。密集小字、明显倾斜的拍摄件同理。

手写表格是另一个工具

扫描件里的表格如果是手写的，不要走这一页 —— 印刷体表格识别认不准手写内容。站内有独立的 手写表格转Excel，能力边界也不同（需要画出表格线，且该能力目前只有阿里云提供，没有备用供应商可切换）。

交接前的验收动作

合计必须重算。 挑表格里的一列求和，与图片上的小计对照；不一致说明有单元格漏识或错行。金额、数量、编号这三类内容逐个核对，不要抽查。列宽、边框、底色都不保留，交付前在 Excel 里重新排版。