Android JSON Text Sequence：UTF-8 分帧与截断恢复

直接回答

一个 JSON text 是一个序列化值；把多个 JSON text 直接拼接并不会自动定义记录边界。RFC 7464 定义 JSON Text Sequence：每个 JSON text 使用 UTF-8 字节编码，前面加 ASCII Record Separator (RS, 0x1E)，结尾加 Line Feed (LF, 0x0A)。这是字节级 framing。读取器应先在 UTF-8 字节流中定位 RS，再解析每条候选记录；不能按任意换行切开 JSON string 或 pretty-printed object。 该分隔符可用，是因为 JSON string 内的 RS 控制字符必须转义，不能以原始 JSON 字符出现。每条编码记录后的 LF 也有助于检测顶层 number 与 `true`、`false`、`null` 等字面值的截断；这些 JSON 拼写不像 object、array 或 string 那样能自我界定。对于顶层这些形式，parser 应要求规定的 whitespace boundary；遇到可能只是完整前缀的记录要标为可能截断，而不能直接接受。 RFC 7464 刻意定义不同的 encoder 和 parser grammar，使读取器可以从损坏记录后恢复。记录格式错误时，sequence parser 可报告这一条，再从下一个 RS 继续。按 RFC parser grammar，连续多个 RS 不代表空记录。恢复范围仅限 framing 和语法；它不能证明坏记录不重要、序列位置稳定，或可以重建遗漏记录。若可能截断/丢记录，不要用数组下标充当持久记录身份。 JSON Text Sequence 没有 end-of-sequence marker。最终字节缺失时，读取器可能无法判断生产者是否主动停止、文件被截断，或原本就有记录未写入。LF 可以帮助发现未闭合的顶层 scalar，但它不是持久事务提交、校验和、长度前缀，也不保证所有预期记录都落盘。要单独记录尾部状态：根据已观察 framing 完整、已恢复坏记录、最后一条可能截断，或流结束原因未知。如果需要持久性，就加应用层 manifest 或 commit record，并定义独立协议与测试。 用明确 UTF-8 策略在 bytes 上做分帧。有效 UTF-8 continuation byte 不会与 ASCII RS 相同，所以扫描 `0x1E` 是明确的；但仍要校验每条记录 UTF-8，不能静默用替代字符修复非法字节。保留每个 RS/LF 的 byte offset、原始 record bytes（若允许留存）、parser 结果和恢复动作。单纯规范化为 String 会丢精确来源偏移，也可能隐藏 encoding replacement。 对整条流和每条记录都设界限。限制文件/流字节数、单条记录大小、记录数量、嵌套深度、collection 大小、处理时间和取消行为。一个超大 record 在 schema validation 前就可能耗尽内存。优先用所选 parser 暴露的 streaming/大小控制；否则只暂存受限 record bytes，在构造大对象前拒绝。没有测试准确 library/version 的 parser option 时，不能编造其保证。 语法、schema 与操作是分开的阶段。一条完整 JSON text 仍可能缺字段、类型不符、对象成员名重复后有库相关解释，或含超出 app 规则的值。对每条记录按版本化 schema 和当前状态校验。记录即使提出 function call、文件更改或偏好更新，也不能只因 JSON 解析成功就执行。后续如果 record 解析失败，不能执行已收到的部分 parse event；只有通过约定完整性和校验边界的记录才能提交效果。 用准确 writer 与 reader 测试：object、array、string、number、Boolean、null、转义换行、转义 RS、多字节 UTF-8、空输入、连续 RS、好记录之间的坏 JSON、object 内截断、顶层 number/字面值截断、非法 UTF-8、超大记录，以及各 byte boundary 的取消。断言记录 offset、错误后能否继续、scalar 截断 warning、好记录保留和明确的未知尾部状态。不要用真实私有 prompt 或模型结果当 fixture。 不要混淆 RFC 7464 JSON Text Sequence、按行分隔的 JSON 习惯、单个 JSON array 或模型 token streaming。模型 partial text chunk 是带 request identity 和 cancellation 的 runtime event；JSON-seq RS/LF 是存储/互换 framing 合同。两者彼此不蕴含，也不会由 sequence parser 提供模型输出质量、事务持久性、丢记录时的顺序保证或加密完整性。本文不表示 Cove 持久化 JSON-seq。

进程在追加本地 JSON 记录时停止

Android worker 向本地序列追加小型结果 object。进程在写完一条 record 的部分内容后被终止，下一次运行先遇到一个损坏片段，随后又找到以 RS 分隔的有效记录。读取器需要恢复，同时不能声称最终历史完整。

