開發工具

兩種編碼，兩個任務 Base64 和 URL 編碼都會把「不安全」的字元替換成安全字元。這種表面相似，正是它們經常被搞混的原因——要嘛該用一種卻用了兩種，要嘛乾脆用錯了。 一句話版本： Base64 讓二進位資料能通過只支援文字的通道 百分比編碼 讓文字能安全地放進 URL 各自到底做了什麼 Base64 用 64 個字元的字母表（A–Z a–z 0–9 + /，結尾用 = 補齊）重寫位元組。每 3 個位元組變成 4 個字元，體積因此增加約 33%。 Man → TWFu Hello → SGVsbG8= 百分比編碼把在 URL 裡不安全的字元替換成 % 加兩個十六進位數字（對應 UTF-8 位元組）。 a b → a%20b 書籤管理 → %E6%9B%B8%E7%B1%A4%E7%AE%A1%E7%90%86 a&b → a%26b 關鍵差別 Base64 百分比編碼 目的 讓二進位穿過文字通道 讓文字安全地待在 URL 裡 字元集 固定的 64 個字元 任意位元組，寫成 %XX 體積變化 +33% 變化很大 誰能還原 任何人 任何人 提供安全性 否 否 常見位置 JSON 欄位、data URI、郵件附件、JWT 查詢參數、路徑片段 什麼時候用 Base64 把小型圖片以 data URI 內嵌進 CSS 或 HTML 在 JSON 裡傳檔案、縮圖或簽章 透過 MIME 寄送郵件附件 構造 Authorization: Basic 請求標頭 JWT 的 header 與 payload 段 需要雙向轉換時，直接用 Base64 編解碼工具，不用裝任何東西。 ...

Base64 要解決什麼問題 很多系統只傳「文字」：郵件協定為 7 位元 ASCII 設計，JSON 定義為文字，HTML 屬性裡放的是字串。但我們真正想傳輸的東西——圖片、PDF、金鑰、二進位協定資料——是位元組串流，裡面很容易混進控制字元、引號與換行。 把原始二進位直接塞進文字通道，遲早會出問題：換行被改寫、引號提前結束字串、代理伺服器吃掉一個位元組。Base64 的做法是：只用 64 個所有文字系統都認得的字元重新表示這些位元組。 A–Z a–z 0–9 + / 結尾的 = 只用於補齊。整個字母表就這些。 Base64 的原理 Base64 每處理 3 個位元組（24 位元），就把他們重寫成 4 個字元（4 × 6 位元）： 輸入 位元數 輸出 Man 24 位元 TWFu Ma 16 位元 + 補齊 TWE= M 8 位元 + 補齊 TQ== 由此直接得到兩個結論： 結果大約比原文大 33%（3 個位元組變成 4 個字元） = 的數量告訴解碼器最後一組缺了幾個位元組，一個或兩個 = 表示結尾不完整 Base64 是可逆的、完全公開的編碼，沒有金鑰，也沒有任何保密性。 日常開發中在哪裡遇到 Base64 Data URI：background-image: url(data:image/png;base64,...) 把小圖示直接內嵌進 CSS JSON 介面：在 JSON 欄位裡傳檔案、縮圖或簽章 郵件附件：MIME 用 Base64 編碼附件，讓它們能穿過只支援文字的郵件伺服器 HTTP Basic 認證：Authorization: Basic dXNlcjpwYXNz 就是 user:pass 的編碼結果 JWT：Token 的 header 與 payload 兩段都是 Base64URL 字串 Base64 不是加密 這是最重要的一點：Base64 不提供任何保密性。 ...

為什麼 JSON 總是難以閱讀 每個介面回傳、每份設定檔、每行日誌都是 JSON。壓縮後它是一整塊字元牆；格式化之後同樣的資料兩秒就能掃完。資料完全相同，差的只是空白——這也是「JSON 格式化」成為開發者最常用搜尋之一的原因。 格式化、壓縮、驗證的差別 操作 改變什麼 什麼時候用 格式化 加縮排與換行 閱讀、審查、排查問題 壓縮 去掉所有多餘空白 傳輸、儲存設定 驗證 不改內容，只報語法錯誤 送出請求或提交設定前 這三件事在 JSON 格式化工具 裡都只差一次點擊，而且全程在瀏覽器本機完成。 什麼才算合法的 JSON JSON 的語法非常小，而且比 JavaScript 嚴格得多： 鍵名必須用雙引號包起來 字串必須用雙引號，單引號不合法 不允許多餘的逗號 不允許註解（// 和 /* */ 都不行） 值只有這幾種：物件、陣列、字串、數字、true、false、null 數字不能有多餘的前導零，NaN／Infinity 也不是合法值 如果你寫過 JSON5、JSONC（VS Code 設定）或 JavaScript 物件實字，其中一些習慣在 JSON 裡是違法的。 最常踩的五個錯誤 1. 多了一個逗號 { "name": "NavShelf", "version": "1.0", } "1.0" 後面那個逗號，是 JSON 錯誤的第一大來源。 2. 用了單引號 { 'name': 'NavShelf' } JavaScript 合法，JSON 違法。 3. 鍵名沒加引號 { name: "NavShelf" } 同樣：JavaScript 合法，JSON 違法。 ...

一個典型的壞連結 你拼了一個搜尋連結，英文下一切正常，使用者一輸入中文就掛： https://example.com/search?q=書籤管理 & page=2 伺服器收到的 q 是 書籤管理 ，還多了一個叫 page 的參數——本來屬於查詢值的 & 被當成了分隔符。#、=、?、+ 和空白也有同樣的問題。 解決辦法是百分比編碼（URL 編碼）：把不安全的字元替換成 % 加兩個十六進位數字，表示它的 UTF-8 位元組。 書籤管理 → %E6%9B%B8%E7%B1%A4%E7%AE%A1%E7%90%86 & → %26 空白 → %20 哪些字元是安全的 RFC 3986 把字元分成「未保留」與「保留」兩類，只有未保留字元可以原樣出現： 類別 字元 說明 未保留 A–Z a–z 0–9 - _ . ~ 任何位置都安全 保留（結構類） : / ? # [ ] @ 在 URL 中有結構意義 保留（子分隔符） ! $ & ' ( ) * + , ; = 在查詢字串中有意義 其他 空白、"、<、>、%、{}、中文⋯ 必須編碼 保留字元不是「不能用」，而是「有意義」。關鍵問題永遠是：這個 & 是想表達結構，還是想表達資料？如果是資料，就編碼它。 ...