tamakyi
f98d3864b8
导出：zip 用 CreateRaw 写长度/CRC，别再带 data descriptor（真机判整包损坏）
真正的病根（09-16 起每一份站点导出都被拒都是它）：Go 的 zip.Writer 默认走流式写入——本地头里
的长度与 CRC 留 0、真值挪到条目尾部的数据描述符里，并在 flag 里置 bit3。**真机的读取器只认
「本地头里就写着长度」的条目**，遇到这种包直接判成损坏，报「备份恢复失败，你的当前数据未被更改」。
铁证（直接读文件头）：
站点 Go 写的每一份导出 本地头 flags=0x0008 csize/usize=0/0 → 全部被拒
20260920-fixed-A-数据修复 本地头 flags=0x0000 有长度 → 真机接受（Python 重打包）
真机自己的包 本地头 flags=0x0800 有长度 → 正常（只有 UTF-8 位）
这也解释了之前为什么全都修错了方向：09-20 那次「修悬空引用后就能导入」其实是 Python 重打包顺手把
zip 写法修对了；而 09-29 一整天修的内容问题（活动颜色为 NULL、交通方式重名）都不是拦路虎。
修复：zipBackup 改用 zw.CreateRaw，先把三个文件读进内存算出 CRC32 与长度写进本地头，
不再用会置 bit3 的 zw.CreateHeader。
用例：TestZipBackupWritesNoDataDescriptor —— 直接读第 0 个条目的**本地头**，断言 bit3 为 0、
压缩/原始长度非 0、CRC 正确（变异验证：改回 CreateHeader → 立刻变红，且精确复现 0x0008 + 长度 0）。
真实数据验证：修复后新导出的本地头 flags=0x0000、长度正确。
全量验收 296 PASS / 0 FAIL / 0 SKIP。
2026-09-29 15:04:07 +08:00
..
2026-09-24 20:37:16 +08:00
2026-09-18 13:05:49 +08:00
2026-09-18 13:05:49 +08:00
2026-09-24 20:37:16 +08:00
2026-09-18 13:05:49 +08:00
2026-09-24 20:37:16 +08:00
2026-09-18 13:05:49 +08:00
2026-09-24 22:48:22 +08:00
2026-09-24 20:37:16 +08:00
2026-09-18 13:05:49 +08:00
2026-09-24 20:37:16 +08:00
2026-09-29 15:04:07 +08:00
2026-09-18 13:05:49 +08:00
2026-09-24 20:37:16 +08:00
2026-09-24 20:37:16 +08:00
2026-09-29 13:25:50 +08:00