老格式文档怎么解析：OLE2 .doc与编码文本

结论先行：真实企业语料里约 23.3% 是非常规格式，老格式不能套用通用解析器，必须按格式做差异化处理，否则会整批丢内容。

一、老格式为什么是暗礁

通用解析器面向现代 Office（docx / xlsx）设计，遇到 OLE2 复合文档、编码不明的老文本或 HTML 公告就会失效。在 A 股投研语料中，841 家公司、252,386 份文档、147GB 数据里，约 23.3% 是非常规格式（HTML / OLE2 .doc / 巨潮 .bin）。任何“忽略老文件”的策略，等于默认放弃近四分之一的语料。

这四分之一往往还是最难再生的部分：老 .doc 和 .bin 多是早年公告与制度文件，源头系统可能早已下线，想补抓也没有第二份。财报季批量入库时，团队看到解析成功率超过九成就放行，剩下的文件静默落库为空，直到检索冒烟测试里某家公司的指标怎么都召回不到，才回头发现是老格式整批没进来。等把问题定位到数据层，一轮模型调优往往已经白做。

二、OLE2 .doc 的差异化解析

老 .doc 并不是把文字平铺在文件里，而是一个 CFB（Compound File Binary）复合文档：内容被切成扇区散落在文件各处，由目录结构组织起来。正文不占据连续区域，要靠 piece table（CLX）结构才能知道每个真正的正文片段在哪、按什么顺序拼接，样式、修订记录和删除残留都混在同一个容器里。

因此解析必须下钻到 piece table（CLX），只提取正文片段，跳过样式与修订残留。这一步做错，常见结果有两种：整篇乱码，或者更隐蔽的一种——解析状态显示“成功”，正文却几乎为空。后者最难发现，流水线里它是绿的，只有入库后的字符数统计和人工抽查才能暴露。

三、巨潮 .bin 的编码检测回退

巨潮老式文本文件通常不声明编码，同一批文件里可能混着 UTF-8、UTF-16 和 GBK。解析器需要按 BOM / UTF-16 / UTF-8 / GBK 的顺序做编码检测回退：先读字节序标记，有 BOM 直接定案；没有 BOM 再逐个尝试候选编码，直到解码结果通过校验。

这个顺序有讲究：BOM 是最可靠的显式信号；UTF-16 的变体必须靠 BOM 区分大小端；UTF-8 对纯 ASCII 内容天然兼容；GBK 则是中文遗留系统最常见的缺省编码。编码猜错一个字节，整篇就是乱码，而且乱码照样能通过切片入库——它不会报错，只会把垃圾语义带进向量库。

四、HTML 公告的正文定位

HTML 公告的页面结构远比正文复杂：导航栏、面包屑、版权声明、广告位和脚本混在同一个文档里。直接整页转文本，噪声和正文的比例可能相当接近，切片后每个 chunk 都掺着导航短语。

正确做法是先用 Readability 做正文定位，找出主内容块，再清洗掉无关标签，只保留真正的公告正文。否则噪声会被切片进知识库，检索时与正文抢相关度、挤占 Top-K 名额，页面看起来“全命中”，答案却是错的。

老格式兜底只是解析的一环，扫描件与文本件的路由见 扫描件 OCR 与版面分析；解析后的清洗见 文档清洗。如果非常规格式正在拖累你的知识库，可以直接试用丑梨AI的解析流水线。

常见误区与修正

这类误区的共同特征是「在开发机上测试正常，在真实语料上静默失败」——不报错，只是产出不可用。A 股语料里 23.3% 的非常规格式都集中在这三类。判断自己的流水线是否踩坑，最直接的办法是抽样验证：随机抽老格式文档，对比提取文本与原始文件的可读性。六格式入库的增量审计校验（added + unchanged == total）能把静默丢失挡在入库之前，详见文档解析流水线设计。

常见问题 FAQ

Q1：真实语料里有多少是非常规格式？

在 A 股投研语料中，841 家公司、252,386 份文档、147GB 数据里，约 23.3% 是非常规格式（HTML / OLE2 .doc / 巨潮 .bin）。跳过它们等于放弃近四分之一语料，而且这部分往往最难再生。

Q2：OLE2 老 .doc 为什么不能直接读文字？

老 .doc 是 CFB 复合文档，正文分散在扇区里，要下钻到 piece table（CLX）结构才能按序拼接出真正的正文片段，并跳过样式和修订残留；直接平铺读取只会得到乱码或空文档。

Q3：巨潮 .bin 编码怎么处理？

按 BOM / UTF-16 / UTF-8 / GBK 顺序做编码检测回退，逐个尝试直到正确解码。编码猜错一个字节整篇乱码，而且乱码照样会切片入库，污染检索。

Q4：HTML 公告怎么去掉噪声？

先用 Readability 定位正文主块，再清洗掉导航、广告、脚本等无关标签，只保留公告正文；否则噪声切片入库后会与正文抢相关度，挤占 Top-K 名额。