Base64、Hex、百分號編碼與 Base85：按傳輸場景選擇

編碼必須由兩端共同約定才有意義。字元最少的表示不一定最好：接收方可能只接受特定字母表，人可能需要手工輸入，外層語法也可能賦予某些標點特殊含義。先檢查目標協議。

Hex 易讀，但體積更大

十六進位制每個位元組使用兩個字元。FF 00 41 寫成 ff0041，每兩個字元都有明確的位元組邊界，適合檢視檔案頭、校驗和與網路報文。字元數量翻倍，但小型字母表容易進入日誌和除錯工具。

Base64 適合常見二進位制傳輸

Base64 每三個位元組對應四個字元。標準版使用加號與斜槓，Base64URL 按協議替換它們。兩端仍需約定填充和空白規則。它們都不會說明解碼後的內容究竟是文本、圖片還是壓縮資料。

百分號編碼面向 URL 元件

百分號編碼把需要轉義的位元組寫成 %HH。哪些字元需要轉義取決於 URL 元件。文本先轉為 UTF-8，再編碼。斜槓可能分隔路徑，問號可能開始查詢；把整個 URL 當成一個元件，會改變含義。

console.log(encodeURIComponent('a+b / 中文'));
// a%2Bb%20%2F%20%E4%B8%AD%E6%96%87

Base85 必須說明變體

許多 Base85 方案用五個字元表示四個位元組，但字母表、分隔符和特殊縮寫不同。ASCII85 與 Z85 不能直接互換，Z85 還有塊長度要求。外層格式如果需要再次轉義標點，密度優勢也可能縮小。

這些位元組編碼與把整數 255 轉為不同進位制不是一回事。檔案可以有前導零位元組，整數表示卻可能丟棄前導零。無損檔案編碼必須定義長度與前導零的儲存方式。

檢查位元組用 Hex，通用二進位制傳輸使用協議規定的 Base64 變體，URL 使用元件編碼，專用方案則要求雙方實現相同契約。應比較轉義和壓縮後的總成本。Base16、Base32、Base64 的標準見 RFC 4648。