开源贡献-Docling
围绕 Docling 的 XLSX 表头识别和 CLI 批量转换输出，修复合并区段标签误入表头以及同名输入静默覆盖问题。
Docling 面向文档解析与 GenAI 数据准备。本项目记录两条端到端贡献：Excel 后端将紧邻表格的合并区段标签与真实列头分离，并保持 DoclingDocument 与 HTML 的表头语义；CLI 则为同名输入建立独立暂存目录和稳定的唯一输出 stem，避免 RAG chunks 被静默覆盖。
- - XLSX 合并区段标签与真实表头分离
- - 保持 DoclingDocument 与 HTML 的 th 语义
- - CLI 输入按来源隔离暂存
- - 同名输出按处理顺序生成 document_2 等稳定名称
开发记录
- fix(reading-order): dehyphenate hard continuations：在文档解析的读取顺序（reading order）阶段，当处理跨元素文本合并时，若一个以连字符结尾的片段与后续以小写字母开头的片段合并，原有的硬连字符（hard hyphen）未被正确移除，导致输出文本中残留不必要的连字符（例如“meth-od”）。此问题影响文本可读性和后续自然语言处理。Issue #3886 报告了该问题，且与配套的映射变更（docling-ibm-models#171）相关，需要在模型层调整连字符处理逻辑，区分硬连字符（应仅在特定条件下保留）和软连字符（应始终保留）。
- fix(ocr): support Latin languages with RapidOCR ONNX：Issue #3840指出，当用户为RapidOCR配置非中英文的语言（如西班牙语）时，系统会尝试加载默认的ONNX模型路径，但由于该路径被解析为通用的'latin'模型集，而当前实现未正确处理此回退逻辑，导致初始化失败或运行时错误。该问题影响了多语言文档处理场景的稳定性和可用性。
- fix(pdf): remove NUL characters from parsed text：在Docling解析PDF时，部分PDF文本中嵌入了NUL字符（\x00），这些字符在进入下游文档组装流程后会导致异常或数据损坏。该问题影响标准Docling Parse后端和线程化后端，用户反馈在转换包含特殊格式（如上标单位指数）的PDF时出现异常。需要在不损失有效Unicode字符的前提下，从字符、单词和文本行单元中彻底清除NUL字符，确保解析输出在任何导出格式（如Markdown）和序列化对象中均不含NUL。
- fix(xlsx): preserve headers after section labels：Excel 中没有空行分隔的合并区段标签会被 flood-fill 识别为表格第一行，导致标签渲染成 th，而真正的列头降级为 td，破坏 DoclingDocument 结构和 HTML 表格语义。
- fix(cli): preserve outputs for duplicate stems：一次 docling convert 接收不同目录下的同名文件时，输入会在共享暂存目录互相覆盖，转换后的 flat 输出又只使用 source stem，最终后一个文件静默覆盖前一个文件；对 chunks 输出尤其危险。