本页内容
先确认分隔规则，再查原生值、类型与接收软件显示
- 保留原PDF，先看表头、货币单位和地区数字约定。本例两组均为EUR，但一组用小数点，另一组用小数逗号，不能只凭货币判断标点。
- 上传PDF并完成解析，对照网页表格的六个金额。本例一次选择单页PDF、解析一次，网页文字保留了两组不同分隔写法。
- 从导出配置点击“表格 Excel”取得实际XLSX。本例点击该卡片直接生成两工作表文件，没有再点另一个开始导出按钮。
- 分别查看实际单元格的存储值与类型，再用交付软件检查显示。本例表1为数值，表2仍为文本；屏幕上都能看到金额，不表示类型相同。
- 需要统计时，先在副本中按明确的分隔与区域规则核对转换，再检查代表值、零值和计算范围。不要直接全局删除点或逗号；本轮没有做转换、公式或SUM验证。
此页展示原生导出与只读核对，没有制作转换修正版。金额的标点、数值含义、显示格式和实际计算分别检查。
同页六个金额：小数点组为数值，小数逗号组仍是文本
2026年10月19日，一页自编虚构PDF含两张表，明确不同数字分隔规则。实际上传解析并导出XLSX各一次，原生文件有表1、表2两张工作表；随后用Apple Numbers 14.4只读打开查看两组金额，没有修改格式、地区或单元格，也没有求和、保存或重开。
| 样例／源金额 | 网页识别文字 | 实际XLSX值与类型 | Numbers显示 |
|---|---|---|---|
| A17／1,234.50 | 1,234.50 | 表1 C2：数值1234.50 | 1234.5 |
| A29／12.75 | 12.75 | 表1 C3：数值12.75 | 12.75 |
| A00／0.00 | 0.00 | 表1 C4：数值0.00 | 0 |
| B17／1.234,50 | 1.234,50 | 表2 C2：文本1.234,50 | 1.234,50 |
| B29／12,75 | 12,75 | 表2 C3：文本12,75 | 12,75 |
| B00／0,00 | 0,00 | 表2 C4：文本0,00 | 0,00 |
原PDF明确的两组数字约定（金额单位均为EUR）
Group A：小数点，逗号千位分隔
1,234.50 · 12.75 · 0.00
Group B：小数逗号，点千位分隔
1.234,50 · 12,75 · 0,00- 实际XLSX为3,391字节，包含两张工作表。表1的1234.50、12.75、0.00存为数值；表2的1.234,50、12,75、0,00存为原文字，不把相同金额含义当作相同存储类型。
- 本例没有把12,75误转成1275，也没有漏掉零金额。小数逗号组仍是文本，不能由显示完整就认定已转换为可计算数值。
- 六个金额使用普通General格式。Numbers表1显示1234.5、12.75、0，而原生存储仍为1234.50、12.75、0.00；显示省尾零与数值丢失是两项不同判断。
- Numbers 14.4中六个金额均可见，导入时出现一种字体缺失提示，未更换字体。只读查看没有建立公式、SUM、排序、编辑、保存、重开或Microsoft Excel/WPS兼容结论。
仅此自编单页、两张表的分隔规则对照。没有制作数值转换修正版，也没有改变地区或格式；原生XLSX保持下载字节。三图为真实网页结果与Numbers打开画面，不能由此承诺所有外文表格、货币或电子表格软件采用同一转换规则。
先了解这几件事
PDF转Excel时，先看原表约定哪个符号是小数、哪个是千位，再分别检查网页文字、XLSX的值类型和表格软件显示。本例1,234.50导出为数值1234.50，1.234,50却仍以原文字保存；后者看起来像金额，不代表已经可用于计算。Numbers把数值1234.50显示为1234.5、0.00显示为0，也不等于原存储金额丢失。本轮没有转换或求和测试。
- 原稿口径
- 同页两组EUR金额，分别明确小数点/逗号千位与小数逗号/点千位约定。
- 原生导出
- 两个工作表：表1三金额为数值，表2三金额仍是小数逗号文本。
- 显示与存储
- 数值使用普通格式，Numbers可能省略末尾零；单元格类型与屏幕外观分别核对。
- 本轮范围
- 一次解析、一次XLSX导出及Numbers只读打开；未改地区、格式、值或测试SUM。
看起来都是金额，先分清是哪一层问题
| 看到什么 | 先核对什么 | 本例能说明什么 |
|---|---|---|
| 1.234,50仍完整显示 | 单元格类型与原表数字约定 | 本例是文本，未做数值转换或SUM |
| 1234.50显示为1234.5 | 存储值与显示格式 | 本例数值含义保持，普通显示省略尾零 |
| 0.00显示为0 | 是否是真正零值，还是未记录空白 | 本例零金额明确存在，并非丢失 |
| 担心逗号被当成千位 | 源规则、原生值与实际类型 | 本例12,75未误转1275，仍是原文本 |
PDF转Excel，先用原表说明确定小数与千位规则
点和逗号的含义取决于原表约定。本例同为EUR金额，两张表分别明确不同规则；1,234.50与1.234,50在这份原稿中表达相同数值，但不能把这种对应关系推广到所有地区或文件。
看起来像数字，实际单元格仍可能是文本
网页识别保留标点后，XLSX还要决定如何存储。表2的三个小数逗号金额是文本，屏幕显示完整不等于已可参与数值计算。本轮没有实际SUM，因此不把类型观察说成已经测得求和失败或成功。
普通格式省略尾零，不等于原金额被删减
本例表1原生值包括1234.50与0.00，Numbers显示为1234.5与0。金额数值、两位小数显示和源写法是不同要求；若交付要固定两位小数，应在自己的副本中另核显示格式，本轮没有修改或验证该操作。
转换小数逗号前，保留原稿并核对代表值
需要整理为数值时，先确认原表规则与接收系统区域设置，在副本抽查大额、小额与零值，明确转换后含义。不要只删除所有点或逗号，也不要批量改动编号列。这个样例展示原生结果，没有提供已测的一键修复或地区转换流程。
相关官方说明
常见问题
PDF转Excel小数逗号被识别成千位怎么办？
先对照原PDF约定、实际值与单元格类型。本例没有把12,75误转为1275，小数逗号组仍是原文字；文本并不等于已转换为数值。保留原稿，在副本按明确规则核对，不能仅凭屏幕上的金额认定发生同一种错误。
外文表格转Excel后1.234,50怎么核对？
先从原稿确认点是千位、逗号是小数，或是否另有约定，再查看原生XLSX的值类型。本例1.234,50保留为文本，Numbers也显示该文字，没有验证地区转换或求和。
PDF转Excel千位分隔符和小数点怎么区分？
将源表说明、单位、代表金额、原生类型与接收软件显示分开看。本例两组明确不同规则，导出后一组为数值、一组为文本。不能只按EUR或表面标点推断自动转换正确；需要统计时在副本另行验证。
内容核对：2026-10-19 · 功能条件与配额以当前产品界面为准