如何在不安裝軟體的情況下線上批次轉換圖片

你旅行回來，手機裡有 200 張 HEIC 照片。Windows 筆電打不開它們，你的 Web 應用需要 JPEG 格式，而你常用的照片分享網站徹底拒絕 HEIC。你可以一張一張地轉：每張照片點四下，200 張就是 800 次點擊，半個下午就沒了。或者，你可以把資料夾拖進瀏覽器分頁，然後走開，讓它自己跑完。

這就是批次轉換工具存在的意義，而基於瀏覽器的版本和你用過的桌面軟體工作方式不太一樣。

批次轉換到底是什麼意思

批次轉換不是「轉換一張，重複一次」。真正的批次管線會在可能的情況下並行完成三件事：

讀取：解析每個檔案的檔案頭確認格式。.heic 副檔名說明不了任何問題。管線會讀取前 12 個位元組，檢查 ftyp box 中的 heic/heif/mif1 標記，在接觸像素資料之前就把不匹配的檔案剔除。
解碼：將來源檔案解壓為原始像素資料。對於 HEIC 檔案，這意味著執行一個 WebAssembly 編譯的 libheif。對於 JPEG 和 PNG，瀏覽器自帶的解碼器直接處理。這一步是 CPU 密集型的，也是整個流程的瓶頸。
編碼：將原始像素資料壓縮為目標格式。JPG 以 90 品質編碼，PNG 使用 DEFLATE，WebP 使用瀏覽器內建編碼器。

桌面軟體做的是同樣的三步。差別在於 CPU 週期消耗在哪裡：無論如何都是在你的機器上，但在瀏覽器分頁裡，你不需要安裝程式、不需要管理員權限、桌面也不會留下一堆暫存檔案。

支援的格式組合

並非每種格式都能很好地轉換為另一種。真正有用的矩陣如下：

來源格式	轉 JPG	轉 PNG	轉 WebP	轉 ICO
HEIC	支援	支援	支援	不支援
JPG	不支援	支援	支援	支援
PNG	支援	支援	支援	支援
WebP	支援	支援	不支援	支援
BMP	支援	支援	支援	支援

空白格子不是功能缺失。HEIC 轉 ICO 是沒有意義的轉換：一張數 MB 的照片縮成 256×256 的圖示檔案，照片的一切特質都喪失了。工具直接跳過了這些無意義的路徑。

PDF 頁面走獨立管線。每一頁透過 PDF.js 渲染到畫布，然後編碼為目標格式。我們的 PDF 轉 JPG、PDF 轉 PNG 和 PDF 轉 WebP 轉換器會自動批次處理所有頁面。

操作步驟詳解

1. 一次性全部拖入

開啟轉換器頁面。從檔案管理員裡把一個資料夾拖到拖放區域。你也可以點擊開啟檔案選擇器然後選中多個檔案，Ctrl+A 在這裡也能用。

拖放區域直接從瀏覽器的拖曳事件中讀取 FileList 物件。沒有任何上傳。檔案以 File 物件的形式留在記憶體裡——這些物件只是指向磁碟上 blob 的參照，包含檔名、檔案大小和根據副檔名推測的 MIME 類型。

2. 讓驗證程式跑一遍

每個檔案在解碼前都會被檢查。對於 HEIC 檔案，驗證器會像上面說的那樣讀取 ftyp box。對於其他格式，瀏覽器的 createImageBitmap() 要麼成功（有效的圖片），要麼拋出例外（損壞的或被誤標記的檔案）。

無效檔案會被標上紅色標記並給出原因：「不是有效的 HEIC 檔案」、「不支援的格式」、「檔案超過 200 MB」。它們不會阻塞其他檔案的處理。有效檔案進入處理佇列。

3. 選擇輸出格式

每個轉換器頁面面向特定的輸出格式。如果你需要 HEIC 轉 JPG，就用 HEIC 轉 JPG 頁面。需要 HEIC 轉 PNG？用 HEIC 轉 PNG。輸出格式在每個頁面上是固定的，這讓介面保持簡潔：沒有下拉選單，沒有困惑。

品質設定因格式而異。JPG 提供品質滑桿（10–100，預設 90）。PNG 始終是無損的，所以不需要滑桿。WebP 的品質滑桿行為與 JPEG 不同：WebP 的 80 大致相當於 JPEG 的 92，適用於照片類內容。

