7MB轻量神器File2MD：本地OCR识别，将PDF/扫描件一键转为Markdown

有一类工具属于那种“没碰到之前觉得无所谓，碰到一次就再也回不去”的类型。File2MD对我来说就是这一种——一个只有7兆左右的轻量化文档转Markdown工具，内置OCR识别能力，官方宣称精度达到98%，能把docx、PDF、扫描件图片等常见格式直接转成干净的Markdown文本。先不管这个数字是不是营销话术，单是“离线转换、7兆体量”这两个点，就足够让很多程序员把它放进常驻工具清单了。

这篇东西我想写给谁呢？主要是三类人：一是整天跟各种格式文档打交道、最后都要统一成Markdown喂给知识库或代码仓库的程序员；二是手里攒了一堆扫描版PDF和纸质资料照片、想变成可检索文本的“知识管理重度用户”；三是刚接触Markdown、被各种格式转换折腾到头疼的初学者。读完你应该能独立把File2MD用起来，并且知道什么时候该指望它、什么时候别指望它——后者其实比前者更重要。

1. 为什么是Markdown？为什么是本地轻量工具？

1.1 程序员的Markdown需求早就溢出来了

先别急着看工具，想清楚一个问题：为什么我们非得把docx、PDF、扫描件变成Markdown？

我以前写过技术文档，也维护过好几个开源项目的README。真正的痛点不是“格式转换”本身，而是格式锁死。Word文档里的样式调得再漂亮，放到Git仓库里就是一堆二进制没法diff；PDF导出之后想改一个字，得回源文件重新排版；扫描件更离谱，搜都搜不到关键词，只能一页页翻。Markdown就不一样，纯文本，能进Git，能在各种编辑器之间无缝迁移，还能被AI工具直接解析喂进去。

这两年大家把Markdown的使用场景又推远了一层：把一堆零散文档转换成Markdown，然后整体塞给大模型做RAG检索，或者迁到Obsidian、Logseq这类双链笔记工具里。我身边不少同事做知识库搬家，最耗时间的就是把老旧的docx、PDF转成格式干净的Markdown，用在线工具又担心文档内容外泄，手动复制粘贴又受不了长文档那个排版错乱。

所以说，“文档转Markdown”听起来是个小需求，放到真实工作流里它就是个绕不开的环节。File2MD这类工具能出现，本质上是把这个环节从“手动折腾”变成了“跑一条命令”。

1.2 现有方案的痛点：要么太重，要么不靠谱

市场上有现成的方案为什么不够用？我逐个踩过。

第一个是Pandoc。Pandoc确实是文档转换领域的瑞士军刀，能力强到没话说，但它有两个门槛：一是配置和使用有学习曲线，普通用户看到那一堆参数就退缩了；二是它不擅长处理扫描版PDF和图片型文档——也就是说它不解决OCR问题，而你手里的PDF十个里有三四个是扫描件。

第二个是各种在线转换网站。优点是省事，缺点是文档隐私完全暴露。你把合同扫描件、内部技术方案传到别人服务器上，就算站点承诺“不存储”，你敢信吗？我反正不敢。有些在线工具转出来的Markdown还是一堆乱七八糟的HTML标签残留，根本不能用。

第三个是大型商业OCR套件。识别能力强，体积和价格同样可观，装一个好几G，许可证费用让人肉疼。为一个“偶尔转一下文档”的需求去扛这么重的工具，属于杀鸡用牛刀。

File2MD给我的观感正好卡在“够用”和“轻巧”之间：7兆的体积意味着它不需要安装，解压就能跑，放在U盘里也行，跑在低配办公本上也不卡。它把文档解析和OCR识别集成在一个工具里，本地运行，数据不出机器，转换结果直接是可编辑的Markdown。正是“本地、轻量、一条命令搞定”这个组合，让我愿意花时间去测它。

2. 7兆体积，功能一点没缩水：File2MD的核心能力拆解

