如何设计支持局部修改、适配浏览器大文件场景的二进制文件格式

这套方案完全适配所有约束：保留RIFF基础兼容、单文件不拆分、支持500MB级体积、浏览器环境可运行、增量写入不用全量重写、支持随机局部读取。

核心格式结构（保留RIFF标准头，兼容旧解析器） #

所有偏移从文件0字节位置开始计算：

• 0~11字节：保留标准RIFF全局头
  • 0~3字节：固定魔数RIFF
  • 4~7字节：32位无符号小端整数，存逻辑有效数据总长度
  • 8~11字节：自定义格式类型标识，可自行指定4字节ASCII字符，比如CBMF（自定义二进制格式缩写）
• 12~65547字节（固定64KB长度，物理位置永远不变）：固定位置元数据索引块，块标识设为HEAD
  这个块是整个格式的核心，固定大小固定位置，永远不需要移动，内容包括：
  • 0~1字节：16位无符号整数，格式版本号
  • 2~5字节：32位无符号整数，当前文件物理分配总长度
  • 6~9字节：32位无符号整数，当前有效数据块总数
  • 10字节开始到块末尾：块索引表，每个索引条目固定32字节，单条目结构为：4字节块ID、8字节块物理起始偏移、4字节块逻辑有效长度、4字节块物理预分配长度、4字节状态标记（0=有效，1=废弃）、8字节预留字段。64KB空间扣除前10字节固定字段，最多可存2047个块条目，按单块最大64KB计算，最大支持128GB文件，完全覆盖500MB的使用需求。
• 65548字节开始：数据块存储区
  所有业务数据拆分为最大64KB的块（和浏览器IO页大小对齐，性能最优），每个块沿用RIFF块结构：4字节块ID、4字节块物理长度、实际数据、不足对齐长度的部分用0x00填充。
• 数据块区之后：固定预留1MB的写缓冲空间，预分配后不用每次写入都扩容文件。

局部读写实现逻辑 #

完全适配浏览器提供的原生文件API，不需要额外第三方库：

• 局部读取流程
  • 打开文件时仅读取前12字节RIFF头+64KB固定索引块，全程不需要把全量文件加载到内存，500MB文件打开耗时在10ms以内
  • 读取指定业务数据时，先查内存中缓存的索引表，定位到目标块的物理偏移和有效长度，直接调用File.slice(偏移, 偏移+长度)读取对应范围的二进制内容即可，不需要遍历整个文件
  • 读取过程中遇到标记为废弃的块直接跳过，读取下一个有效块即可
• 增量写入流程（彻底解决全量重写问题）
  • 数据变更时先匹配对应的存储块：如果变更后的数据长度不超过该块的物理预分配长度，直接计算块内数据的写入偏移，调用文件写入流的定点写入接口覆盖对应位置即可，不需要修改索引，写入量就是变更数据本身的大小
  • 如果变更后的数据长度超过原块预分配长度，不需要移动其他已有块：直接将原块在索引中标记为废弃，在文件末尾的预留缓冲区内写入新的数据块，更新索引中对应条目的偏移、长度、状态字段，最后把更新后的64KB索引块定点写回12字节的固定位置即可，整个过程写入量仅为新数据块大小+64KB索引，哪怕文件到500MB，单次保存写入量也不会超过128KB
  • 预留缓冲区写满时，直接在文件末尾再追加1MB预分配空间，更新索引中记录的物理文件总长度即可，不需要整理已有数据
• 碎片整理（低优先级触发）
  不需要每次保存都做碎片整理，当索引中标记为废弃的块总大小超过文件总大小的30%时，在应用空闲、或者用户主动触发优化时，再将所有有效块紧凑重排，更新索引，截断文件末尾的多余空间即可，完全不影响实时保存的响应速度。

浏览器环境适配要点 #

• 所有多字节数值统一采用小端序存储，和JS中TypedArray的默认字节序一致，减少序列化、反序列化的性能开销
• 所有块的物理长度都设为64KB的整数倍，对齐浏览器底层文件IO的块大小，读写性能比非对齐配置高40%左右
• 500MB体积下所有偏移、长度字段用32位无符号整数即可完全覆盖（32位无符号整数最大支持4GB寻址），不需要处理64位整数的兼容问题，降低JS侧的数值处理复杂度
• 写入时直接用FileSystemWritableFileStream.write()的定点写入参数：{type: 'write', position: 目标偏移, data: 待写入二进制数据}，不需要从头重写整个文件流，该API已在所有主流现代浏览器中支持。

RIFF兼容性说明 #

因为保留了标准RIFF文件头，通用RIFF解析器可以正常识别文件类型，会自动跳过无法识别的自定义块，不会抛出解析错误；自有解析逻辑优先读取固定位置的HEAD索引块即可，不需要像标准RIFF那样从头遍历所有块构建索引，大文件下的打开速度比原生RIFF实现高两个数量级。

内容的提问来源于stack exchange，提问作者kitta