pdfcpu提取中文文本需配置fontmap.yml指定中文字体绝对路径，嵌入字体时无效；Go调用需设Conf.FontMapFile，返回文本页间以"\f"分隔；unidoc过重且有许可限制；加密PDF仅owner密码阻断提取。
pdf
cpu 提取文本时中文乱码怎么办
默认不支持中文，因为 pdfcpu 内置字体映射没覆盖常见中文字体（如 Adobe-GB1、GBK），直接调用
会把中文转成空格或方块。
必须显式指定字体映射配置文件：用
参数传入自定义
至少要包含一条匹配规则，例如
（macOS）或
（Windows）
路径必须是绝对路径，相对路径在 pdfcpu 中会被忽略
如果 PDF 使用了嵌入字体（Embedded Font），
无效，得先用
检查是否含嵌入字体；有则需换库（如 unidoc）或预处理剥离字体
用
golang
调用 pdfcpu 提取文本的最小可行代码
别直接 exec.Command 包一层就完事——pdfcpu 的 Go API 是纯函数式设计，不暴露底层 reader，但支持从
加载 PDF，更可控也更省内存。
导入
和
用
，传入
（关键：设置
）
输入必须是
或
，不能是网络流（
需先
）
返回的
是按页拼接的，每页之间用
分隔，不是
，注意切分逻辑
为什么 github.com/unidoc/unipdf 不适合轻量 CLI 工具
unidoc 的 Go SDK 功能全，但对简单文本提取来说太重：许可证限制、编译慢、二进制体积大、运行时依赖多。
Nano Pdf
使用 nano-pdf CLI 通过自然语言指令编辑 PDF 文件。
下载
免费版只支持 200 页/天，超限后
会静默返回空文本，无明确错误提示
必须调用
，否则部分 PDF（尤其带加密或非标准结构）会 panic 报
编译出的二进制含大量未使用的渲染/图像模块，Linux amd64 下轻松破 40MB，而 pdfcpu + fontmap 可控在 8MB 内
它默认把换行符标准化为
，看似友好，但实际会合并原文档中因排版产生的“假换行”，导致段落粘连
PDF 加密时 extract text 失败的快速判断和绕过
不是所有加密都阻止文本提取。pdfcpu 会区分 owner password 和 user password，只有 owner password 才真正限制内容操作。
立即学习
“
go语言免费学习笔记（深入）
”；
用
查看输出里是否有
和
如果只是 user password（打开密码），传入
即可继续提取，无需解密 PDF 文件本身
如果 owner password 锁死了文本权限，且你没有密码，基本无解——Go 生态里没有开源库能绕过 AES-256 权限位
别试
后再喂给 pdfcpu：qpdf 会重写对象流，某些 PDF 经此处理后反而触发 pdfcpu 的 strict mode 报错
pdfcpu 的 fontmap 机制看着麻烦，但它是目前 Go 生态里唯一能把中文字体映射、权限检查、内存控制三者稳住的方案。真要支持嵌入字体 PDF，就得接受加一层 OCR 的现实——那已经不是“文本提取”而是“文档理解”了。
pdfcpu extract text-ffontmap.ymlfontmap.ymlAdobe-GB1: /System/Library/Fonts/PingFang.ttcSimSun: C:\Windows\Fonts\simsun.ttcfontmap.ymlpdfcpu validateio.Readergithub.com/pdfcpu/pdfcpu/pkg/apigithub.com/pdfcpu/pdfcpu/pkg/pdfcpuapi.ExtractText*pdfcpu.ConfigurationConf.FontMapFile = "/path/to/fontmap.yml"bytes.Readeros.Filehttp.Response.Bodyio.ReadAllstring"\f""\n"cfg := pdfcpu.NewDefaultConfiguration()
cfg.FontMapFile = "/etc/fontmap.yml"
text, err := api.ExtractText(bytes.NewReader(pdfData), nil, cfg)pdf.Reader.Readlicense.SetLicenseKey"invalid object number""\n"pdfcpu validate -v input.pdfEncrypted: truePermissions: ... text extraction denied-pw yourpassqpdf --decrypt"invalid xref"