欢迎加入开源鸿蒙跨平台社区：https://openharmonycrossplatform.csdn.net20 篇写完了。从第一篇的插件概览，到 OLE2 二进制格式的逐字节拆解，再到 Piece Table 的双编码处理——这个系列覆盖了 doc_text 适配 OpenHarmony 的每一个技术细节。这篇做一个完整的回顾，聊聊适配过程中的关键决策，以及文档解析技术在 OpenHarmon

欢迎加入开源鸿蒙跨平台社区：https://openharmonycrossplatform.csdn.netdoc_text 在解析 .docx 文件时会产生临时文件——因为需要把 ZIP 内容解压到磁盘上。这些临时文件用完之后必须清理，否则会占用存储空间。这篇讲 doc_text 的临时文件管理策略，包括创建、使用、清理的完整生命周期，以及一些容易踩的坑。及时清理：用完立即删除异常安全：try

欢迎加入开源鸿蒙跨平台社区：https://openharmonycrossplatform.csdn.net从 Word 文档中提取出来的"原始文本"并不干净——里面混着各种控制字符、空字节、Word 专用的特殊标记。做字符映射，做字符过滤，cleanText做最终清洗。这篇把这三个方法以及底层的 readU16/readU32 都讲透。\n，HT →\t，控制字符 → null：6 个 Uni

欢迎加入开源鸿蒙跨平台社区：https://openharmonycrossplatform.csdn.netPiece Table 是精确提取文本的"正道"，但它不是万能的——有些文档的 CLX 结构损坏、Table 流缺失、或者格式太旧。这时候 doc_text 会启用回退策略：直接在 WordDocument 流中暴力搜索文本。三个偏移量、两种编码、取最长结果。粗暴但有效。三个偏移量：0x2

欢迎加入开源鸿蒙跨平台社区：https://openharmonycrossplatform.csdn.netPiece Table 是 .doc 文本提取的核心数据结构。它把文档的文本分成若干"片段"（piece），每个片段记录了文本在 WordDocument 流中的位置和编码方式。同一个文档中可能同时存在 Unicode 和 ANSI 两种编码的片段——这就是为什么 .doc 解析比 .do

欢迎加入开源鸿蒙跨平台社区：https://openharmonycrossplatform.csdn.netPiece Table 是 .doc 文本提取的核心数据结构。它把文档的文本分成若干"片段"（piece），每个片段记录了文本在 WordDocument 流中的位置和编码方式。同一个文档中可能同时存在 Unicode 和 ANSI 两种编码的片段——这就是为什么 .doc 解析比 .do

欢迎加入开源鸿蒙跨平台社区：https://openharmonycrossplatform.csdn.net拿到了 WordDocument 流的数据，接下来要从中提取文本。这不是简单的"读字节"——Word 文档的文本存储方式相当复杂，涉及FIBCLX结构。doc_text 的 extractWordText 方法就是在处理这些东西。这篇是整个系列技术含量最高的一篇。FIB 是 WordDoc

欢迎加入开源鸿蒙跨平台社区：https://openharmonycrossplatform.csdn.net拿到了 WordDocument 流的数据，接下来要从中提取文本。这不是简单的"读字节"——Word 文档的文本存储方式相当复杂，涉及FIBCLX结构。doc_text 的 extractWordText 方法就是在处理这些东西。这篇是整个系列技术含量最高的一篇。FIB 是 WordDoc

欢迎加入开源鸿蒙跨平台社区：https://openharmonycrossplatform.csdn.netOLE2 的目录流就像一个"文件目录"——记录了每个流的名称、类型、起始扇区和大小。doc_text 需要从中找到流（文本数据）和流（格式信息）。这篇把 parseDirectoryEntry 和 findEntry 的每一行代码都过一遍。目录条目（128 字节）：偏移 长度 字段0x00

欢迎加入开源鸿蒙跨平台社区：https://openharmonycrossplatform.csdn.netOLE2 的目录流就像一个"文件目录"——记录了每个流的名称、类型、起始扇区和大小。doc_text 需要从中找到流（文本数据）和流（格式信息）。这篇把 parseDirectoryEntry 和 findEntry 的每一行代码都过一遍。目录条目（128 字节）：偏移 长度 字段0x00