URL 解碼速查表是一份快速參考，將百分比編碼字元對應回可讀的形式:%20 是空格，%2F 是斜線，%3F 是問號，依此類推，讓你讀取任何網址時不必猜測這些代碼的含義。如今使用這類速查表最快的方式是 URL 解碼器，這是一個免費的瀏覽器工具，可以立即將任何百分比編碼字串轉回純文字，並正確處理中文、腔調符號和表情符號的 UTF-8 編碼。你不再需要翻閱印刷表格，只要貼上編碼後的 URL，選擇模式，就能讀出原始字元。本文將逐一說明你最常遇到的編碼、示範在瀏覽器中解碼 URL 的完整工作流程、解釋如何讀取像表情符號和 CJK 文字這類多位元組序列，並說明當解碼失敗時該如何處理，讓你能修正來源而非送出損壞的資料。
百分比編碼快速參考
下方表格列出你在實際網址中最常見的字元編碼。這些對應直接來自 RFC 3986，也就是定義 URI 撰寫方式的標準，所以無論你在讀取搜尋引擎查詢、API 回應，或是 OAuth 回呼連結，這些對應都同樣適用。保留字元會被編碼，以維持 URL 的明確性;不安全字元也會被編碼，因為它們的位元組序列在僅限 ASCII 的位址文法中沒有立足之地。這兩組合起來，就是你在日常中會遇到的百分比代碼。
| 字元 | 編碼 | 出現位置 |
|---|---|---|
| 空格 | %20 | 搜尋詞彙、檔名 |
| ! | %21 | 登入欄位、簽署請求 |
| # | %23 | 片段標記 |
| $ | %24 | 查詢字串中的貨幣 |
| & | %26 | 參數分隔符 |
| + | %2B | 字面加號 |
| , | %2C | 清單分隔符 |
| / | %2F | 路徑分隔符 |
| : | %3A | 連接埠號碼、通訊協定 |
| = | %3D | 鍵與值配對 |
| ? | %3F | 查詢字串的開頭 |
| @ | %40 | 使用者資訊分隔符 |
這份表格刻意保持精簡。記住上面這十幾個代碼，就能涵蓋實際 URL 中大部分會出現的編碼。如果遇到這份清單以外的編碼，解碼器本身就成為你的速查表:貼上編碼字串，選擇「完整 URL」模式以保持位址結構完整，然後讀取結果。
如何在瀏覽器中解碼 URL
當你需要讀取百分比編碼的 URL，或從查詢參數中取出原始值時，請依下列步驟操作。
- 在瀏覽器中開啟 URL 解碼器。該頁面完全以本地 JavaScript 執行，因此你的輸入內容不會上傳到任何伺服器。
- 選擇範圍。當你擁有完整的網址且希望保留其結構(通訊協定、主機、斜線、問號、井字號)時，選擇完整 URL。當你只有單一查詢值、路徑片段或片段識別碼，且需要將每個保留字元都進行編碼時，選擇URL 元件。
- 將方向設定為解碼，百分比編碼的文字就會被轉回可讀字元。
- 將編碼字串貼入輸入框。輸入時結果會即時更新，任何格式錯誤的百分比序列都會觸發清楚的錯誤訊息，而不是產生損壞的字串。
- 點擊複製將解碼後的文字放入剪貼簿，然後貼到你的編輯器、試算表、終端機或聊天視窗中。
如果你也需要反向操作，例如從包含空格或符號的值建構安全的查詢字串，只要在保留相同範圍和文字的情況下，將方向切換為編碼即可。
保留字元與其編碼原因
URL 是有結構的字串，這個結構依賴一小組保留字元執行特定工作。問號分隔路徑與查詢字串;& 符號分隔一個參數與下一個參數;等號分隔鍵與值;井字號則標示片段的開始。如果這些字元出現在值內部而非作為分隔符，周圍的 URL 就會被破壞，因為解析器會看到兩個參數而不是一個。
百分比編碼透過將每個保留字元替換為百分比符號加上其位元組的兩位十六進位值來解決這個問題。因此空格變成 %20，斜線變成 %2F，解析器就知道把這三個字元視為單一字面位元組，而不是分隔符。同樣的規則也保護位址中完全不被 URL 文法允許的字元，例如空格、帶腔調字母、CJK 字元和表情符號。
元件模式是嚴格的選擇:它會編碼所有保留字元，再加上幾個額外字元(驚嘆號、撇號、括號和星號)，因為某些伺服器和簽署機制會特別處理這些字元。完整 URL 模式則是寬鬆的選擇:它保留構成位址結構的結構字元，只對真正不安全的字元進行編碼。元件模式 vs 完整模式指南說明了何時該使用哪種模式，而底層的 JavaScript 行為則記載於 MDN 的 encodeURIComponent 參考文件。
多位元組文字:中文、腔調符號與表情符號
百分比編碼是針對位元組而非字元。在編碼器寫出百分比序列之前，必須先將文字轉換為位元組序列，而它選擇的轉換方式至關重要。UTF-8 是現代的預設標準，也是唯一能正確處理網路上所有字元的編碼方式。在 UTF-8 中，常見的拉丁字母和數字各佔一個位元組，帶腔調字母和多數非拉丁文字佔兩個位元組，中文和日文等文字系統的字元佔三個位元組，而位於基本多語言平面之外的多數表情符號、音樂符號和罕見歷史文字則佔四個位元組。
你可以在編碼輸出中直接看到這點。像「你好」這類兩個字元的中文問候語會變成六組百分比編碼，因為每個字元佔三個 UTF-8 位元組。單一表情符號如 😊 則佔四組百分比編碼，每個位元組一組。由於解碼器會將這些百分比編碼組讀回為 UTF-8 位元組，因此能還原出完全一致的原始字元，不會出現靜默損壞、問號取代或被截斷的序列需要猜測。
這個來回轉換的測試，是區分可信賴解碼器與脆弱解碼器的關鍵。如果你將一段文字編碼、複製百分比字串、再解碼，結果讀起來仍是原本的字元，那這個工具運作正確。如果結果是一連串的問號或取代方塊，代表該工具誤解了位元組序列，它產生的 URL 將與其他系統預期的內容不符。
當解碼失敗時:讀取錯誤訊息
並非所有百分比編碼字串都是有效的。以下三種常見的格式錯誤會困擾大多數解碼器:
- 單獨的%符號後面沒有任何內容，因為沒有可讀取的位元組值。
- 百分比後面接著非十六進位數字的字元，例如 %zz，因為該位元組無法解析。
- 被截斷的多位元組序列，例如 UTF-8 的前導位元組宣告後續需要兩個、三個或四個位元組，但輸入在中途就被截斷。
一個好的解碼器會停下來並回報問題。URL 解碼器會以明確的錯誤標示格式錯誤的輸入，而不是回傳一個損壞的字串，這一點很重要，因為靜默失敗會將損壞的資料向下游傳遞到記錄檔、分析工具或下游 API，事後要找出問題會更加困難。當錯誤出現時，修正方式幾乎總是在來源端:該 URL 被截斷、手動編輯，或從某個破壞了位元組的系統複製過來。修正來源後重新解碼即可。
還有一種情況值得了解:+ 符號有時代表空格，有時代表字面加號，這取決於編碼字串的來源。在 application/x-www-form-urlencoded 資料中(也就是 HTML 表單提交所產生的格式)，加號代表空格。在嚴格的 RFC 3986 URI 中，加號就是加號。本解碼器將加號視為字面加號;如果你正在解碼表單資料，請先將每個加號替換為空格，再解碼百分比序列。
實際運用速查表
上方速查表足以讓你用肉眼讀取大多數的 URL。至於其他情況，工作流程都一樣:開啟 URL 解碼器，貼上編碼字串，選擇「完整 URL」模式以保持位址結構完整，切換到解碼，然後讀取結果。這個工具能正確保留 UTF-8、清楚回報格式錯誤的輸入，且完全在瀏覽器中執行，因此內部 URL、OAuth 回呼和簽署請求參數絕不會離開你的電腦。請將參考表隨時備在手邊以便快速查閱，當 URL 出現你無法辨識的代碼時，就交給解碼器來處理。