当前位置：首页 > news >正文

拯救 7234 张老 GIF 图片：突破服务器端图像映射难题，搭建新展示网站

news 2026/7/16 10:52:16

拯救老 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 给出评论链接。