JPEG 的秘密人生：一個 1992 年的格式如何統治了網際網路

用十六進位編輯器開啟任意 .jpg 檔案。前兩個位元組：

FF D8

這是**影像開始（Start of Image）**標記。每個 JPEG 檔案都以它開頭。地球上每個 JPEG 解碼器都會尋找它。接下來的位元組告訴解碼器這是哪種 JPEG 變體、期望什麼色彩空間、以及像素資料從哪裡開始。這個格式比網頁瀏覽器還要古老，但根據 2025 年 Web Almanac 的資料，它仍然承載著現代網路上約 57% 的影像流量。

催生 JPEG 的儲存危機

1986 年，一張 640 × 480 的原始灰階影像佔用 307 KB 磁碟空間。同解析度的彩色影像需要 921 KB。當時一個 20 MB 的硬碟售價數百美元，1.44 MB 軟碟是標準交換媒介，一張未經壓縮的照片就能填滿三分之二的磁碟。

需求很明顯：需要一種針對連續色調影像（照片，而非線條圖）的標準壓縮格式。多個團隊同時在攻關。**聯合影像專家小組（Joint Photographic Experts Group）**於 1986 年由 ISO/IEC 和 ITU-T 成立，將最優秀的思路合併為一份單一草案。經過六年打磨，該標準於 1992 年以 ISO/IEC 10918-1 發布。

JPEG 從來就沒打算成為唯一的影像格式。它被設計來做一件事：讓照片小到足以儲存和傳輸。它透過按特定順序丟棄資訊來完成這件事。

JPEG 為何壓縮得這麼好

JPEG 壓縮是一條管線，而非單一演算法。每一級都去除人類視覺系統最不可能察覺的資料。

1. 色彩空間轉換（RGB → YCbCr）

你的螢幕顯示 RGB。JPEG 儲存的是 YCbCr。Y 通道承載亮度（luminance）。Cb 和 Cr 承載色度（藍色差和紅色差）。這很重要，因為人眼有約 250 萬個錐狀細胞負責亮度，而負責顏色的只有 10 萬個。我們對亮度細節的感知遠強於顏色細節。

2. 色度子採樣（Chroma Subsampling）

大多數 JPEG 使用 4:2:0 子採樣。每 4 個亮度樣本對應 1 個 Cb 樣本和 1 個 Cr 樣本。這意味著色度通道的儲存解析度只有亮度通道的 四分之一。對於一張 4000 × 3000 的影像，Y 平面是全解析度，Cb 和 Cr 平面各為 2000 × 1500。在真正的壓縮開始之前，原始資料就已經被砍掉約 50%，而大多數觀看者根本不會察覺。

3. 離散餘弦變換（DCT）

影像被切分為 8 × 8 像素塊。每個塊經過 DCT，將空間資料（像素值）轉換為頻率資料（數值在塊內的變化速度）。結果是一個 8 × 8 的係數矩陣。左上角的值是 DC 係數——該塊的平均亮度。其餘 63 個是 AC 係數，代表越來越高頻的細節。

高頻係數編碼精細紋理：頭髮、草葉、雜訊。低頻係數編碼寬泛形狀：天空、牆面、膚色。

4. 量化（Quantization）

有損壓縮發生在這裡。JPEG 對每個 DCT 塊應用一張量化表。這張表是另一個 8 × 8 的除數矩陣。每個 DCT 係數被對應的量化值除，並四捨五入到最近的整數。

標準量化表對高頻係數打擊最重：

16  11  10  16  24  40  51  61
12  12  14  19  26  58  60  55
14  13  16  24  40  57  69  56
14  17  22  29  51  87  80  62
18  22  37  56  68 109 103  77
24  35  55  64  81 104 113  92
49  64  78  87 103 121 120 101
72  92  95  98 112 100 103  99

一個高頻係數，比如 7，被 121 除並四捨五入為 0。它消失了。不可逆。解碼器再也看不到它。這就是有損壓縮：資料被銷毀，而非僅僅重新編碼。

在品質 90 時，量化值被更小的縮放因子除。在品質 50 時，縮放因子更大。更多係數歸零。檔案更小。影像更柔和。

