PDF 的边界：文本型与扫描型，以及 OCR 之外的事
在 Everything to Markdown 支持的 14 种格式里，13 种都是"结构化文档"——Word、Excel、PPT、RTF、EPUB、ODF、CSV，它们的内容本来就是可被程序读取的文字。唯独 PDF 是个异类：它不是"文档格式"，而是"页面描述格式"。这一字之差，决定了它能不能被干净地转成 Markdown。
PDF 到底存了什么
PDF 的设计目标是"在任何设备上看起来都一样"。为此，它记录的是"这一页在第 100 像素、第 200 像素处画一个字 'A'"，而不是"这一段是标题，这一行是正文"。所以一份 PDF 可能根本没有'段落'这个概念，只有一串被精确摆放的字形。
能不能转成 Markdown，关键看它属于哪一类。
两类 PDF
| 类型 | 有无文字层 | 能否本地转 Markdown |
|---|---|---|
| 文本型 PDF | 有（内嵌可选中文字） | 可以，效果好 |
| 扫描型 / 图片型 PDF | 无（每页是一张图） | 不能，需 OCR |
文本型 PDF：能转，而且转得不错
这类 PDF 内部真的存了文字，只是表达方式特殊。Everything to Markdown 借鉴的开源模型（底层用 pdf-inspector 一类本地解析器）能把文字层抽出来，再按阅读顺序还原成标题、段落、表格。你平时导出的"可复制文字"的 PDF，大多属于这一类。
扫描型 PDF：图片里没有字
扫描仪、手机拍照生成的 PDF，每一页本质是一张图片。图片里当然有"看起来像字"的像素，但程序眼中那只是颜色点阵，没有任何文字信息。要转成 Markdown，必须先做 OCR（光学字符识别），把像素"认"成文字——这一步，本地 WASM 管线并不包含。
不是工具不行，是文件本身就没有可提取的文字层。再强的解析器，也认不出一张图里"写"了什么。
为什么不做内置 OCR
有人会问：既然扫描型 PDF 这么常见，为什么不在本地一并解决？现实是：
- OCR 是重计算，且质量高度依赖模型，与"纯确定性解析"的定位不符；
- 高质量 OCR 通常要模型权重，会把"几 MB 的 WASM"变成"几十上百 MB"，违背轻量初衷；
- 扫描件常含表格、公式、手写，通用 OCR 也未必可靠，不如交给专门的 OCR 服务或工具。
所以 Everything to Markdown 的边界很清晰：文本型 PDF 本地搞定；扫描型 PDF 建议先 OCR，再转。这不是偷懒，而是把"确定能做好"和"做不好还不如不做"分开。
实用的小建议
- 导出 PDF 时，选"另存为 / 导出为 PDF（含文字）"，而不是"打印成图片 PDF"；
- 拿到一份转不出来、或转出来全是乱码的 PDF，先试试在 PDF 阅读器里能否选中文字——选不中，基本就是扫描件；
- 扫描件先用 OCR 工具（如本地 OCR 软件或在线服务）识别成文本 PDF / Word，再交给 Everything to Markdown。
小结
PDF 的"边界"提醒我们一件事：转换能力不是无限的，它受限于文件本身携带的信息。Everything to Markdown 把 13 种结构化格式和文本型 PDF 都转得很稳，而把扫描型 PDF 留给更合适的工具——这正是对"诚实"的取舍。到这里，原理系列就告一段落，希望你拖进来任何资料时，心里多一分底气。