Base64URL 與標準 Base64：字母表、填充和 URL 解析

識別連字元和下劃線，理解填充約定，避免查詢引數把加號變成空格。

Base64URL 只替換兩個字母表字元：標準版的加號變成連字元，斜槓變成下劃線。資訊沒有變化。它適合外層協議會特殊處理加號或斜槓的場景，但不能因此忽略其他 URL 與應用規則。

使用能體現差異的樣本

FB FF 兩個位元組的標準編碼為 +/8=，URL-safe 編碼為 -_8=。Hello 之類樣本可能只產生兩種字母表共有的字元，無法判斷選項是否有效。

const standard = btoa(String.fromCharCode(251, 255));
const urlSafe = standard.replace(/\+/g, '-').replace(/\//g, '_');
console.log(standard); // +/8=
console.log(urlSafe); // -_8=

填充是另一項約定

許多令牌格式省略末尾等號，另一些系統保留。替換字母表與移除填充是不同選項。無填充長度除以四餘二時，需要補兩個等號；餘三補一個；餘一無法僅靠填充修復，因為一個六位字元不足以表示完整位元組。

校驗時還要檢查最後字元的未使用位。忽略它們的解碼器可能接受多個字串表示同一位元組，在直接比較編碼字串時產生歧義。規範編碼應輸出統一形式。

區分查詢解析與 Base64 解碼

表單式查詢引數解析會把字面加號變成空格。標準 Base64 未轉義就放入查詢引數，可能在解碼前已損壞。應使用 URLSearchParams 構建引數，或按接收協議選擇 Base64URL。

const query = new URLSearchParams({ payload: '+/8=' });
console.log(query.toString()); // payload=%2B%2F8%3D
console.log(query.get('payload')); // +/8=

不要自動把全部空格替換成加號：空格可能來自真實格式或另一類錯誤。先儲存原文，定位改變資料的傳輸層，再明確修正。JWT 應使用其格式規定的規則。字母表定義見 RFC 4648，填充、空白和長度限制仍由具體整合決定。