5. 熵編碼（Entropy Coding）

量化後，剩餘的係數經過 zig-zag 掃描、游程編碼，再用 Huffman 編碼壓縮。這一階段是無損的。它只是把已經被破壞的資料打包得更緊湊。

結果是：一張 1200 萬像素未經壓縮的 RGB 影像為 36 MB。以 JPEG 品質 90、4:2:0 子採樣儲存後，降到約 3.5 MB。這是 10:1 的縮減，只有在放大時才能看到可見的品質損失。

它到底多有損？

損傷並非均勻分布。

品質	典型大小（1200 萬像素）	視覺影響
95+	~8 MB	幾乎不可見；適合歸檔
90	~3.5 MB	輕微柔化；相機預設標準
75	~1.8 MB	精細細節可見模糊；網頁預設
50	~1.0 MB	100% 放大時塊效應明顯
30	~600 KB	色帶、蚊狀雜訊，無法用於印刷

隨著品質下降，會出現三種明顯的偽影：

塊效應（Blocking）：可見的 8 × 8 網格邊緣，尤其在平滑漸變（如天空）中。
振鈴（Ringing）：高對比度邊緣周圍出現振盪光暈（如文字與背景交界處）。
顏色溢出（Color bleeding）：色度子採樣將顏色抹過銳利邊界。

真正的殺手是代際損失（generation loss）。開啟一張 JPEG，編輯它，再存為 JPEG。每次儲存都會重新跑完整條管線：RGB → YCbCr → 子採樣 → DCT → 量化。四捨五入誤差不斷累積。10 代之後，影像看起來像水彩畫。50 代之後，面目全非。

綠色偏移與其他重壓縮怪象

反覆重存 JPEG，你可能會注意到色溫在漂移。有些影像泛出淡淡的綠色，有些則偏向洋紅。原因藏在色度通道裡。

JPEG 以降低的解析度儲存 Cb 和 Cr，並對它們進行激進的量化。每次儲存都會在這兩個通道引入捨入誤差。轉回 RGB 時使用的是這個矩陣：

R = Y + 1.402 × (Cr - 128)
G = Y - 0.344136 × (Cb - 128) - 0.714136 × (Cr - 128)
B = Y + 1.772 × (Cb - 128)

注意，綠色由 Cb 和 Cr 共同計算。當反覆量化使 Cb 向上偏移、Cr 向下偏移哪怕一個量化步長時，G 通道就會漂移。Cb 的正偏壓會把綠色往下推。Cr 的負偏壓會把綠色往上推。這種交互並不對稱，因為係數 -0.344136 和 -0.714136 的幅值不同。結果是：某些影像區域綠色緩慢累積，尤其是原始色度值已經接近量化邊界的地方。

這不是必然發生的效果。它取決於編碼器的量化表、子採樣模式以及影像內容。但它是真實的、可複現的，也是專業工作流避免重存 JPEG 的原因之一。

如果 JPEG 這麼多缺陷，為什麼所有東西都在用它？

JPEG 流行不是因為它完美。它流行是因為它夠好，且無所不在。

無專利鎖定：基礎 JPEG 專利（由 Forgent Networks 持有）於 2006 年到期。該格式免權利金。
硬體解碼：每台相機、手機、印表機和瀏覽器都在晶片或高度最佳化的 C 程式碼中內建了 JPEG 解碼器。渲染成本幾乎為零。
夠用了：對於社交媒體、新聞網站和郵件附件，在手機螢幕上，品質 75 的 JPEG 與來源檔案幾乎無法區分。
生態慣性：內容管理系統、CDN、影像庫和遺留檔案都認 JPEG。替換它們需要的不僅僅是更好的格式，還需要一個理由去遷移 PB 級的現有資產。

那些本該贏的格式

已有多種格式試圖取代 JPEG。沒有一種完全成功。

格式	有損	無損	透明	動畫	最大位元深度	核心優勢
JPEG	是	否	否	否	8-bit	通用支援
PNG	否	是	是	否	16-bit	完美無損，支援透明
WebP	是	是	是	是	8-bit	比 JPEG 小 25–35%，瀏覽器原生支援
HEIC	是	是	是	是	16-bit	比 JPEG 小約 50%，Apple 預設格式
AVIF	是	是	是	是	12-bit	當今最佳壓縮率，免權利金
JPEG XL	是	是	是	是	32-bit	無損 JPEG 重壓縮，漸進式解碼

