毕设里有个上传头像的页面。室友用 iPhone 传了一张照片之后页面上只剩一个裂图图标。控制台里一行红字都没有。我先怀疑后端把文件存坏了可下载回来的文件好好的扩展名是.heic。Mac 自带的预览能打开它而拖进 Chrome 就不行。这件事逼我去查一个以前没想过的问题浏览器到底认不认 HEIC。HEIC 是 iPhone 相机默认存照片用的格式。它里面的画面是用 HEVC 压出来的HEVC 就是视频里常说的 H.265。这种压法很省空间代价是浏览器得自己带着 HEVC 解码器才能看懂它。Chrome 打不开 HEIC 是我代码的问题吗为了不靠猜我把同一批文件放进三个浏览器内核里挨个试。内核可以理解成浏览器里负责解析和画出网页的那台引擎。我用的是 Playwright 自带的 Chromium 149、WebKit 26.5 构建和 Firefox 151 构建。三个都是 headless 运行不开窗口在后台跑机器是一台 M4 芯片的 Mac。样本不是真 iPhone 照片。我先用脚本生成合成图再用 macOS 自带的sips命令编成 HEIC。一共有 3MP、12MP、48MP 三档而 12MP 横拍那个文件是 1,375,265 字节。对照组我用的是图映 ImgInghttps://imging.cn/的压缩转换页同一批样本在同样三个内核里各传了一遍。我试了四条读图的路。第一条是最普通的img src。第二条是img.decode()这个方法它会等图片真正解完再告诉你结果。第三条是createImageBitmap这个函数它直接把文件解成一张能画进 canvas 的位图。第四条是 WebCodecs 里的ImageDecoder。这是较新的图片解码接口能先用isTypeSupported问浏览器认不认某种格式。Chromium 和 Firefox 的表现一模一样。img触发 error 事件。decode()抛出EncodingError。createImageBitmap抛出InvalidStateError。ImageDecoder.isTypeSupported(image/heic)直接返回 false。有意思的是拿同一个接口去问image/avif的时候两家都回答 true。新格式它们是会解的偏偏 HEIC 不行。五个样本的结果完全一致并且控制台也确实一个报错都没打。改了 MIME 类型为什么还是打不开我一度觉得是服务器的锅。本地起的 Python 静态服务给.heic返回的 Content-Type 是application/octet-stream意思是「一串说不清是什么的二进制」。我把 Blob 的 type 手动改成image/heic再试一次。结果一点没变。卡住的地方在解码器而不在文件类型声明上。至于这两家为什么不内置 HEVC 解码我查到最多的说法是专利授权。这一点我没办法自己验证就只能先记着。WebKit 能读 HEIC是不是 Safari 也能WebKit 构建四条路里有三条成功。竖拍样本读出来是 3024×4032 并且方向也是正的。这个结果我没料到。它能读靠的是 macOS 的系统解码器而不是浏览器自己带的。我测的只是 Mac 上的 Playwright 构建。它不等于 Safari 正式版。iPhone 上的 Safari 和 Windows 上的 WebKit 我都没测过所以不敢往外推。前端遇到 HEIC 该怎么判断我后来把处理顺序改成先试、后兜底。先用createImageBitmap试一次原生解码。成功就直接用。失败了再去加载一个 WASM 解码器。WASM 是能在浏览器里跑的编译后代码像 libheif 这种用 C 写的解码库就可以编成 WASM 放进网页。图映走的正是这个顺序。在 Chromium 和 Firefox 构建上传完 HEIC 会先出一个「加载解码器」按钮。点了它才去下载 libheif 的包而第一次传输约 510 KB。刷新之后它记得用过这个解码器两个文件都走缓存校验只花了 1,095 字节。在 WebKit 构建上原生读成功了全程没有下载任何解码文件。这比按 UA 判断靠谱。UA 是浏览器自报家门的那串字符串它说自己是谁不代表它真能解。手边有 HEIC 文件的话可以打开 Chrome 控制台对它跑一次createImageBitmap看报的是不是InvalidStateError。再用ImageDecoder.isTypeSupported(image/heic)问一次。几秒钟就能做完。两个结果对得上就能确认是浏览器原生不支持而不是你的代码写错了。
识别与调试器配置实战)