2.1 支持格式与处理策略

所谓“兼容多种格式”，不是每种格式都用同一种方式硬啃。我实测了下，File2MD对不同输入走的是完全不同的处理路径，这也是它效率高的原因之一。

值得关注的是PDF会自动区分文本层和扫描件。这个识别是自动的：如果PDF内部有可提取的文本信息，就优先走文本抽取；如果发现这一页其实是一张图片，就自动切到OCR兜底。这种“文本优先、OCR兜底”的策略很聪明，因为文本PDF的转换速度几乎是瞬间的，只有碰到扫描件才需要启动重量级的识别流程。

2.2 从docx到Markdown：不是简单去掉格式

把Word转成Markdown，技术上并不是什么黑魔法，但要做得好很考验细节。最简单粗暴的方式是把docx里所有文本抽出来拼在一起，但这样你会丢掉标题层级、列表嵌套、表格结构，转出来的东西没法用。

File2MD的做法是解析OOXML里真正控制结构的那些节点：<w:p>段落、<w:tbl>表格、<w:pPr>段落属性里的outlineLvl标题级别、列表的numPr编号属性。它把这些映射成Markdown的#、-、|等符号。我试着导入了一个带三级标题、嵌套列表和五列表格的docx文件，转换结果基本能做到“打开就能继续编辑”的程度。

当然，docx里的复杂对象是有天花板的——比如文本框、艺术字、嵌入式图表，这些在Markdown里根本没有对应的原生概念，File2MD会退化成提取里面的文本内容并放在合适位置。这一点后面我会专门讲坑，这里先有一个预期：文本信息不丢，版式细节打折扣。

2.3 7兆是怎么装下一套OCR引擎的？

这是我最开始觉得不可思议的地方。市面上正经的OCR识别程序，模型文件动辄几百兆，File2MD宣称自带OCR能力，整个包才7兆，怎么做到的？

拆解下来主要靠三板斧：量化、裁剪、字典精简。

量化是最关键的一步。现代OCR模型里的权重参数通常是32位浮点数，File2MD这类轻量工具会把模型权重压缩到8位整数（INT8），体积直接缩小到原来的四分之一，同时推理速度反而更快。代价是精度有微小损失，但配合后处理纠错，完全可以把损失控制在感知不到的范围。

裁剪是指把模型里的部分层和冗余参数去掉。OCR模型里有很多参数控制着字形风格的泛化能力，轻量化工具会针对“印刷体、常见字体、标准排版”做专项优化，把不需要的参数删掉。说白了这个工具的模式更像“手术刀”，而不是“大而全的军火库”。

字典精简更是直接：它内置的字符集主要覆盖中英文常用字、数字、常见标点，而不是试图收录全世界所有语言的字符。7兆的体积，装下的是一套“够用的泛化场景”，不是“无所不能的通用引擎”。

提示：如果你需要识别稀有生僻字、小语种、复杂手写体，就别对任何7兆级别的工具抱指望，那已经超出轻量方案的能力边界了。

这种取舍思路其实很值得学习：做一个工具，先搞清楚“谁在用、解决什么问题”，然后把不服务的场景果断砍掉。File2MD默认服务的场景就是程序员日常接触的中英文印刷文档，这个定位非常清晰。

3. 跑通全流程：从解压到输出第一份Markdown

3.1 安装：免安装就是最大的亲和力

File2MD不需要安装向导，下载下来是一个压缩包，解压之后直接能看到可执行文件。我用的是Windows版本，解压到一个目录后，双击GUI程序或者配置PATH后用命令行都能跑。macOS和Linux版本我也简单试过，前者是.app格式，后者是二进制文件，体验基本一致。

这种免安装的形态对程序员来说简直太友好了：不需要管理员权限，不需要注册服务，不需要往系统目录里写东西。你甚至可以把它放到一个专门的工具目录下，然后用软链接把命令接到/usr/local/bin里，随时调用。

