概览
文档摄取由src/transcode/ 中的文档转码器处理 —— document.hpp / document.cpp。它把一份上传的 PDF 或电子表格分解为一个有序的 LLM 可消费片段列表(文本和/或图像),策略为**“文本优先,图像(及 OCR)兜底”**。概念性走查参见文件处理。
文档转码器把上传的文档拆解为文本与图像片段,供具备视觉能力的 LLM 在对话轮次中读取。(上传接线以当前 HTTP 层为准核实。)
支持的格式与构建开关
格式由 magic bytes 嗅探得出(detect_format),再路由:
| 格式 | 库 | CMake 开关 | 默认 | 备注 |
|---|---|---|---|---|
| PDFium | MIROBODY_ENABLE_PDF | 关闭 | 逐页文本层;扫描页 → 图像 | |
| .xlsx | xlnt | (找到 xlnt 时自动) | 存在 xlnt 处开启 | 每个工作表一张 Markdown 表格 |
| .xls | 内置的 libxls | MIROBODY_ENABLE_XLS | 关闭 | 旧版 BIFF |
| .csv | 内建(RFC 4180) | — | 始终 | 单张 Markdown 表格 |
| OCR | Tesseract + Leptonica | MIROBODY_ENABLE_OCR | 关闭 | 需要 MIROBODY_ENABLE_PDF |
process() 会抛出 DocumentError("... not built")。
API
各路径产出什么
- PDF,文本页 → 一个带提取出的文本层的
Text片段。 - PDF,扫描页(文本低于
pdf_text_threshold)→ 以raster_dpi栅格化,编码为 PNG,经image::Transcoder处理以适配image_limits,作为Image片段发出。在MIROBODY_ENABLE_OCR构建中,同一张栅格图还会被 OCR,识别出的文本追加为一个Text片段。 - .xlsx / .xls → 每个工作表一个
Text片段,一张 GitHub 风格的 Markdown 表格(## <sheet title>+ 表格)。绝不产生图像。 - .csv → 单个
Text片段(RFC 4180 解析 → Markdown 表格;剥离 UTF-8 BOM)。
to_markdown() 把一个 Document 展平:文本片段内联,图像片段作为一行  占位符。
线程(PDF)
PDFium 的库初始化/清理是进程全局的且非线程安全,且一份已加载的文档不可被并发访问。PDF 路径把所有 PDFium 工作串行化在一个内部互斥锁之后,并持有那次一次性的全局初始化,因此Transcoder 可从多个线程安全调用 —— 只是在处理一份 PDF 时,PDF 工作并不并行。CSV / xlsx 无此约束。
试一试 —— document CLI
cli/document.cpp 工具(当 MIROBODY_BUILD_TOOLS 为 ON 时构建)端到端演练转码器:
<out> 旁边;文本片段落进 Markdown。--target 为栅格化页面挑选视觉预设(默认 qwen)。
单位
从文档中提取的数值可用单位引擎(src/fhir/units/)归一化到 UCUM —— 参见数据映射。
测试
tests/transcode/document_test.cpp、tests/transcode/file_test.cpp、tests/transcode/image_test.cpp,以及 tests/fhir/units_test.cpp(Catch2)。运行转码器子集:
把提取出的数值作为带编码的
Observation 写回 FHIR 存储(文档 → 指标 → FHIR 流水线)尚在进行中 —— 转码器与 UCUM 归一化已上线;术语映射与写回尚在计划中(src/fhir/README.md 的第 3–4 阶段)。(verify)下一步
文件处理(概念)
流水线一览
数据流
上传的定位
数据映射
UCUM 归一化
测试
运行转码器测试