PDF不是"文本文件"——理解PDF的本质
很多开发者第一次接触PDF解析时，会期望像读取TXT文件一样简单地获取文本内容。但事实上，PDF是一种面向页面描述的二进制格式，它存储的不是"一段文本"，而是"在坐标(x,y)处用字体F以大小S绘制字符G"这样的绘图指令集合。PDF文件内部由对象树、交叉引用表、内容流（Content Stream）等结构组成。文本数据嵌入在内容流中，以二进制操作符序列的形式存在。
理解这个本质差异，是正确实现PDF文本提取的第一步。从PDF中"提取文本"的过程，实际上是：解析内容流 -> 识别文本操作符 -> 查找字体编码映射 -> 还原Unicode字符 -> 按空间位置重组为可读文本。
PDF内容流与文本操作符
PDF内容流由一系列操作符（Operator）和操作数（Operand）组成。与文本提取相关的核心操作符包括：
BT % Begin Text Object - 开始文本对象
/F1 12 Tf % Set Font - 设置字体F1，大小12pt
100 700 Td % Move Text Position - 移动到坐标(100,700)
(Hello World) Tj % Show Text - 显示文本字符串
0 -14 Td % 移动到下一行
[(A) 120 (B)] TJ % Show Text with kerning - 带字距调整的文本
ET % End Text Object - 结束文本对象
文本提取的第一步是解析这些操作符：BT/ET标记文本对象边界，Tf设置字体，Td/Tm控制位置，Tj/TJ输出文本内容。解析器需要维护一个"图形状态栈"，跟踪当前坐标变换矩阵、字体、字号等状态信息。
字体编码与CMap映射——CJK字符的挑战
Tj/TJ操作符输出的并不是Unicode字符，而是字体编码空间中的字符代码（Character Code）。要将字符代码还原为可读的Unicode文本，需要查找字体的编码映射表。对于西文字体，这个过程相对简单——大多数情况下使用WinAnsiEncoding或MacRomanEncoding，与ASCII/Latin-1直接对应。
但对于CJK（中日韩）字符，问题变得复杂得多。中文PDF通常使用Identity-H或Identity-V编码的CIDFont，字符代码与Unicode的映射关系存储在CMap（Character Map）表中。CMap可能嵌入在PDF文件内部（ToUnicode CMap），也可能引用外部的预定义CMap（如UniGB-UTF16-H）。如果PDF生成工具未正确嵌入ToUnicode映射，文本提取就会失败——输出乱码或空白。
using DocCore.Abstractions.Documents;
var doc = PdfDocument.Load("中文报告.pdf");
for (int i = 0; i < doc.PageCount; i++)
{
var page = doc.GetPage(i);
// ExtractText内部处理了CMap映射和编码转换
var text = page.ExtractText();
// 获取带位置信息的文本块
var textBlocks = page.ExtractTextBlocks();
foreach (var block in textBlocks)
{
Console.WriteLine($"[{block.X:F0},{block.Y:F0}] {block.Text}");
}
}
扫描件PDF——当文本提取遇到图像
并非所有PDF都包含可提取的文本数据。扫描件PDF（Scanned PDF）是将纸质文档通过扫描仪转为图像后封装成PDF格式的文件——它的每一页本质上就是一张图片，内容流中只有图像绘制指令（Do操作符引用XObject Image），没有任何文本操作符。对这类PDF执行文本提取会得到空字符串。
判断PDF是否为扫描件的简便方法：尝试提取文本，如果结果为空或极少（少于10个字符），则大概率是扫描件。此时需要切换到OCR路径：先将PDF页面渲染为图像，再通过OCR引擎识别文字。
using DocCore.Abstractions.Documents;
using VisionOCR.Abstractions.Core;
var doc = PdfDocument.Load("unknown.pdf");
var ocrEngine = new OcrEngine();
ocrEngine.Initialize();
for (int i = 0; i < doc.PageCount; i++)
{
var page = doc.GetPage(i);
var directText = page.ExtractText();
if (directText.Trim().Length > 10)
{
// 电子PDF，直接使用提取的文本
Console.WriteLine($"Page {i+1} (电子): {directText}");
}
else
{
// 扫描件，使用OCR识别
var image = page.RenderToImage(dpi: 300);
var ocrResult = ocrEngine.Recognize(image);
Console.WriteLine($"Page {i+1} (OCR): {ocrResult.Text}");
}
}
复杂布局的文本重组
PDF中的文本操作符只描述"在某个坐标绘制某些字符"，并不包含段落、列、表格等逻辑结构信息。当页面存在多栏排版、页眉页脚、侧边注释、表格嵌套等复杂布局时，简单地按照内容流顺序拼接文本，往往会得到混乱的结果——例如左栏和右栏的文字交替出现。
要正确重组文本，需要基于字符的空间位置进行聚类分析：首先按Y坐标将字符分组为行，然后按X坐标排序行内字符，检测行间距判断段落边界，识别多栏结构并按栏分割。DocCore SDK底层的PdfPig库在这方面做了大量优化，内置了多种文本提取策略（默认策略、按布局保持策略等），能够较好地应对常见的复杂布局。
双层PDF——兼顾可搜索与原貌的方案
双层PDF（Overlay PDF）是解决扫描件不可搜索问题的标准方案：底层是原始扫描图像（保留文档原貌），上层叠加一层透明的文本层（提供可搜索和可复制的文字）。这样既保留了扫描件的视觉呈现，又赋予了电子PDF的文本操作能力。
创建双层PDF的过程是：扫描文档 -> OCR识别文字及其位置坐标 -> 在PDF页面上叠加透明文本层，文字位置与图像中的原文精确对齐。智数云科技的双层PDF转换工具正是基于DocCore + VisionOCR SDK实现的这一流程。
var page = doc.GetPage(0);
var blocks = page.ExtractTextBlocks();
// 按Y坐标分组（同一行）
var lines = blocks
.GroupBy(b => Math.Round(b.Y / 14.0) * 14) // 按行高聚合
.OrderByDescending(g => g.Key) // PDF坐标Y轴向上
.Select(g => string.Join(" ",
g.OrderBy(b => b.X).Select(b => b.Text)));
foreach (var line in lines)
{
Console.WriteLine(line);
}
总结：选择正确的提取路径
PDF文本提取不是一个简单的问题，根据PDF的类型和内容特点，需要选择不同的技术路径。电子PDF使用直接解析内容流的方式，准确率最高且速度最快；扫描件PDF需要先渲染为图像再通过OCR识别；双层PDF则兼具两者优势。DocCore SDK在底层封装了这些复杂的解析逻辑，让.NET开发者可以用简洁的API完成文本提取工作，而无需深入了解PDF规范的每一个细节。
DocCore SDK让PDF文本提取变得简单
获取DocCore SDK