决策

按 RFC framing bytes 工作，逐条隔离解析状态和 byte offset；仅在下一个 RS 可确认时按策略继续，并且除非应用层 completion marker 能证明更多信息，否则标记尾部不确定。

预期结果

先前有效记录仍可单独查看，损坏记录会被报告；文件不会被描述为原子或完整事务日志。

需要收集的证据

只有将以下证据与同一模型文件和测试运行关联起来，结论才可复核：

• ANDROID-JSON-SEQ-RECOVERY-2026-10：RFC 7464 以 UTF-8、RS 和 LF 为 JSON text 分帧，允许在后续 RS 处恢复；格式无 end marker，并定义顶层 scalar 截断检测。
• ANDROID-PRIVACY-01：解析后的本地文件访问和留存仍由应用负责。
• RAG-01：摄取、切分、索引、检索、prompt 与 generation 阶段须独立验证；JSON sequence framing 只定义记录级字节边界。

收到完整字节流还不够；最终落盘、完整性、运行时加载和恢复路径也必须验证。

实施流程

1. 明确序列格式与字节合同. 声明使用 RFC 7464，而非非正式按行约定。每条 JSON text 用 UTF-8 编码，前有 RS、后有 LF；定义允许的顶层值并保留源 byte offset。
2. 解析前分帧并校验编码. 在 byte stream 中扫描原始 RS 边界，校验每条候选记录 UTF-8，再把受限 record bytes 交给 JSON parser。不能按行切 pretty-printed 内容，也不能用 replacement character 归一化非法 UTF-8。
3. 逐条恢复但不声称完整. JSON 损坏时记录其 offset 范围与错误；按 RFC parser 行为从下个 RS 恢复。用规定 whitespace boundary 检测可能截断的顶层 number/true/false/null；区分已恢复记录、可能缺失记录和未知尾部。
4. 副作用前校验 schema. 只有完整 JSON text 解析成功后，才能应用版本化 record schema、大小/范围规则和当前状态授权。不要执行部分事件，也不把 framing 当 transaction commit、签名、顺序或用户同意。
5. 覆盖 writer、reader、崩溃与限制. 测试有效值类型、转义换行/RS、多字节 UTF-8、连续分隔符、中间坏记录、各 framing 点截断、大记录、取消和重启。断言 byte offset、恢复决定及明确的尾部不确定状态。

让每个阶段的状态都可观察。失败信息应指出阶段、模型、运行时和恢复动作，同时避免记录用户私密内容。

验收标准

• 生产端按 UTF-8 + RS + JSON text + LF 写入，parser 使用声明的 RFC 7464 byte grammar，而不是逐行切分。
• 中间坏记录、连续 RS、非法 UTF-8 和顶层 number/literal 截断均有逐条结果与 byte offset 测试。
• 没有 completion marker 的序列绝不声称完整或原子；前一条可恢复记录不能消除尾部丢失的不确定性。
• 记录大小、流总量、条数、嵌套、schema 处理时间与取消都设明确限制和失败状态。
• 解析、schema 有效性、用户授权与副作用彼此分开；部分 parse event 不会触发操作。

决策对照表

需要避免的失败模式

• 把多个相邻 JSON text 当作天然有记录边界，或按换行分割所有 JSON。
• 把 LF 当作写入提交、校验和或序列结束标记。
• 恢复一个坏记录后声称记录序号稳定、尾部没有丢失或日志完整。
• 把模型 partial token 当成 JSON-seq record，或在完整校验前触发操作。

还要避免静默回退、版本未固定、缺少取消处理，以及把不同配置的结果混在一起下结论。失败运行也应与成功记录一并保存。

最小复现记录

发布检查表

• ☐ 主要搜索问题已回答，且没有未经支持的数字。
• ☐ 所有模型文件和运行时版本均已固定。
• ☐ 代表性任务和失败处理策略均有说明。
• ☐ 生命周期、取消、清理和回退均已测试。
• ☐ 用户内容与网络边界均有说明。
• ☐ 结论只适用于被记录的配置。
• ☐ 新增测试结果时链接到原始方法或证据。

来源与相关证据

• Android privacy and security
• IETF RFC 7464：JSON Text Sequences
• IETF RFC 8259：JSON 数据互换格式
• IETF RFC 3629：UTF-8 编码格式

中文部署与排错专题见。奇连 AI 端侧专题。

常见问题