哈哈，你这个例子在那个年代估计也确实合理

MS的ppt二进制格式里面，也会把用户每次修改的对象，单独存储，叫UserEditAtom

【 在 vabc3 的大作中提到: 】
: 看过一个例子：对于1M的文件，需要在第10字节插入一个字符，现在的机器就直接全读进来然后全写回去好了。
: 但是在软盘+低内存时代这个是无法接受的，产生了有不少技巧，比如文件头预留一部分固定长度描述后面有什么patch，然后把这个字符当作patch插入文件尾部。这样能节省很多io。
: 下次'另存为‘的时候，这些patch才有机会被合并成新文件。
--
FROM 125.35.123.*

你是在开发亿赛通吗？
厉害厉害

CSDN的sam是不是你？https://blog.csdn.net/lipinganq/article/details/76713880

之前看过一个博客，背其中的“上千人年”吓住了。现在看到你真的在parse文档，非常钦佩。https://www.joelonsoftware.com/2008/02/19/why-are-the-microsoft-office-file-formats-so-complicated-and-some-workarounds/

【 在 z16166 的大作中提到: 】
: 由于要parse老版本的*.xls文档，看了一下xls的格式，发现xls中存在一个极其奇葩的设计。
: xls是Excel 97/95版本的，这种文件是二进制格式，带有一个文件头，文件头指向后面一系列的记录。
: 每个记录是T-L-V（Type-Length-Value）结构的，V里面会有很多结构，这个没啥问题。
: ...................
--
FROM 36.45.32.*

上千人年，作者对office的工作量估计。

但博客本身，也是吐槽文档格式的BIFF，增加了解析的难度。核心结论就是，这种格式根本没有考虑interchangeable ，就是为了快。
解析的难度还来自复杂漫长的历史，比如1900和1904那个例子。

总而言之，你解析这个，还是很厉害的。好好干，是career ，不是job了。
【 在 z16166 的大作中提到: 】
: 这不是我，哈
: “上千人年”是说搞office、wps那种解析、渲染、编辑一体的吧，文档的每个角落都要触及，还不能有大bug
:
--
FROM 36.45.32.*

听起来像ZIP格式
【 在 vabc3 的大作中提到: 】
: 看过一个例子：对于1M的文件，需要在第10字节插入一个字符，现在的机器就直接全读进来然后全写回去好了。
: 但是在软盘+低内存时代这个是无法接受的，产生了有不少技巧，比如文件头预留一部分固定长度描述后面有什么patch，然后把这个字符当作patch插入文件尾部。这样能节省很多io。
: 下次'另存为‘的时候，这些patch才有机会被合并成新文件。
--
FROM 222.71.112.*

别把file parser想那么难，有规范文档的，对着文档弄就完事了

除非是那种什么巨老的连格式文档都找不到的

当然，要想少出点漏洞，得搞一堆的测试用例和fuzzy

【 在 DoorWay 的大作中提到: 】
: 上千人年，作者对office的工作量估计。
: 但博客本身，也是吐槽文档格式的BIFF，增加了解析的难度。核心结论就是，这种格式根本没有考虑interchangeable ，就是为了快。
: 解析的难度还来自复杂漫长的历史，比如1900和1904那个例子。
: ...................
--
修改:z16166 FROM 125.35.123.*
FROM 125.35.123.*