3.2 命令行上手：一分钟转出第一个文件

我最喜欢的是它的CLI模式。安装好之后，最简单的转换命令就是：

file2md input.pdf -o output.md

如果输入的是扫描版PDF，需要指定走OCR：

file2md scanned.pdf -o output.md --ocr on

混合场景也可以自动处理：不指定--ocr时，File2MD会先尝试提取PDF内嵌文本，只有遇到图片页才触发OCR。这样对于“部分扫描、部分文本”的混合PDF，你不用手动切开关，工具自己会判断。

批量转换直接传一个文件夹：

file2md ./docs_batch/*.pdf --output-dir ./converted

它会把每个输入文件转换成一个同名.md文件放到converted目录下。实测下来，纯文本型PDF每份耗时基本在1秒内，扫描版PDF每页大约2到4秒（取决于图片分辨率和内容复杂度），批量场景完全可以接受。

3.3 没有命令行基础也OK：GUI三步走

如果你不喜欢敲命令，File2MD也带了图形界面。打开后的主界面非常朴素：左边选文件、右边设输出目录、中间一个“转换”按钮。

界面模式的逻辑和命令行一样，只是多了一些下拉框选项：输入格式识别（自动/强制OCR）、识别语言（中文/英文/中英混合）、输出目录、是否保留图片路径、是否合并同一文件里的多页OCR结果为单一Markdown文档。

我拿扫描版PDF试了一遍GUI：选中文件，输出目录设为桌面，语言选“中英混合”，点转换，进度条走完后生成一个带自动命名前缀的.md文件。整个过程不需要读任何使用说明，属于看一眼就会的那种。

3.4 配置参数：一条命令里的可调旋钮

File2MD的官方文档列出的核心参数不多，但每一个都值得知道用途：

• --ocr on/off/auto：主动开启、关闭或自动判断OCR。auto是默认值，文本型文档不会浪费时间。
• --lang zh/en/mix：识别语言。纯中文文档强制选zh能提高精度，反之选en。
• --dpi 300：扫描图片的处理分辨率。默认300，够用；低清晰度图片可以调到400以上但会增加耗时。
• --vertical-text on/off：竖排文字开关。识别古文、竖排书页时打开，常规文档保持关闭。
• --image-dir ./assets：Markdown中图片引用的保存目录，转出的文档图片路径全部指向这个目录。

配置除了命令行传参，也可以写在一个config.json里，工具启动时会自动读取。这个设计对需要固定工作流的人特别有用：把参数固定在配置文件里，每次双击运行就直接按你的偏好执行。

4. OCR不只是加一层：98%精度背后的识别细节

4.1 扫描件转Markdown的真正难点

很多人以为OCR就是“把图片里的字认出来”，其实远不止这么简单。一张扫描件要变成Markdown，要跨越四个层次：

• 像素层：把图片里的文字区域和背景分离开。
• 字符层：把每个文字图像块识别成对应的Unicode字符。
• 语义层：判断哪些字符组成一个段落、哪些组成一个表格、哪些是标题。
• 结构层：最终输出带标题层级、列表缩进、表格分隔符的Markdown语法。

File2MD的98%精度，主要体现在“像素层”和“字符层”。到了“语义层”和“结构层”，它做得还不错但远谈不上完美。这一点我在第5节的实测里会展示真实效果。

4.2 识别管线是怎么走的？

File2MD的OCR管线拆开看，大致是六个环节：

1. 图像预处理：把彩色扫描件做灰度化、二值化、去噪、倾斜校正。这一个步骤对最终识别率影响极大。我拿一张稍歪斜的图片测试，不开倾斜校正时识别错误明显增加，开着校正后基本都能正确识别。
2. 版面分析：先切分出文字块、表格区域、图片区域，判断阅读顺序。
3. 文字检测：在文字块内部找出每一行文字的精确位置。
4. 文字识别：用内置的轻量模型把行图像转成字符串。
5. 后处理纠错：根据词典、常见词频、上下文做候选矫正。比如“O”和“0”、“l”和“1”这类容易混淆的字符，靠上下文概率修正。
6. Markdown结构化：根据版面信息给内容套上标题、段落、列表、表格的标记。

这种管线设计中，真正对精度贡献最大的是第1步和第5步。前者是把问题变简单，后者是把识别结果变干净。很多人使用OCR工具发现效果不好，其实问题往往出在自己给的图片质量太差，预处理阶段就已经无法挽回了。

4.3 影响精度的变量

官方说98%，我的实测结论是：在清晰的印刷体扫描/截图场景下，这个数字接近真实水平；在模糊、倾斜、阴影、泼溅噪声的图片上，会掉到90%甚至更低。

有一个细节参数值得单独说：--vertical-text on。这个开关对应的是热搜里提到的“竖排/纵向阅读顺序”问题。古书、部分中文文献是竖排排版，OCR识别时必须先判断文字排列方向，再按纵向顺序读取，否则出来的文本完全是乱的。我用一页竖排繁体PDF测试，开启开关后内容顺序基本正确，比默认模式好了太多。

还有一个容易被忽略的影响因素：图片的DPI（每英寸像素数）。200DPI以下的低清扫描件，字符边缘发虚，识别率直线下降。如果原图本身就是低清的，调--dpi参数是救不回来的——那个参数只是告诉引擎“按什么分辨率处理”，并不能凭空提升图片信息量。这种时候唯一有效的办法是找更高清的源文件。

5. 三类真实文档的转换测试：表格、扫描件、混合排版

5.1 密集表格的Word文档

我拿了一份带多级表头、合并单元格的技术方案文档测试，里面有一张六列二十行的复杂表格。转出来的Markdown表格保留了表头和主要行数据，最让我满意的是合并单元格虽然没有视觉上的合并效果，但内容位置没有错乱，每一格的数据都待在对应的列里。

不过要留意，这种转换结果不是为了“原样还原”，而是为了“数据可用”。Markdown表格本身就不支持合并单元格，File2MD能做的事情是把每个格子里的文本按行列关系放进二维表结构，这就已经足够导出成CSV或者粘回Excel了。我甚至试过把转出来的Markdown表格复制到Excel里做二次处理，数据排列完全正确。

5.2 扫描版PDF

第二个测试对象是一本技术图书的扫描版PDF，共42页，中文为主，间杂代码片段。我用命令行加--ocr on批量转换，总耗时约2分钟，平均每页3秒多一点。

转换结果的文字段落在Markdown里被正确分成了段落结构，代码块我原本期待它会被识别成代码块，实际上它只是被识别成了普通文本里的等宽字符，没有被包进代码块语法里。也就是说OCR层面识别出了代码内容，但结构化层面没能识别出“这是代码”。这也不算意外，因为代码块识别的判断依据是排版模式、缩进、字体等，轻量引擎在语义分割上没做那么深。

但整体文字识别率确实高，我抽查了十来页，正文部分几乎没有错字。少数几处错误集中在代码片段里的大小写、下划线和数字上——比如O_0这种组合被认成了O0，这类错误对代码场景是致命的，使用时一定要人工过一遍。

5.3 带截图的网页导出HTML

第三个场景是把一个有大量截图的网页先存成HTML，再转成Markdown。File2MD对HTML的处理比较有意思：它会把HTML里的标题标签、<ul>列表、表格标签映射成对应的Markdown语法，同时把<img>里的图片保存到指定目录，然后在Markdown里生成相对路径的引用。

我比较担心的是图片路径问题——之前用很多工具转出来的Markdown，图片路径要么是绝对路径，要么是乱码文件名。File2MD在--image-dir参数的控制下，输出的是./assets/xxxx.png这种相对路径，配合版本控制用起来很舒服。

不过这里有个细节：如果原网页里的图片是懒加载的，HTML初始代码里并没有真正的图片地址，只是一个空的>