Apa itu Base64?
Base64 menulis ulang byte menggunakan enam puluh empat karakter yang dapat dibaca, sehingga data tetap utuh di saluran yang dibuat untuk teks: badan email, string JSON, atribut XML, atau URL. Setiap tiga byte menjadi empat karakter, dari situlah namanya — alfabetnya memiliki enam puluh empat simbol dan setiap simbol membawa tepat enam bit.
Ini adalah encoding transport, bukan langkah keamanan dan bukan kompresi. Output-nya kira-kira sepertiga lebih besar daripada input, dan siapa pun yang memiliki string itu dapat langsung membalikkannya. Jika ingin mengetahui apakah data pernah diubah, gunakan hash (Hash Generator); jika ingin menjaganya tetap rahasia, gunakan enkripsi. Base64 tidak melakukan keduanya.
Satu angka yang perlu diingat: tiga byte input menjadi empat karakter output. Semua yang lain di halaman ini mengikuti dari situ. Empat karakter membawa dua puluh empat bit, dan dua puluh empat bit tepat tiga byte, sehingga tidak ada data yang hilang atau dibuat-buat — kecuali di ujung, saat input mungkin tidak memenuhi grup ketiga terakhir.
Lima alfabet yang dapat digunakan halaman ini
Dua baris pertama adalah standar dan tiga baris terakhir adalah konvensi yang tumbuh di sekitar Unix. Kelimanya membawa enam bit yang sama per karakter dan hanya berbeda pada enam puluh empat karakter yang dipakai, sehingga byte yang sama menjadi lima string yang berbeda. Tidak ada yang di dalam string menunjukkan alfabet mana yang menghasilkannya, itulah sebabnya pemilih alfabet default ke standar dan kotak centang aman-URL menjadi jalan pintas ke baris kedua.
Cara halaman memilih kandidat: pemilih adalah default untuk kedua arah. Saat mendekode, panel di sebelah kanan juga membaca string itu sendiri — - dan _ hanya berasal dari alfabet aman-URL, + atau / hanya berasal dari alfabet standar, dan / atau . di dekat awal menunjuk ke dua alfabet Unix. Setiap alfabet yang dapat membaca input saat ini ditampilkan di sana, beserta alasan mengapa ia kandidat atau bukan.
Pemotongan baris: 76 dan 64 karakter
MIME menginginkan Base64 yang muat dalam email tanpa ada baris yang terlalu panjang, dan menetapkan 76 karakter per baris yang dipisahkan CRLF. File PEM, yang membungkus sertifikat dan kunci, memakai 64. Pemutusan baris bukan bagian dari data: decoder menghapusnya dan menyambung kembali baris-barisnya sebelum melakukan hal lain, sehingga string yang dipotong dan yang tidak dipotong didekode menjadi byte yang persis sama. Setiap baris kecuali yang terakhir berisi jumlah grup empat karakter yang utuh, dan itulah yang membuat penyambungan kembali aman.
Halaman ini membiarkan output dalam satu baris kecuali lebar dipilih, dan decoder menerima input dengan atau tanpa pemutusan baris. Pemutusan yang ditulis halaman ini adalah line feed biasa, yang dapat ditampung kotak teks; badan email MIME secara tradisional memakai carriage return sebelum setiap line feed, dan setiap decoder yang digunakan menerima keduanya.
Padding, dan mengapa boleh dihapus
Jika input bukan kelipatan tiga byte, grup empat karakter terakhir tidak lengkap, dan satu atau dua karakter = melengkapinya. Padding itu tidak membawa data sama sekali: hanya menunjukkan berapa dari empat karakter yang nyata. Decoder dapat menghitungnya dari panjang, sehingga Base64 aman-URL secara tradisional membiarkan padding dihapus — = merepotkan di URL atau nama file, dan beberapa sistem men-persen-encode-nya.
Kotak centang di baris opsi mempertahankan padding ketika alfabet aman-URL dipilih. Tidak ada yang lain berubah; karakter yang membawa data identik dalam kedua kasus.
Kesalahpahaman umum
- "Base64 menyembunyikan data." Tidak. Ini adalah substitusi tanpa kunci, dan intinya adalah siapa pun dapat membalikkannya. Membungkus kata sandi atau token dengan Base64 tidak mengubah siapa yang dapat membacanya.
- "Base64 memampatkan." Justru sebaliknya: setiap tiga byte input menjadi empat karakter output, sehingga teksnya sepertiga lebih besar daripada data yang dibawanya.
- "Pemutusan baris adalah bagian dari nilai." Itu hanya tampilan. Menambah atau menghapusnya tidak pernah mengubah byte yang kembali.
- "Aman-URL berarti encoding yang berbeda." Itu encoding yang sama dengan dua karakter ditukar:
+ menjadi - dan / menjadi _, sehingga string dapat berada di path URL atau nilai query tanpa escaping.
- "String yang bisa didekode pasti Base64 yang valid." Setiap string karakter alfabet adalah Base64 yang valid, karena setiap kombinasi nilai enam-bit adalah urutan byte yang valid. Sebuah string baru terbukti salah pada langkah berikutnya, ketika byte-byte itu diperiksa terhadap format yang seharusnya.
- "Padding memberi tahu alfabet mana yang dipakai." Tidak, dan dalam kebanyakan kasus karakternya juga tidak: alfabet standar dan aman-URL sepakat pada enam puluh dua dari enam puluh empat simbolnya, sehingga string pendek sering terbaca sama dalam keduanya.
Pertanyaan yang sering muncul
Mengapa string Base64 kadang berakhir dengan satu = dan kadang dua? Satu berarti grup terakhir membawa tiga karakter nyata, yaitu dua byte input; dua berarti membawa dua karakter, yaitu satu byte input. Tanpa = berarti panjang input adalah kelipatan tiga.
Dapatkah Base64 merepresentasikan file biner sembarang? Ya, dan itulah kegunaan utamanya. Halaman ini memperlakukan input sebagai teks UTF-8; alat khusus File ke Base64 membaca byte mentah jika ingin mengenkode sesuatu yang bukan teks.
Alfabet mana yang harus dipakai di API? Apa pun yang didokumentasikan pihak penerima. Jika tertulis aman-URL, gunakan itu; jika tidak ada keterangan dan nilainya dibawa di dalam URL, aman-URL dengan padding dihapus adalah pilihan yang aman.
Apakah output peka huruf besar-kecil? Sepenuhnya. a dan A adalah nilai yang berbeda, itulah sebabnya Base64 jauh lebih tidak tahan terhadap karakter yang salah ketik dibandingkan Base32 atau Crockford Base32.
