您輸入的內容不會被儲存,轉換後在同一請求中傳回。
您輸入的內容不會被儲存,轉換後在同一請求中傳回。
日誌裡的權杖、重新導向裡的查詢字串、滿是 & 的郵件內文,工作中到處都會遇到編碼過的文字。貼到這裡,選擇格式,邊輸入邊看到編碼或解碼的結果。
JSON Web Token 由三段 Base64URL 以點連接而成:標頭、酬載和簽章。貼上中間那段,選擇 Base64URL 並解碼,就能看到 JSON 宣告,例如使用者 id 和到期時間 exp(一個 Unix 時間戳,可用 Unix 時間戳轉換工具讀取)。解碼不等於驗證:任何人都能讀出 JWT 的酬載,只有伺服器上的簽章檢查才能證明它沒有被竄改。
有些系統為了節省空間會拿掉 Base64 的填補字元,這樣的資料在嚴格的解碼器裡會失敗;本工具會補上缺少的 = 號並告訴你。許多伺服器把查詢字串裡的 + 當成空格,所以未經編碼直接貼進連結的 Base64 值抵達時已經損壞;請把它當作 URL 元件編碼,或改用 Base64URL。被編碼兩次的文字會顯示為 %2520 或 &,需要解碼兩次。
Base64 解碼會忽略空格與換行,所以像電子郵件裡那樣被折成多行的值,貼上後可直接解碼。Base64URL 解碼也接受 + 和 /,但一般 Base64 不接受 - 和 _,因此 JWT 的各段需要選 Base64URL。十六進位解碼會略過空格、冒號、逗號、連字號和 0x 前綴,所以 48:65:6c:6c:6f 和 0x48 0x65 都能解碼。URL 解碼會把 + 變成空格,所以真正的加號必須寫成 %2B。HTML 編碼會跳脫 & < > " 和 ' 這五個字元;HTML 解碼能識別 HTML5 的所有具名實體,例如 和 …,以及數字實體,例如代表盧比符號的 ₹。
這裡的 URL 編碼針對單一值,例如一個查詢參數,因此所有保留字元都會被跳脫:https://example.com/a b?x=1&y=2 會變成 https%3A%2F%2Fexample.com%2Fa%20b%3Fx%3D1%26y%3D2。只編碼要放進連結的那個值,不要編碼整個連結。ASCII 以外的文字按 UTF-8 位元組編碼:café ₹ 會變成 caf%C3%A9%20%E2%82%B9,十六進位顯示的是同樣的位元組,é 為 c3 a9,₹ 為 e2 82 b9。user:pass 的 Base64 是 dXNlcjpwYXNz,正是 HTTP Basic Authorization 標頭攜帶的值(RFC 7617),所以任何看到該標頭的人都能讀出密碼。
這些位元組原本是 UTF-8,但在編碼之前被某個環節當成 Latin-1 或 Windows-1252 讀取了。這裡的解碼如實顯示位元組,問題需要在產生它們的系統裡修正。
最多可貼上 200,000 個字元的文字。對於圖片等二進位檔案,解碼後的位元組會以十六進位顯示,而不會產生下載檔案。
不是。Base64 只是改變位元組的書寫方式,讓它們能通過只接受純文字的系統。任何人都能解碼,切勿用它來隱藏密碼或機密。
Base64URL 把 "+" 和 "/" 換成 "-" 和 "_",通常也拿掉 "=" 填補字元,因此結果可以安全地放進 URL 和檔名。JSON Web Token 使用的就是它。
不會。文字在同一次請求中轉換並傳回,從不寫入資料庫或日誌。
本工具還會跳脫 ! ' ( ) 和 *,而 encodeURIComponent 會保留它們,所以 it's (50%) off! 會變成 it%27s%20%2850%25%29%20off%21。兩種寫法解碼後是同一段文字,在查詢參數值裡跳脫這些字元總是安全的。空格變成 %20 而不是 +;+ 的寫法來自 HTML 表單編碼,這裡的解碼器兩種都能辨識。
在 Linux 或 Mac 上,echo -n 'Hello, World' | base64 會得到 SGVsbG8sIFdvcmxk,echo 'SGVsbG8sIFdvcmxk' | base64 --decode 再把它還原成文字。如果省略 -n,echo 會多加一個換行字元並一起編碼,結果變成 SGVsbG8sIFdvcmxkCg==:這是兩個工具結果不一致最常見的原因。在 PowerShell 中,[Convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes('Hello, World')) 用於編碼,[Text.Encoding]::UTF8.GetString([Convert]::FromBase64String('SGVsbG8sIFdvcmxk')) 用於解碼。本頁以 UTF-8 精確編碼你貼上的字元,不會額外加上換行字元。
只貼上逗號後面的部分:在 data:image/png;base64,iVBORw0KGgo... 中就是 iVBORw0KGgo...,因為 data:image/png;base64, 前綴不是 Base64,整串貼上會被拒絕。選擇 Base64 和 Decode。不是文字的位元組會以十六進位顯示,而不是畫成圖片,但這足以判斷檔案類型:PNG 以 89 50 4e 47 開頭,JPEG 以 ff d8 ff 開頭,完整的 .docx、.xlsx 或其他以 ZIP 為基礎的檔案以 50 4b 03 04 開頭。想看圖片本身,把完整的 data URI 貼到瀏覽器網址列即可。輸入上限為 200,000 個字元,約等於 150,000 位元組的檔案。
Base64 把每 3 個位元組寫成 4 個字元,最後一組用 = 補齊到 4 的倍數(RFC 4648),所以輸出是輸入位元組數的 4/3,無條件進位。Hello, World 是 12 位元組,變成 16 個字元 SGVsbG8sIFdvcmxk。計算的是 UTF-8 位元組而不是字數:café 是 4 個字元但有 5 位元組,結果為 Y2Fmw6k=;₹100 是 6 位元組,結果為 4oK5MTAw。一個中文字在 UTF-8 中通常佔 3 位元組,所以中文文字的 Base64 比字數長得多。電子郵件附件還會再大一點,因為 MIME 會把 Base64 按每行最多 76 個字元斷行(RFC 2045);本頁解碼時會忽略這些換行。不帶填補的 Base64URL 只省下 = 號。