PNG 解決了無損問題，但對照片產生的檔案比 JPEG 大 5–10 倍。它統治了螢幕截圖、UI 素材和圖形領域。

WebP（Google，2010）在體積上擊敗 JPEG，並增加了透明和動畫支援。它現已內建在所有主流瀏覽器中。2025 年 Web Almanac 顯示，WebP 在 LCP 影像中佔比 11%，高於 2024 年的 7%。它是當下穩妥的升級路徑。

HEIC（Apple，2017）在 ISOBMFF 容器中使用 HEVC 壓縮。它比 JPEG 小約 40–50%，且單檔案可存多圖。它統治了 Apple 生態，在其他地方則停滯不前，原因在於 HEVC 專利池。

AVIF（AOM，2019）源自 AV1 影片。它在所有廣泛支援的格式中實現了最佳壓縮比——同等品質下比 WebP 小約 30%。缺點是解碼速度。在行動裝置上，AVIF 影像的渲染時間可能比 JPEG 長 2–3 倍，消耗電量並延遲最大內容繪製（LCP）。

JPEG XL（ISO/IEC 18181，2021）在技術上優於以上所有。它比 JPEG 小 50–60%。解碼速度快。它支援漸進式解碼：僅下載約 1% 的檔案後即可顯示可用影像。最重要的是，它可以對現有 JPEG 進行無損重壓縮，節省約 20% 的體積，並能逐位元恢復原始檔案。沒有其他格式能做到這一點。

JPEG XL 的童年很坎坷。Google 於 2021 年在 Chrome 中加入了實驗性支援，隨後在 2022 年 10 月 31 日將其移除——即「萬聖節決定」。官方理由是：相對於現有格式的增量收益不足。反彈立竿見影。該 Chromium issue 成為專案歷史上獲得 star 數第二高的議題。Google 被指責是在保護 AVIF——一個與 Google 聯合創立的 Alliance for Open Media 綁定的格式。

2025 年底，Chromium 改變了方向。一個新的 Rust 解碼器（jxl-rs）進入了 Chrome Canary。Chrome 145 於 2026 年 2 月發布，在旗標（flag）後支援了 JPEG XL。Safari 自 2023 年起已支援它。Firefox Nightly 正在整合同一個 Rust 解碼器。JPEG XL 尚未預設啟用，但它已回到程式碼庫中。

與此同時，AVIF 是 2026 年的務實選擇。瀏覽器支援廣泛。編碼器在改進。Cloudinary 和 Cloudflare 都透過 Accept 頭協商自動提供 AVIF。根據 CoreDash 資料，提供 AVIF 或 WebP 的頁面 median LCP 良好率達到 81%，而僅提供 JPEG 的頁面為 64%。

底線

JPEG 是一個 33 歲的妥協。它用顏色解析度、高頻紋理和數值精度換取了 1990 年代讓數位攝影得以實現的檔案大小。偽影已被充分理解。代際損失真實存在。綠色漂移也會發生。

然而 JPEG 依然存續，原因與 QWERTY 鍵盤相同：遷移成本高於忍受現狀的痛苦。

實際的推進路徑是分層的：

保留高品質母版。將原始檔案以 PNG、TIFF 或品質 95+ JPEG 歸檔。永遠不要從品質 75 的網頁匯出檔案重新編輯。
動態提供現代格式。使用能根據瀏覽器 Accept 頭協商 AVIF、WebP 或 JPEG XL 的 CDN 或影像服務。只存一份母版；讓邊緣節點按需轉換。
不要批次重編碼 JPEG。每一代都在銷毀資料。如果你需要更小的檔案，從母版重新編碼，而不是從另一個 JPEG 重編碼。

JPEG 不會突然死亡。它會像 GIF 一樣逐漸淡出：仍然到處支援，仍然在每個檢視器中開啟，但越來越多地被用更少位元組和更少偽影完成同樣工作的格式超越。不同之處在於，這一次，替代格式真的在贏。