一张 JPEG 也能像动画一样变化：有人利用了浏览器“边下载边重画”的老机制
林岚｜OC 开发者生态编辑
林岚｜OC 开发者生态编辑
开发者 Maurycy 在文章 Regressive JPEGs 中展示了一种非常规实验：把多张同尺寸图片的 JPEG 扫描数据拼进同一个文件，过滤重复的文件头与结束标记，再通过慢速网络发送。部分解码器会把后来的扫描继续应用到已经显示的图像上，于是浏览器里的同一个 .jpg 会依次变成不同画面。
一句话结论： 这不是 JPEG 突然支持了正式视频，而是利用渐进式解码允许后续扫描补充甚至覆盖频率数据，让“图片逐渐变清晰”变成了“图片逐渐变成另一张”。
普通 baseline JPEG 往往等到足够数据后从上到下显示。progressive JPEG 会把图像分成多个 scan：第一轮只传最重要的低频信息，让用户先看见模糊全图；后续再增加亮度、颜色和高频细节，最终收敛到完整图片。
JPEG 并不是逐像素保存颜色。它把图像转换到 YCbCr，再把小块内容表示成离散余弦变换系数。低频决定大致亮暗和轮廓，高频补充边缘与纹理。渐进扫描可以指定本轮包含哪些颜色通道、哪些 DCT 频段和哪一位精度。
Maurycy 发现，既然后续 scan 能继续写解码状态，就可以把另一张同尺寸图片的扫描接在后面。网络足够慢时，浏览器每收到一批数据便重新绘制，用户看到的就不再只是清晰度变化，而是多个画面依次出现。
为什么只有慢慢加载时才能看见
文件里没有帧率、时间戳和播放控制。画面变化速度完全取决于服务器发送速度、网络缓冲和解码器何时刷新。文件下载完成后，它通常只剩最后状态，看起来还是一张静态图片。
这也是它和 GIF、APNG、WebP 动画或视频格式的根本区别。正式动画格式知道每帧持续多久、是否循环，也能随机访问和稳定解码；这个 JPEG 实验把网络传输过程本身当作时间轴。
多数解码器还会限制 scan 数量，以防止恶意文件消耗过多 CPU 或制造类似压缩炸弹的问题。作者最初拼接多幅完整渐进 JPEG 时，很快撞上限制，因此继续尝试让每个画面只使用最少扫描。渐进模式中 DC 与 AC 数据不能在同一扫描里随意混放，这又限制了画质和帧数。
它能用来绕过图片审核吗
理论上，一些只解码首帧或最终状态的系统可能错过传输中出现的中间画面，但实际利用取决于具体解码器、缓存和扫描限制。不能仅凭演示断言主流平台审核已经可以被普遍绕过。
对安全工程更实际的提醒是：文件扩展名和最终截图不足以描述一个媒体文件的所有状态。上传服务应使用成熟解码库完整解析输入，限制尺寸、扫描数与解码资源，并重新编码用户图片，而不是原样转发任意扫描结构。
重新编码通常会把异常 JPEG 归一化成平台自己的 baseline 或 progressive 结构，从而消除拼接扫描。不过，解码本身仍要在资源受限环境中完成，避免格式解析漏洞和拒绝服务。
为什么这种小实验值得看
现代开发者经常把文件格式当作黑箱：浏览器能显示就行。这个实验提醒我们，几十年前的格式包含丰富状态机，很多看似固定的对象其实是逐步计算出来的。渐进式 JPEG 原本是为拨号网络改善体验，现在被重新组合成一种近似动画的视觉效果。
它大概不会替代任何视频格式，却非常适合作为协议设计课程：兼容性允许的行为，未必等同于产品设计者当初希望用户拿它做的行为。
关键事实
- 实验把同尺寸图片的扫描数据拼入一个 JPEG，并依赖渐进解码刷新画面。
- 文件没有动画时间信息，播放速度由网络传输和解码器决定。
- 多数解码器限制扫描数量，因此目前很难形成长而稳定的动画。
- 该技术是格式实验，不等于 JPEG 标准新增动画功能，也不是成熟视频方案。
OC 判断
这项实验的新闻价值不在“JPEG 打败 GIF”，而在于它把一个熟悉格式的隐藏状态暴露出来。对普通开发者是有趣的编码课，对平台工程师则是提醒：任何允许增量解释的格式，都要考虑中间状态、资源上限和重新编码边界。
为什么重要
- 对开发者： 媒体格式是状态机，不能只检查扩展名或最终渲染结果。
- 对平台： 完整解码、资源限制和重新编码比依赖客户端行为更可靠。
- 对普通用户： 这类文件的变化依赖加载过程，下载后看到的通常只会是最后一幅图。
评论
围绕这篇文章补充信息、提出问题或分享观察。