表格、公式、多栏排版：为什么这些 PDF 内容让所有转换器崩溃？
如果你要转的 PDF 是一本纯文字小说，大多数转换工具都能给你一个还过得去的结果。
但如果你的 PDF 里有以下任何一种内容——
- 学术论文的 双栏排版
- 数学教材的 公式
- 技术手册的 代码块
- 报告文档的 表格
- 杂志或绘本的 图文混排
——那么恭喜你，你踩到了 PDF 转 EPUB 领域最大的雷区。
这些内容类型让转换质量从「凑合能用」直接跌到「完全不可用」。不是因为转换工具不行，而是因为每一种复杂排版都在挑战 PDF 格式的底层限制。
让我们逐个拆解。
挑战一：多栏排版
问题有多严重？
一位 MobileRead 论坛用户的实测：一本 129 页的多栏 PDF，转换后多栏格式 完全丢失，所有文字被合并成单栏，阅读顺序变得毫无意义。
这不是偶然——多栏排版是传统转换器最容易翻车的场景。
为什么传统方法搞不定？
传统转换器按坐标提取文本块。假设你有一个双栏页面：
左栏第1行 | 右栏第1行
左栏第2行 | 右栏第2行
左栏第3行 | 右栏第3行
转换器看到的是：「坐标 (72, 720) 有一段文字，坐标 (306, 720) 有另一段文字。」它需要决定：先读 (72, 720) 还是先读 (306, 720)？
如果按 Y 坐标排序（从上到下），它会先读左栏第 1 行，再读右栏第 1 行——但这两行根本不是连续的内容。
更复杂的情况：有些页面前半部分是双栏，后半部分变成单栏（比如参考文献部分）。有些页面第一栏比第二栏长。有些页面有跨栏的大标题。
每一种变体都需要一条额外的规则来处理，而规则之间可能互相矛盾。
AI 怎么处理？
Gemini 模型「看」这个页面时，就像一个人在看——它一眼就能认出这是双栏排版，然后按正确的顺序读取：先读完左栏，再读右栏。
它甚至能处理这些边界情况：
- 页面上半部分双栏、下半部分单栏 → 正确识别分界线
- 跨栏标题 → 识别为标题，放在两栏内容之前
- 不等长的两栏 → 不会把短栏的空白和长栏的尾部内容拼在一起
这不需要任何规则——AI 从海量文档中学会了「双栏排版长什么样」以及「应该怎么读」。
挑战二：数学公式
问题有多严重？
一个简单的二次公式 ，在 PDF 里可能被存储为几十个独立的字符，各自有不同的坐标、字号和字体。
传统转换器提取出来的结果可能是：
x = −b ± b2 − 4ac 2a
分数线没了，根号没了，上下标的位置关系也没了。这段「公式」完全不可读。
为什么这么难？
PDF 中的数学公式不是以「公式」的形式存储的——它是一堆被精确定位的字符和线条。分数线是一条水平线段，根号是一段曲线，上标是一个在较高 Y 坐标的小号字符。
传统转换器不知道这些元素之间的语义关系。它只看到：
- 坐标 (100, 500) 有字符 "x"
- 坐标 (115, 500) 有字符 "="
- 坐标 (130, 500) 有字符 "−"
- 坐标 (140, 500) 有字符 "b"
- 坐标 (155, 488) 有一条水平线（这是分数线）
- 坐标 (135, 495) 有字符 "2"（这是上标）
要从这些原始数据重建出公式的数学含义，需要极其复杂的启发式规则——而且每种数学排版系统（TeX、Word Equation Editor、MathType）生成的 PDF 结构都不一样。
AI 怎么处理？
Gemini 模型看到公式图片时，直接理解它是一个数学公式，并输出标准的 LaTeX 表示：
$$x = \frac{-b \pm \sqrt{b^2 - 4ac}}{2a}$$
这个 LaTeX 公式可以在 EPUB 中被正确渲染。AI 不需要解析 PDF 内部的字符坐标——它直接从视觉上识别出这是什么公式，就像你在看一张数学卷子。
在我们的处理流程中，还有一步特殊处理：PDF 中常见的 Unicode 数学符号（如 x²、∑、∫）会被统一规范化为 LaTeX 格式，确保在不同阅读器上的渲染一致性。
挑战三：表格
问题有多严重？
PDF 里的表格在转换后经常变成这样：
产品名称 价格 库存
笔记本电脑 6999 有货 智能手机 3999 缺货 耳机 299 有货
表格结构完全丢失，行和列的对应关系消失了。更糟糕的情况是表格和正文混在一起，完全无法区分。
为什么这么难？
PDF 中的表格不是 HTML 的 <table> 标签——它只是一堆被画在特定位置的文字和线条。
一个表格在 PDF 内部大概是这样的：
% 画表格线
0 0 500 200 re S % 画一个矩形边框
0 100 500 0 m l S % 画一条水平线
200 0 0 200 m l S % 画一条竖线
% 放置文字
BT 10 180 Td (产品名称) Tj ET
BT 210 180 Td (价格) Tj ET
BT 10 80 Td (笔记本电脑) Tj ET
BT 210 80 Td (6999) Tj ET
传统转换器需要：
- 识别出哪些线条组成了表格边框
- 根据线条交叉点推断出行列结构
- 把文字分配到对应的单元格
- 处理合并单元格、嵌套表格等特殊情况
如果表格没有显式的边框线（很多现代设计的表格用颜色交替或间距来区分行），传统方法几乎完全无法识别。
AI 怎么处理？
Gemini 视觉模型看到表格时，直接理解它的行列结构，输出 Markdown 格式的表格：
| 产品名称 | 价格 | 库存 |
|---------|------|------|
| 笔记本电脑 | 6999 | 有货 |
| 智能手机 | 3999 | 缺货 |
| 耳机 | 299 | 有货 |
即使是没有边框线的表格、有合并单元格的表格，AI 也能通过视觉对齐来识别结构——因为它在理解「这些数据之间的空间关系」，而不是在找线条。
挑战四：代码块
问题有多严重？
技术书籍和手册中的代码块，在传统转换后通常会：
- 丢失缩进（Python 代码的缩进丢了，逻辑就乱了）
- 被当成普通段落文字（和上下文混在一起）
- 等宽字体信息丢失（所有文字变成同一种字体）
AI 怎么处理？
Gemini 可以识别出代码块——通过等宽字体、背景色、行号等视觉特征——并将它们标记为代码块输出：
```python
def fibonacci(n):
if n <= 1:
return n
return fibonacci(n-1) + fibonacci(n-2)
```
缩进、空行、语法结构都被保留下来。
挑战五：图文混排
问题有多严重？
当文字环绕图片排列时，传统转换器无法区分「这段文字是图片说明」和「这段文字是正文，只是被图片推到了右边」。结果就是图片要么丢失，要么被放在完全错误的位置。
AI 怎么处理？
我们的处理流程中，Gemini 会对每个页面上的图片进行三个层次的处理：
- 检测图片位置：输出图片在页面上的归一化坐标（bounding box）
- 判断图片类型：是内容相关的插图，还是装饰性元素（logo、水印）
- 生成图片描述：用文档的原始语言为图片生成上下文相关的描述
同时，从原始 PDF 中提取高分辨率的原图嵌入到 EPUB 中，并和 AI 生成的说明文字正确关联。
真实世界的转换效果
| 复杂排版类型 | 传统转换器典型结果 | pdf2epub.ai 处理方式 |
|---|---|---|
| 双栏学术论文 | 两栏混合成一栏，阅读顺序错乱 | 正确识别栏位，按正确顺序输出 |
| 数学公式 | 变成无意义的字符碎片 | 转为可渲染的 LaTeX 格式 |
| 数据表格 | 行列结构丢失 | 转为 Markdown 语义表格 |
| 代码块 | 缩进丢失，混入正文 | 保留格式，标记为代码块 |
| 图文混排 | 图片丢失或位置错误 | 提取原图+生成描述+正确定位 |
| 脚注 | 混入正文 | 识别为脚注，正确标注 |
| 水印 | 残留在文字中 | 自动识别并去除 |
哪些 PDF 最适合用 AI 转换？
根据我们处理过的文档数据，AI 转换优势最大的文档类型是：
- 学术论文和期刊（双栏 + 公式 + 脚注 + 参考文献）
- 理工科教科书（公式 + 图表 + 代码 + 练习题）
- 技术手册和 API 文档（代码块 + 表格 + 层级结构）
- 扫描版的旧书和资料（需要 OCR + 排版重建）
- 商业报告（表格 + 图表 + 混合排版）
对于纯文字小说或简单排版的文档，传统工具已经够用，没必要为此付费。
试试你最复杂的 PDF：pdf2epub.ai 注册送免费额度。支持先转几页预览——看看 AI 处理你的表格、公式、多栏排版的效果。