使用pdfcpu库从PDF提取JS对象的技术问题咨询

字节流处理支持 #

pdfcpu完全支持直接处理内存中的PDF字节流，无需将字节写入磁盘生成临时文件。
其核心处理API均以io.ReadSeeker接口作为入参，业务侧拿到[]byte类型的PDF数据流后，直接用标准库包装为bytes.Reader即可传入处理，无需任何磁盘IO操作，参考代码：

import (
	"bytes"
	"github.com/pdfcpu/pdfcpu/pkg/api"
	"github.com/pdfcpu/pdfcpu/pkg/pdfcpu/model"
)

// 业务层接收到的PDF字节流
var pdfByteStream []byte

// 包装为支持Seek操作的Reader
pdfReader := bytes.NewReader(pdfByteStream)
// 直接加载PDF到内存上下文，全程无落盘操作
ctx, err := api.ReadContext(pdfReader, model.NewDefaultConfiguration())
if err != nil {
	// 处理PDF加载错误
}

注意：不要使用bytes.NewBuffer包装字节流，该类型不支持Seek接口，会触发pdfcpu的参数校验错误。

声明式JS提取能力 #

pdfcpu提供开箱即用的JS提取能力，无需手动遍历全量PDF对象匹配内容。
按照PDF规范，内嵌JavaScript的存储位置是固定的，仅会出现在文档级打开动作、名称树JavaScript节点、页面/注释关联动作、表单字段关联动作四类位置。pdfcpu内部已经实现了所有标准位置的JS扫描逻辑，v0.4.0及以上版本直接暴露了公开提取方法，和命令行pdfcpu extract -mode js的提取逻辑完全一致，调用即可拿到全量内嵌JS：

// 返回结构为 map[JS条目名称]JS内容字符串
allJS, err := ctx.ExtractJavaScript()
if err != nil {
	// 处理提取错误
}

如果使用v0.4.0以下的旧版本，也无需全量遍历PDF对象，只需要检查上下文的Names、Root.AA、各页面Annots、AcroForm这几个固定节点下的动作属性，就能拿到所有内嵌JS。

内容的提问来源于stack exchange，提问作者mks