前端

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 不提供任何保密性。 ...

一個典型的壞連結 你拼了一個搜尋連結，英文下一切正常，使用者一輸入中文就掛： 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 中有結構意義 保留（子分隔符） ! $ & ' ( ) * + , ; = 在查詢字串中有意義 其他 空白、"、<、>、%、{}、中文⋯ 必須編碼 保留字元不是「不能用」，而是「有意義」。關鍵問題永遠是：這個 & 是想表達結構，還是想表達資料？如果是資料，就編碼它。 ...