4. 等待（短暫的）

處理時間取決於三個因素：檔案數量、檔案大小和你的 CPU。一台現代 8 核心筆電大約每秒能處理 2–4 次 HEIC 轉 JPG。200 張 iPhone 照片的資料夾不到兩分鐘就能完成。

每個檔案透過 requestAnimationFrame 分片執行，這樣介面始終保持回應。進度條顯示的是檔案級別的進度，不是位元組級別的：每個檔案走一格，無關大小。

5. 下載

你有兩種選擇：

逐個下載：每個轉換後的檔案單獨下載。瀏覽器的下載管理員原生處理這個，到處都能正常運作。

ZIP 封裝：所有轉換後的檔案打包成一個 .zip。透過串流 ZIP 實作在記憶體中構建，檔案即時壓縮，不需要暫存儲存空間。

原始檔名保留，只改副檔名。IMG_4021.HEIC 變成 IMG_4021.jpg。

品質與體積的取捨

轉換格式意味著要對檔案體積做出選擇：

轉換	典型體積變化	品質說明
HEIC → JPG (q90)	約大 2 倍	正常縮放下視覺無差異
HEIC → PNG	約大 5–8 倍	無損，但對照片來說小題大做
HEIC → WebP (q80)	約大 1.2 倍	同等品質下比 JPEG 更小
PNG → JPG (q90)	約小 3–5 倍	透明區域變成白色背景
BMP → JPG (q90)	約小 10–20 倍	BMP 儲存原始像素，JPG 將其壓縮
JPG → PNG	約大 5–10 倍	不會提升品質，只是阻止進一步劣化

HEIC 轉 PNG 是人們經常踩的坑。HEIC 本身就是有損的。把有損格式轉成無損格式並不能恢復畫質，只是把當前狀態凍結下來，檔案體積大了 5 倍。對於要放到網頁上的照片，HEIC 轉 JPG 或 WebP 是誠實的路徑。對於要進入編輯器處理的照片，PNG 有意義，因為它能防止後續儲存時的代際損失。同樣的邏輯適用於所有類似場景。參見我們的有損與無損壓縮指南了解完整解釋。

瀏覽器 vs 桌面 vs 伺服器

	瀏覽器端	桌面軟體	伺服器/雲端
安裝	無需	下載 + 安裝	無需
隱私	檔案留在本地	檔案留在本地	檔案上傳到伺服器
速度	WebAssembly（接近原生）	原生	網路上傳 + 排隊 + 下載
批次大小	受記憶體限制（~500+ 檔案）	受磁碟限制	免費方案通常設上限
更新	始終最新	手動更新	始終最新

對大多數人來說，瀏覽器端轉換器處於最佳位置：無需安裝、無需上傳，而且速度足夠快——在近五年內生產的任何裝置上，與原生應用的差異幾乎無法感知。

WebAssembly 這個細節很重要。HEIC 解碼器是一個編譯為 WASM 的 C 函式庫（libheif），執行在沙箱中。它沒有檔案系統存取權限、沒有網路存取權限，無法以任何方式把你的資料傳送出去。瀏覽器在引擎層面強制執行這些邊界，而不是在應用層面。更多架構細節參見我們的 WebAssembly 詳解和瀏覽器隱私深度剖析。

批次轉換什麼時候會出問題

有幾件事會讓批次執行直接中斷：

在錯誤的轉換器裡混入不同格式。 把 JPEG 拖進 HEIC 轉 JPG 的頁面。驗證器會捕捉到這些檔案並跳過它們。被拒絕的檔案會有清晰的標籤，你可以把它們重定向到正確的轉換器。
超大批次導致記憶體耗盡。 處理兩千張 2400 萬畫素的原始檔案最終會撞上瀏覽器的記憶體限制。解決辦法是把批次拆成幾百張一份。對於典型的手機照片（1200 萬畫素、約 2 MB HEIC），每次跑 500+ 張毫無問題。
Safari 的下載行為。 Safari 對並行下載的限制比 Chrome 或 Firefox 更嚴格。單個下載沒問題。ZIP 下載徹底繞過了這個問題：一個檔案，沒有並行問題。