PDFiumSharp是.NET 6+下最轻量可靠的PDF文字提取方案,需启用EnableCJKFontFallback支持中文,直接调GetTextPage.GetText()获取文本,避免OCR或误编码;加载耗时高,应缓存PDFDocument实例。

用 PDFiumSharp 读取 PDF 文字最轻量可靠
直接说结论:C# 原生不支持 PDF 解析,System.IO 或 StreamReader 打开 PDF 文件只会读出乱码或二进制垃圾——PDF 是结构化容器,不是纯文本。目前在 .NET 6+ 环境下,PDFiumSharp(基于 Google PDFium)是兼顾准确性、跨平台支持和维护活跃度的首选,比 iTextSharp 更少 License 风险,比 PDFBox(需 JVM)更干净。
常见错误现象:File.ReadAllText("x.pdf") 返回一堆不可读字符;用 FileStream + StreamReader 指定 UTF-8 也无效;甚至误以为 PDF 内容像 HTML 一样可正则提取。
- 必须通过 PDF 渲染引擎或解析器访问文字层,不能当文本文件读
-
PDFiumSharp需要预编译原生依赖(Windows/macOS/Linux 各有对应.so/.dylib/.dll),NuGet 包会自动处理,但首次运行可能报DllNotFoundException——检查项目是否启用SelfContained发布或确认运行时架构匹配(x64/x86/ARM64) - 不要用
PDFiumSharp的RenderPageToBitmap再 OCR 提字——这是绕远路,且精度差、性能低;直接调GetTextPage+GetText即可获取逻辑顺序文字
GetTextPage 返回的文字顺序不等于视觉阅读顺序
PDF 没有“段落”概念,文字按绘制指令流排列。GetTextPage.GetText() 默认返回的是内容流顺序(类似 PostScript 绘制路径),常导致标题在正文后面、表格文字错行、中英文混排断点异常。
使用场景:做全文搜索、关键词高亮、基础摘要还行;但要做结构化提取(如识别章节标题、提取表格字段)必须后处理。
- 用
GetTextPage.GetCharBBox(i)获取每个字符边界框,再按 Y 坐标分“行”,X 坐标排序拼接,才能逼近人眼阅读顺序 - 中文字体缺失时,
GetText()可能返回空字符串或方块 —— 确认 PDF 内嵌字体,或改用GetTextPage.GetTextWithPositions()拿原始 Unicode 码位 - 扫描型 PDF(图片 PDF)无法提取文字,
GetTextPage返回空,需先判断page.TextPage != null,否则会 NullReferenceException
中文支持的关键配置:字体回退与编码处理
很多 PDF 中文显示正常,但 GetText() 返回空或乱码,问题不在代码,而在 PDF 自身字体描述缺失或 PDFiumSharp 默认未启用 CJK 回退。
参数差异:PDFDocument.Load() 接收一个 PDFLoadOptions 实例,其中 EnableCJKFontFallback = true 必须显式开启,否则遇到未嵌入的宋体/黑体/思源黑体等,文字直接丢弃。
- 即使开启了
EnableCJKFontFallback,若 PDF 使用自定义 CID 字体且未声明 ToUnicode 表,仍可能漏字——这时只能靠 OCR 补充,别硬扛 - 不要手动对返回文字做
Encoding.UTF8.GetBytes()再转回字符串——GetText()已是合法 .NETstring,再编码是典型双解码错误 - 某些银行 PDF 用“文字隐藏+白底盖章”防复制,
GetTextPage能取到字,但位置被偏移或透明度设为 0 ——需结合GetCharBBox和GetCharProperties过滤掉Opacity == 0的字符
性能瓶颈在 PDFDocument.Load(),不是提取本身
加载一个 50 页含图 PDF,Load() 耗时可能达 1–3 秒;而后续每页 GetTextPage + GetText() 通常在毫秒级。很多人误优化提取逻辑,其实该优化加载和复用。
性能影响:频繁 new PDFDocument() + Load() 是最大雷区;PDFDocument 是非线程安全、不可重入的,但可跨线程只读访问已加载实例。
- 对同一文件反复提取,缓存
PDFDocument实例(注意Dispose()时机,别内存泄漏) - 批量处理多个 PDF 时,用
Parallel.ForEach没问题,但每个任务内必须独占一个PDFDocument,不能共享 - 别在 ASP.NET Core Controller 里每次请求都
Load()—— 改用IMemoryCache缓存已加载文档(加MemoryCacheEntryOptions.SlidingExpiration控制内存)
真正难的从来不是“怎么写那几行代码”,而是判断当前 PDF 属于哪一类:是标准文字型、扫描混合型、还是防提取型。不同类别,GetTextPage 是否可用、要不要 fallback 到 Tesseract、是否值得投入坐标分析,决策点都在打开文件头后的前 100 字节和第 1 页的 TextPage 是否为空——这一步跳过,后面全白忙。










