Alat pengembang · Encoder & decoder Base64
Base64 vs base64url: mengapa dekoder standar ditolak - dan _
· Cara kerjanya
base64 pengkodean alur kerja pengembang
base64url menukar + dan / untuk - dan _ sehingga output dapat berjalan dalam URL dan nama file tanpa keluar. Posting ini menjelaskan kedua alfabet, cara mengonversi keduanya, dan mengapa padding biasanya dihilangkan juga.
Token yang menerjemahkan kode di mana pun kecuali kode Anda — kesalahan karakter tidak valid yang disebabkan oleh satu - atau _
Segmen JWT gagal didekode dalam dekoder Base64 standar dengan tanda hubung penamaan kesalahan karakter yang tidak valid. Namun secara visual, tidak ada tanda hubung yang muncul. Lihat lagi—itu benar. Versi base64url menggunakan - di mana Base64 standar menggunakan +, dan _ di mana ia menggunakan /. Banyak dekoder hanya menerima satu alfabet, dan token yang dikodekan untuk keamanan URL akan ditolak oleh kode yang mengharapkan RFC 4648 standar Base64.
Kedua huruf tersebut setara; mengkonversi di antara mereka adalah penggantian karakter mekanis. Masalah muncul karena + dan / memiliki arti di URL. Tanda tambah mewakili spasi dalam data formulir application/x-www-form-urlencoded. Garis miring adalah pemisah jalur di URL. Jika Anda menyematkan Base64 langsung ke parameter kueri URL tanpa pengkodean persen + dan dekoder /, mungkin salah menafsirkannya.
Mengapa + dan / menjadi masalah pada URL dan nama file — arti yang dicadangkan dari / di jalur dan + sebagai spasi dalam data formulir
A + dapat dibaca sebagai spasi sebelum mencapai decoder. A / dapat membagi nilai parameter di tempat yang salah. RFC 4648 bagian 5 mendefinisikan alfabet url dasar untuk menghilangkan ambiguitas: gunakan - sebagai ganti + dan _ sebagai ganti /, sehingga keluaran aman di URL dan nama file. Kedua alfabet itu identik kecuali dua karakter.
Standar Base64 menggunakan karakter pada posisi 62 dan 63: A–Z (0–25), a–z (26–51), 0–9 (52–61), + (62), / (63). base64url menggunakan A–Z (0–25), a–z (26–51), 0–9 (52–61), - (62), _ (63). Segala sesuatu yang lain—pengelompokan ulang bit, aturan padding, pemetaan bit ke indeks—sama. Jaringan indeks untuk Base64 standar akan menghasilkan jaringan indeks untuk base64url; hanya karakter pada posisi 62 dan 63 yang akan berbeda.
Alfabet base64url dari RFC 4648 bagian 5 — dua karakter yang diganti dan alasannya tidak ada perubahan lain
Jika masukan tidak berisi indeks 62 atau 63 (tidak ada + atau / dalam standar, tidak ada - atau _ di base64url), kedua alfabet menghasilkan keluaran yang identik. Mengonversi Base64 standar ke base64url sangatlah mudah, cari dan ganti: tukar + untuk - dan / untuk _. Mendekode string base64url dalam standar Base64 memerlukan kebalikan: swap - untuk + dan _ untuk /.
Konversi bersifat simetris dan selalu valid. Jika Anda menemukan token yang gagal didekode dengan kesalahan penamaan karakter yang tidak valid - atau _, periksa apakah decoder menerima base64url. Jika tidak, terapkan substitusi karakter, dan jika inputnya berbentuk baik, decoding akan berhasil. Pertimbangkan JWT header {"alg":"HS256","typ":"JWT"} yang dikodekan sebagai base64url. Standar UTF-8 byte melalui pengelompokan ulang bit: tiga byte menjadi empat indeks, dicari dalam alfabet base64url. ToolAcre menampilkan padding sebagai pilihan encoder daripada mengikatnya ke tombol alfabet. Pemisahan tersebut adalah bukti yang berguna: keluaran aman URL mungkin diberi bantalan atau tidak, sementara dekoder menormalkan bentuk apa pun sebelum memanggil browser primitif. Alfabet dan padding adalah konvensi terkait, bukan satu saklar.
Padding di base64url bersifat opsional berdasarkan konvensi — mengapa JWT menghilangkan = dan bagaimana decoder dapat memulihkannya dari panjangnya
Jika indeksnya adalah 62, karakter keluarannya adalah -; ketika 63, outputnya adalah _. Byte identik melalui alfabet standar akan menghasilkan + pada indeks 62 dan / pada indeks 63. Mengonversi hasil base64url ke standar adalah operasi karakter demi karakter: pindai - dan ganti dengan +, pindai _ dan ganti dengan /, lalu dekode seperti biasa.
Byte yang Anda pulihkan identik karena indeksnya identik; hanya simbol yang berbeda. Padding di base64url bersifat opsional berdasarkan konvensi, meskipun standar mengizinkannya. JWT disusun sebagai tiga segmen url base64 yang dihubungkan oleh titik-titik; setiap segmen menggunakan padding jika diperlukan, tetapi banyak implementasi menghilangkannya dan mengandalkan fakta bahwa aplikasi yang memakan mengetahui panjang byte yang diharapkan.
Contoh praktis: mengonversi segmen header JWT ke Base64 standar — mengganti karakter, menambahkan padding, mendekode ke JSON
Decoder dapat memulihkan padding yang hilang dengan membagi panjang string dengan empat, menghitung sisanya, menambahkan tanda sama dengan 0, 1, atau 2. Jika panjang string bukan kelipatan empat, paddingnya hilang. Jika panjangnya kelipatan empat, string akan diisi lalu bantalannya dilucuti, atau masukan sudah merupakan kelipatan empat byte (diakhiri dengan tiga byte di blok terakhir, tidak memerlukan bantalan).
Menggabungkan segmen base64url memerlukan perhatian pada padding. Jika tiga segmen masing-masing diakhiri dengan =, penggabungan secara langsung menghasilkan string seperti AAAA=BBBB=CCCC=, dengan padding di tengah sekarang menjadi karakter liar, bukan penanda penghentian. Inilah sebabnya mengapa JWT menghilangkan padding di setiap segmen: struktur tiga segmen bersifat eksplisit, sehingga decoding berlangsung secara independen di setiap bagian, dan padding di tengah string yang digabungkan tidak diperlukan dan akan merusak penguraian.
Kesalahan umum — mencampur huruf dalam satu string, atau standar pengkodean persen Base64 alih-alih menggunakan base64url
Jika membuat muatan multi-segmen, putuskan konvensi padding di awal: sertakan dalam setiap segmen dan jangan pernah digabungkan secara langsung, atau hilangkan dan pulihkan dari panjangnya hanya saat mendekode. RFC 4648 standar adalah otoritas pada kedua alfabet. Bagian 4 menentukan Base64 standar; bagian 5 menentukan base64url. Setiap dekoder yang sesuai harus menyatakan dengan jelas alfabet mana yang diterimanya.
Kode yang menerima base64url tetapi tidak standar Base64 (atau sebaliknya) hanya mengimplementasikan subset. Alfabet url base64 ada untuk kompatibilitas dengan URL dan batasan nama file; ini bukan perbaikan atau penggantian, hanya varian untuk konteks tertentu. Saat Anda menulis API atau format token, pilih satu alfabet dan dokumentasikan yang mana. Kesalahan umum adalah pengkodean persen Base64 standar alih-alih menggunakan base64url. Implementasinya juga menjelaskan batasan pasal. Ini menormalkan tanda hubung dan garis bawah sebelum mendekode, tetapi tidak memverifikasi tanda tangan token atau menafsirkan klaim. Mengonversi segmen JWT menjadi byte dapat mengungkap JSON; tidak dapat ditentukan siapa yang menerbitkan JSON tersebut atau apakah ada yang mengubahnya.
Apa yang tidak tercakup dalam hal ini — memverifikasi tanda tangan JWT, base32 dan pengkodean RFC 4648 lainnya
%2B adalah kode persen untuk +; %2F adalah kode persen untuk /. Pengkodean persen mengubah TWFu menjadi TWFu tidak berubah (tidak ada karakter khusus) tetapi TE9S+g== menjadi TE9S%2Bg%3D%3D (terlalu banyak karakter untuk ditangani). Solusi yang benar adalah dengan menggunakan base64url, yang sudah menghasilkan keluaran aman URL. Pengkodean persen Base64 tidak berguna dan boros. Gunakan alfabet yang tepat untuk konteksnya. Encoder & decoder Base64 menerima kedua alfabet secara otomatis.
Jika Anda menempelkan string yang mengandung -, itu akan memperlakukannya sebagai base64url; jika menempelkan string yang mengandung +, itu akan memperlakukannya sebagai Base64 standar. Alat juga menerima URL dan memperlakukannya sebagai masukan yang URL. Oleh karena itu, pemeriksaan praktis memiliki dua hasil independen: perjalanan bolak-balik byte, dan representasi yang dipilih sesuai dengan salurannya. Melewati yang pertama berarti transformasi itu dapat dibalik. Melewati detik berarti tanda baca dan padding tidak akan ditulis ulang oleh URL, nama file, cookie, atau protokol yang membawanya.
Kesimpulan: dua alfabet, satu tata letak bit — bagaimana encoder & decoder Base64 menangani alfabet standar di browser, dan di mana halaman alatnya menyatakan apa yang diterimanya
Saat mendekode segmen JWT atau token aman URL, Anda dapat menempelkannya secara langsung tanpa konversi, dan alat mengidentifikasi alfabet dari konteks. Men-debug dekode yang gagal menjadi sederhana: tempelkan token, lihat apakah alat menerimanya, dan jika tidak, tukar karakter secara manual dan coba lagi.
Substitusinya sendiri berupa satu baris kode, namun dekode yang gagal juga bisa disebabkan oleh panjangnya yang tidak tepat, padding yang salah tempat, kerusakan, atau input non-Base64. Alat ini menormalkan kedua alfabet secara otomatis, sehingga penerimaan hanya mengonfirmasi bahwa byte dapat dipulihkan. Payload JWT yang didekodekan masih merupakan klaim yang belum ditandatangani sampai pemverifikasi terpisah memeriksa tanda tangannya dan algoritme yang diharapkan.