鸿蒙ArkTS迁移RTF解析：AI辅助改造与真机排障

鸿蒙专家

背景：电子书App的文档格式适配难点

图片、音频、视频等多媒体文件虽然格式多，但鸿蒙系统已有Image、Video、MediaPlayer等原生组件可加载，开发难度相对可控。文档格式则不同：格式多、结构复杂，部分格式还闭源。原文指出，鸿蒙已原生支持PDF、TXT、EPUB、MOBI、AZW3等文档格式，但DjVu、RTF、DOCX等仍未覆盖。对电子书App来说，若要把其他平台已有的解析能力迁移到鸿蒙，往往涉及C、Java、JavaScript等多语言代码，既要做语言转换，还要让新工程通过编译、完成文档调试，迁移成本很高。

原文作者的实践目标是让鸿蒙App支持RTF解析。RTF是基于ASCII纯文本的跨平台文档格式，支持字体、颜色、样式、图像等基础格式，复杂度低于DOCX，不少软件的License文档也采用RTF。这个选择适合作为跨平台文档解析迁移的切入点。

选型：LibreraReader加RtfParserKit

作者先借助豆包调研安卓侧可用的RTF开源方案，得到OpenReadEra、CoolReader、KOReader、LibreraReader四个项目。进一步分析发现，前三个涉及C++，LibreraReader采用纯Java，于是将其作为突破口。豆包进一步指出，LibreraReader的RTF解析采用Java层RtfParserKit第三方库，加上自行封装的RtfExtract、RtfExtract2适配器，并非原生C++渲染。

原文给出的选型优势包括：纯Java，不需要NDK编译，集成成本低；rtfparserkit协议宽松，BSD许可比GPL友好；解析后转HTML，可以复用HTML/EPUB渲染引擎做电子书分页。对鸿蒙迁移而言，这意味着可以先在安卓工程中验证RTF解析链路，再处理Java到ArkTS的跨语言改写。

第一步：用AI从LibreraReader剥离RTF代码

作者原本尝试手工从LibreraReader源码中剥离RTF相关代码，折腾数小时未完成，随后改用Trae。给Trae的任务约束很具体：以安卓App开发专家角色工作；指定LibreraReader源码路径；从RtfExtract.java入口抽取RTF解析和阅读相关代码；新工程rtftest沿用现有Gradle、JDK与SDK配置；rtfparserkit源码已放入新工程，不必在build.gradle重复导入；把com.foobnix.pdf.info.R替换为com.example.rtftest2.R；如涉及greendao调用，改为谷歌官方Room；同时给出Android Studio本地安装目录。

Trae约半小时完成代码剥离，并编译打包出debug安装包。这个阶段的关键不是让AI“重写全部”，而是把迁移范围收敛到RTF解析与阅读相关代码，同时明确依赖位置、包名替换、数据库替换和构建环境。对跨平台迁移任务来说，这些边界条件直接影响AI产物能否直接编译。

第二步：先纯文本、再图文，定位16B图片问题

剥离后的安卓工程经简单调试，可以解析纯文本RTF，但图文RTF无法显示图片，抽取出的3张PNG图片都只有16B。作者把真机现象、文件表现和图片大小反馈给Trae，Trae约15分钟定位并修改源码，修复后重新编译，图文RTF中的图片可以正常显示。

这里的调试方法值得借鉴：不要一上来就覆盖所有RTF样本，而是按“纯文本解析—图文解析—样式解析”逐层验证；出现异常时，把可观察结果（图片只有16B、文本正常、图片缺失）作为排障输入，比只说“解析失败”更利于AI定位。

第三步：安卓工程转鸿蒙App工程

安卓侧验证通过后，作者继续让Trae把rtftest安卓工程改写为鸿蒙工程。提示词要求：把Java代码和XML文件改造为鸿蒙ets代码；指定新工程保存路径；兼容鸿蒙6；工程名为RtfApp；给出DevEco Studio本地安装目录。

原文指出，代码剥离发生在两个安卓工程之间，只是从完整工程中抽取部分代码；而安卓转鸿蒙则是把Java实现重新改写为ArkTS代码，工作量更大。即便借助AI，转换也花了近一个小时。由于鸿蒙App的debug安装包需要开发者手动签名，AI只生成了未签名裸包，后续仍需人工完成签名和真机安装。

第四步：真机排障，控制字分隔符处理差一位

鸿蒙工程在真机测试时出现两个问题：tiaozhuan.rtf解析出的内容除中文外，混杂大量字母与数字组成的奇怪字符串；kuaipan.rtf只解析出文本，内部携带的3张图片未显示。Trae分析约半小时后定位到同一根因：readCommand()对控制字分隔符的处理逻辑写错，比Java原版RawRtfParser差了一位。修复后，两个问题一并解决。

这类问题说明，Java到ArkTS的移植不只是语法替换。RTF解析器对控制字、分隔符和状态位很敏感，原Java实现中的边界处理在改写时容易出现偏移；一旦偏移，文本内容和图片提取会同时受影响。因此迁移后的验证用例应同时覆盖纯文本、图文和异常字符场景。

第五步：样式与超链接验证，修复继承缺陷

继续用QQLicense.rtf测试时，作者发现解析出的文本只有一种字体，粗体、黑体不显示，HTML中的超链接也退化成普通文本。Trae分析约15分钟后确认，这是安卓版本就存在的缺陷，鸿蒙版本把该缺陷原样带了过来，随后给出修复并修改相关代码。重新编译后在真机调试，RTF文档的丰富样式可以完整显示，纯文本RTF能显示黑体文字和超链接，图文RTF也能区分字体并正确显示配图。

这一环节提示：跨平台迁移要先确认问题来自“移植引入”还是“原工程继承”。如果是原工程已有缺陷，AI可以辅助定位和修复，但验证用例必须覆盖样式、超链接、图文混排等非纯文本能力，不能只以“能读出文字”作为迁移完成标准。

可复用的迁移方法

从原文实践看，AI编程在鸿蒙文档解析迁移中的价值主要集中在三件事：一是调研开源实现并缩小技术选型；二是按明确边界剥离代码、完成Java到ArkTS的工程转换；三是根据真机现象定位解析器边界错误。可复用的流程是：先选纯Java、依赖清晰的开源实现；把迁移范围限定到具体格式入口和依赖；在提示词中写清源码路径、目标工程路径、包名替换、依赖处理、数据库替换和IDE路径；先跑通纯文本，再验证图文和样式；对AI产物执行编译、签名、真机安装和回归测试。

同时也要看到限制：AI可以加速代码剥离和改写，但跨语言语义差异、RTF控制字边界、样式解析缺陷仍要靠真机样本暴露；鸿蒙debug包签名仍需人工处理；AI生成未签名裸包后，不能直接等同于可交付应用。把AI放在“批量改造与问题定位”位置，把人工放在“边界定义、样本设计和真机验收”位置，更适合这类鸿蒙跨平台功能适配任务。