拯救老 GIF 图片的起因本周[GlitchyZorua]向提及了 [Ibiblio Icon Browser]这是一个由 [Gioacchino La Vecchia] 在 20 世纪 90 年代整理的 GIF 图标集包含数千个图标。Glitchy 的目标是将所有图标存档但过程颇具挑战。如今很难看到如此具有 90 年代风格的网站它看似简单一个索引页面链接到 24 个子索引页面再链接到 57 个图标目录页面这些页面代表着 114 个图标集每个图标集最多包含 7296 个图标图标大多为 32×32 像素。访问图标文件的挑战当试图从目录页面访问图标文件时挑战就来了。点击的看似是一个链接实际上是一个图像映射。之前曾讨论过 [图像映射]简单来说图像映射就是定义图像中的特定“区域”点击这些区域会链接到不同的地方。最常见的是客户端图像映射即 HTML 代码中包含所有坐标信息以及点击后跳转的目标地址。但这个网站使用的是服务器端图像映射。当点击时浏览器会将点击位置的像素坐标作为查询字符串发送给服务器服务器接收到这些坐标后进行解码然后根据点击位置将用户重定向到相应的页面。该网站的 HTML 代码中根本看不到 GIF 文件库的 URL且由于网站禁用了目录索引无法直接去掉 URL 末尾的图像文件名来查看目录内容这正是 GlitchyZorua 遇到的难题。探索与发现archive.org 也未能完整收集这些图标。不过通过对网站的探索发现这些图像总是以最多 8×8 的网格形式排列每个图像包括其大小信息占据 72×89 像素的空间点击这个交叉区域内的任何位置都会重定向到同一张图片。该网站的服务器似乎运行着 Apache可能使用了类似 [mod_imagemaps] 的模块来管理服务器端图像映射。可以推测服务器上可能有一个将矩形坐标对映射到重定向 URL 的文件。虽然无法访问这些配置文件但可以推断出点击区域的位置。如果每个点击区域是 72×89 像素可以先点击左上角区域的中心点36×44然后每次分别增加 72 和 89 像素以此遍历所有点击区域的中心点。获取图标 URL 及下载用伪代码表示需要这样做对于从 1 到 113 的每个图标集对于集合 {36, 108, 180, 252, 324, 396, 468, 540} 中的每个 X 坐标对于集合 {44, 133, 222, 311, 400, 489, 578, 667} 中的每个 Y 坐标生成一个特定格式的 URL向该 URL 发送一个 HTTP HEAD 请求如果收到 HTTP 302重定向响应码则记录响应头中的 Location 字段。通过这种方式就能获取到该网站上数千个 GIF 图标的 URL接下来可以使用 wget 下载这些图标。搭建新网站展示图标在获取所有图标后可以搭建一个新网站来展示它们。这个新网站将不再使用服务器端图像映射并且具备搜索功能。于是用 Ruby 和 ERB 模板快速搭建了一个非常基础的静态网站生成器生成了一个带有分页功能与原网站的页码对应和客户端搜索功能的图库。这个现代化版本的图标库虽然很基础但相比原版有了很大的改进得益于这些年 Web 技术的发展。如果想浏览这个新形式的图标库可以访问 [ibiblio-icon-archive.danq.dev]。文章相关信息与评论文章发布于 2026 年 7 月 10 日 16:46 UTC。文章还有相关的标签、转载信息、分享与提及等内容。此外还有一些评论如 Spencer 提出用 72×89 像素的图像映射来链接 32×32 像素的图片很搞笑询问为什么不用表格来展示原始图片还提到减少服务器请求与页面总大小的关系以及图标的许可协议问题。Dan Q 进行了回复解释了有些图片比 32×32 像素大且合成图片共享一个颜色表能在 GIF 格式中节省空间最大的节省在于 HTTP 往返请求成本相对较高关于许可协议问题目前还没有答案正在联系原网站所有者这些图片最初发布时似乎遵循了当时网络上普遍的合理使用原则。还有 lemmy.bestiver.se 给出评论链接。发表回复方式如果要发表回复电子邮件地址不会被公开必填字段有评论、姓名、邮箱、网站。还可以选择在自己的网站上回复、在 Mastodon 上回复、通过电子邮件回复等方式。