Base64 standar (RFC 4648)
Varian standar memakai alfabet A–Z, a–z, 0–9, plus karakter + dan /, dengan = sebagai padding. Inilah varian yang dipakai di sebagian besar dokumentasi dan contoh di internet.
Gunakan varian ini sebagai pilihan default kecuali ada alasan khusus. Semua decoder umum memahaminya, dan alat Base64 CubTools bekerja dengan varian ini.
Standar ini juga dipakai di sebagian besar tutorial dan dokumentasi, sehingga contoh dari internet bisa langsung dicoba tanpa konversi. Konsistensi inilah alasan ia menjadi pilihan default yang aman.
Base64 URL-safe
Karakter + dan / punya arti khusus di URL sehingga diganti menjadi - dan _ pada varian URL-safe. Padding = pun sering dihilangkan karena juga bermasalah di URL.
Varian ini wajib dipakai untuk token yang ditaruh di URL, seperti pada JWT atau tautan verifikasi. Mencoba decode string URL-safe dengan decoder standar hampir pasti gagal.
Perhatikan bahwa menghilangkan padding pada URL-safe bersifat opsional. Jika decoder Anda rewel, coba tambahkan kembali tanda sama dengan hingga panjang string kelipatan 4 - sering kali itu solusinya.
Base64 MIME untuk email
Standar email (MIME) membatasi panjang baris, sehingga string Base64 dipotong tiap 76 karakter dengan jeda baris. Inilah alasan lampiran email yang disalin mentah sering gagal di-decode.
Jika Anda berhadapan dengan Base64 dari email, hapus dulu semua jeda barisnya hingga menjadi satu baris utuh sebelum di-decode.
Beberapa sistem modern sudah meninggalkan pembatasan 76 karakter, tetapi format MIME tetap dipakai luas karena kompatibilitas mundur. Selama email masih menjadi jalur transfer data, varian ini tetap relevan untuk dipahami.
Cara mengenali varian dari tampilannya
Lihat karakternya: ada + atau / berarti standar; ada - atau _ berarti URL-safe; ada jeda baris tiap baris pendek berarti MIME. Padding = di akhir menandakan varian standar atau MIME.
Setelah mengenali variannya, sesuaikan cara memprosesnya. Kebanyakan error “string tidak valid” selesai begitu variannya ditangani dengan benar.
Panjang string juga bisa menjadi petunjuk: hasil encode selalu sekitar empat per tiga panjang data asli. Jika string jauh lebih pendek dari perkiraan, kemungkinan ada bagian yang terpotong.
Memilih varian untuk proyek Anda
Aturan praktisnya sederhana: default selalu varian standar. Hanya pindah ke URL-safe bila data benar-benar akan lewat URL, dan hanya berurusan dengan MIME bila sumbernya email atau sistem lama.
Dokumentasikan pilihan varian di proyek Anda, terutama bila bekerja tim. Satu baris di README - kami memakai Base64 URL-safe tanpa padding - mencegah perdebatan dan bug yang muncul berbulan kemudian.
Jika Anda menerima data dari pihak ketiga tanpa dokumentasi, identifikasi variannya dari ciri visual sebelum memproses. Lima detik identifikasi menghemat tiga puluh menit debugging yang sia-sia.
Pertanyaan umum
Varian mana yang dipakai alat CubTools?
Varian standar RFC 4648. Untuk string URL-safe, ganti dulu - menjadi + dan _ menjadi / sebelum di-decode.
Bisakah varian dikonversi satu sama lain?
Bisa dan mudah: URL-safe ke standar cukup mengganti dua karakter. MIME ke standar cukup menghapus jeda baris. Isi datanya tidak berubah.
Mengapa JWT memakai URL-safe?
Karena token JWT ditaruh di URL dan header HTTP. Karakter + dan / pada varian standar akan diinterpretasi browser sebagai spasi atau pemisah path.
Apakah padding selalu wajib?
Pada varian standar, ya. Pada URL-safe, padding sering dihilangkan dan decoder yang baik bisa menanganinya. Bila ragu, biarkan padding apa adanya.