上周五晚上十一点四十，我把移动硬盘从抽屉最底层翻出来，插上笔记本的 USB-C 口，风扇立刻转得很大声。那块盘里存着 2023 年 11 月 17 日我自己做的一次整包备份，文件夹名叫「4949_20231117_FULL」，压缩后 4.7 GB，解压后 6.2 GB。我原本只想核对一下里面有没有我当时记错的一个子目录，结果一不小心，从第一个文件夹名一直翻到了最后一个校验文件，用了将近三个小时。这让我意识到，同一份 4949资料图库资料库下载 的东西，别人拿到手里是「下完就完」，而我这种人是「下完才开始」，于是就有了这篇记录。
一、解压之后第一眼看到的东西，比下载时看到的更有信息量
下载页面通常只给你一个包名、一个体积、一个时间戳，最多再加一句版本说明。这次我拿到的那份包，文件名是 4949_lib_pack_20231117.7z，用 7-Zip 24.08 打开，根目录下有三个并列项：catalog/、assets/、verify/。很多人会直接点开 assets 找图，我反而先看 catalog。catalog 里是一个 2.3 MB 的 CSV，字段是「序号、原始路径、归档路径、文件类型、字节数、哈希前 12 位」，一共 18,406 行。有意思的是，第 7,219 行到第 7,344 行这一段，归档路径里出现了两个连续同名目录，比如 assets/2021/07/assets/2021/07/，重复了一层。这不是下载出错，源头打包时就有这个问题，因为解压出来它是真实存在的目录，不是软链接。
一个具体数字：「18,406 行」和「17,891 个唯一哈希」
我把 CSV 里那 18,406 行的哈希前 12 位抽出来做了去重，得到 17,891 个唯一值，也就是说有 515 个条目是重复的。这个比例约 2.8%，不大，但足够让一个严谨的人不舒服。于是我做了一件事：把重复项单独列出来，按哈希分组，用 PowerShell 的 Get-FileHash -Algorithm SHA256 对其中 40 组做了完整校验，结果 40 组全部一致。这说明重复是纯粹的路径冗余，不是文件损坏。确认这一点之后我才放心继续看 assets，否则你根本不知道自己在看什么。
二、命名规则比内容本身更能说明这份资料是怎么攒起来的
assets 目录下面分年、分月，2020 年之前的目录明显稀疏，2021 年之后开始变密，这个变化曲线本身就很有意思。我抽看了 2022 年 3 月那个文件夹，里面有 312 个文件，命名大致有三种格式：一种是纯数字加下划线，像 20220314_0071.jpg；一种是带前缀的 img_20220314_120933.jpg；还有一种是明显从别的系统搬过来的 DSC_4821.JPG。三种格式混在一起，说明这批东西不是一次性采集的，而是来自至少三个不同的来源，被汇总方硬塞进了一个目录。我跟做数字档案的朋友陈苇在电话里聊过这件事，她当时的原话是：「命名不统一的归档，等于没有归档。」我认同，虽然这话有点狠。
说到这里就得谈谈站内的几篇旧文了。49图库恢复正常使用25 那篇里提到过恢复使用后的第一批索引重建，我当时读完就觉得，索引重建的前提是命名可解析，如果命名乱七八糟，重建出来的索引也只是把混乱复制一遍。另外 新澳49库图用户评价分析报告 里统计过一批用户对检索准确率的反馈，数字我记不太清了，但结论我记得：用户抱怨最多的不是「下载慢」，而是「找不到刚才看到的那个」。这两件事其实是同一件事的两面。
关于 tk49.0apk绿色版 那次的小插曲
还有一次是真的走弯路。为了验证某个旧的索引格式，我按 tk49.0apk绿色版 页面上的说明装了一个旧客户端，结果它在 Windows 11 上解压出来的临时目录用了 GBK 编码，中文路径全部变成乱码方块，我花了四十分钟才用 Python 的 os.rename 批量修正回来。这件事让我改了一个习惯：现在凡是拿到一个压缩包，我先在虚拟机里解一半，看路径能不能正常显示，再决定要不要在主力机上动它。
三、我的看法：这份资料的价值不在「多」，在「对得上」
说实话，我对「4949资料图库资料库下载」这类整包资源的态度一直有点矛盾。它的内容量确实可观，6.2 GB、一万八千多个条目，够你看很久；但量本身不构成价值，真正决定它能不能被用起来的，是 catalog 和 assets 能不能一一对应、哈希能不能验证、命名能不能被机器解析。从这个标准看，这份包做得不算差，catalog 有，verify 有，SHA256 清单也在，该给的元数据基本给全了；但那个 2.8% 的路径重复和三种混编的命名格式，说明它离「干净的档案」还有距离。我不认为这是吹毛求疵，因为如果你打算长期保存一批东西，十年后你唯一能依靠的就是这些看不见的元数据。
顺便说一句可能不太受欢迎的观点：很多人拿到整包之后做的第一件事是「先全部解压出来再说」，我很不建议这么做。正确顺序应该是先读 catalog，筛出你真正需要的子集，再按类别选择性解压。这样做的成本是多花二十分钟读 CSV，收益是省下几个 G 的空间，以及，更重要的是，你会真正知道手里有什么。我这次就是按这个顺序走的，最后实际需要的只有 1.4 GB，剩下的原封不动留在压缩包里，标了备注。
最后留一个还没解决的问题：verify 目录下的清单文件里，有一行的修改时间是 2023-11-16 23:58，比整个包的生成时间早了两分钟，理论上不应该出现。我怀疑是打包脚本在最后一步单独覆写这个文件时用了旧时间戳，但我没有证据。如果你也翻到过类似的细节，欢迎跟我对一下。
