Enkoder dan Dekoder Base64

Untuk apa Base64

Base64 menulis ulang byte apa pun memakai 64 karakter yang aman melewati saluran teks mana pun. Base64 mengambil tiga byte sekaligus, membagi 24 bit itu menjadi empat kelompok berisi enam bit, lalu memetakan setiap kelompok ke satu karakter dari A-Z, a-z, 0-9, dan dua simbol. Setiap tiga byte masukan menghasilkan empat karakter, jadi hasilnya sekitar 33% lebih besar dari aslinya, belum termasuk baris baru.

Tujuannya adalah pengiriman, bukan kerahasiaan. Base64 dirancang untuk saluran yang merusak byte mentah: sistem email yang membuang bit tertinggi, protokol yang menganggap karakter kontrol tertentu sebagai perintah, format yang harus berupa teks biasa. Base64 bukan enkripsi dan bukan kompresi, dan apa pun yang dikodekan bisa dibaca dengan mudah oleh siapa saja yang mau mendekodenya. Menganggap string Base64 seolah-olah terlindungi adalah salah paham, dan decoder ini membuatnya mudah dibuktikan.

Padding dan dua jenis alfabet

Jika masukan tidak habis dibagi tiga byte, output diberi padding satu atau dua karakter = agar panjangnya kelipatan empat. Sebagian encoder menghilangkan padding, dan decoder ini menambahkannya kembali alih-alih menolak masukan, karena jumlah yang benar bisa diketahui dari panjangnya.

Alfabet standar diakhiri + dan /, yang keduanya punya arti di URL dan menjadi %2B dan %2F setelah di-escape, sehingga jelek dan rawan salah di query string atau nama file. Karena itu RFC 4648 bagian 5 mendefinisikan varian aman-URL yang memakai - dan _, biasanya tanpa padding karena = juga perlu di-escape. Varian inilah yang dipakai JWT di setiap segmennya. Saat encode, keduanya tersedia di sini; saat decode, alat ini mendeteksi sendiri alfabet mana yang Anda tempel tanpa perlu disebutkan.

Unicode, dan jebakan btoa

Browser sudah punya fungsi bawaan btoa selama puluhan tahun, dan fungsi ini tidak bekerja seperti yang dikira kebanyakan orang. btoa bekerja dengan Latin-1: setiap karakter masukan harus punya code point di bawah 256, dan selain itu akan melempar InvalidCharacterError. Berikan satu karakter Jepang, nama dalam aksara Sirilik, atau emoji, dan fungsi ini langsung gagal.

Solusi yang pertama kali ditemukan orang biasanya adalah meng-escape string sebelum encoding, yang mengubah semua karakter di luar ASCII menjadi urutan byte lain sehingga hasil decode di sisi lain menjadi karakter acak. Cara yang benar, dan yang dipakai di sini, adalah mengubah teks menjadi byte UTF-8 dengan TextEncoder terlebih dahulu, lalu meng-encode byte tersebut. Itulah sebabnya aksara apa pun bisa bolak-balik melalui alat ini tanpa berubah.

Decoding melakukan kebalikannya, dan tidak menebak-nebak. Jika byte hasil decode bukan UTF-8 yang valid, Anda diberi tahu bahwa isinya data biner, bukan ditampilkan string penuh karakter pengganti. Biasanya itu berarti isinya berupa gambar, arsip, pesan protobuf, atau ciphertext, dan yang tepat adalah menyimpan byte-nya, bukan membacanya sebagai teks.

Kapan sebaiknya tidak dipakai

Base64 bukan alat untuk menyimpan rahasia, karena tidak melindungi apa pun. Base64 juga bukan pilihan bawaan yang baik untuk menyematkan aset besar: data URI untuk gambar menambah ukurannya sepertiga, tidak bisa di-cache terpisah dari dokumen yang memuatnya, dan memblokir halaman selama diurai.

Base64 berguna justru pada kasus kecil yang merepotkan: sertifikat dalam format PEM, tanda tangan digital, field biner di dalam body JSON, ikon pendek yang disematkan, atau segmen token.

Tiga byte masuk, empat karakter keluar

Encoding ini lebih mudah dipercaya setelah Anda mengerjakannya sendiri sekali. Ambil tiga huruf ASCII Man: nilai byte-nya 77, 97, dan 110, yang dalam biner adalah 01001101, 01100001, dan 01101110. Tulis 24 bit itu berderet lalu potong menjadi empat kelompok berisi enam bit, bukan tiga kelompok berisi delapan: 010011, 010110, 000101, 101110. Baca setiap kelompok sebagai angka - 19, 22, 5, 46 - lalu cari di alfabet A-Z, a-z, 0-9, +, dan /, dengan indeks 0 adalah A dan indeks 26 adalah a. Hasilnya TWFu.

Semua sifat Base64 mengalir dari perhitungan itu. Enam bit per karakter adalah alasan alfabetnya tepat berisi 64 entri. Empat karakter untuk setiap tiga byte adalah alasan outputnya sepertiga lebih besar. Dan padding ada karena kelompok terakhir bisa kurang: sisa satu byte menghasilkan dua karakter plus ==, sisa dua byte menghasilkan tiga karakter plus =.

Decoding adalah operasi yang sama dibalik, dan itulah sebabnya string Base64 yang panjangnya bukan kelipatan empat pastilah sudah diberi padding, terpotong, atau dibuat oleh encoder yang sengaja menghilangkan padding.

Di mana Anda menemuinya di sistem nyata

File PEM - sertifikat, CSR, kunci privat - adalah Base64 dengan baris header dan footer serta pergantian baris setiap 64 karakter. Panjang baris itu konvensi MIME, bukan keharusan Base64, dan decoder memang diharapkan mengabaikan pergantian barisnya.

Autentikasi HTTP Basic mengirim username:password dalam Base64 di header Authorization, dan itulah persis alasan Basic auth di atas HTTP polos setara dengan mengirim kata sandi secara terbuka. Lampiran email memakai Base64 sejak MIME didefinisikan pada 1992, dengan alasan yang sama seperti dulu: server email pada masa itu tidak bisa dipercaya membawa byte sembarang.

Data URI menyematkan seluruh file ke dalam dokumen - data:image/png;base64, diikuti isinya - dan API JSON memakai Base64 setiap kali sebuah field harus membawa byte, karena JSON tidak punya tipe biner. Segmen JWT memakai varian aman-URL tanpa padding, sementara konfigurasi Docker, secret Kubernetes, dan banyak sistem CI menyimpan kredensial dalam bentuk Base64, dan itu cara penyimpanan, bukan perlindungan.

Ukuran, memori, dan file besar

Pembengkakan 33% adalah biaya yang paling kelihatan dan biasanya yang paling kecil. Teks Base64 lebih sulit dikompresi daripada byte asalnya, karena encoding merusak pola tingkat byte yang seharusnya dimanfaatkan kompresor, sehingga payload Base64 yang di-gzip biasanya lebih besar daripada data asli yang di-gzip.

Di browser, memori adalah kendala yang lebih tajam. Meng-encode file berarti menyimpan byte dan string hasilnya sekaligus, dan string itu sepertiga lebih besar, sehingga file 100 MB bisa memerlukan beberapa ratus megabyte sebelum apa pun dikirim. API streaming - membaca file per potongan lalu meng-encode tiap potongan - menghindari hal itu, asalkan setiap potongan berukuran kelipatan tiga byte agar padding hanya muncul di paling akhir.

Untuk data yang besar, jawaban yang lebih baik biasanya adalah tidak meng-encode sama sekali: kirim file sebagai multipart form data atau sebagai body mentah, dan simpan Base64 untuk nilai-nilai kecil yang merepotkan yang memang harus melewati format teks.

Alfabet kerabatnya dan alasan keberadaannya

Base32 memakai 32 karakter dan menghasilkan output 60% lebih besar dari inputnya, yang terdengar merugikan sampai Anda memerlukan sesuatu yang bisa dibacakan atau diketik orang. Base32 tidak membedakan huruf besar-kecil, menghindari karakter yang mudah tertukar, dan dipakai oleh secret TOTP serta alamat onion.

Base58 membuang 0, O, I, l, dan dua simbol agar sebuah string bisa disalin dengan mata tanpa kebingungan; alamat Bitcoin adalah penggunaannya yang paling dikenal. Base85 atau Ascii85 memampatkan empat byte menjadi lima karakter dan lebih padat daripada Base64, dengan konsekuensi memakai tanda baca yang harus di-escape banyak format, itulah sebabnya ia terutama bertahan di dalam PDF dan PostScript.

Polanya konsisten: semuanya menukar kepadatan dengan batasan salurannya. Base64 berada di posisinya sekarang karena cukup padat untuk sepadan dengan usahanya sekaligus aman di saluran teks yang paling beragam.

Menelusuri payload yang diberikan kepada Anda

Pertanyaan pertama yang berguna tentang string yang tidak jelas adalah apakah itu memang Base64. Ada tiga tanda yang andal: panjangnya kelipatan empat atau diakhiri satu sampai dua tanda sama dengan, alfabetnya terbatas pada huruf, angka, dan dua simbol, serta hasil decode-nya berupa teks yang bisa dibaca atau header file yang dikenali, bukan data acak.

Header file itu layak dikenali juga dalam bentuk ter-encode, karena bisa mengidentifikasi isinya sebelum Anda menyimpannya. Payload hasil decode yang diawali byte 89 50 4E 47 adalah PNG; FF D8 FF adalah JPEG; 50 4B 03 04 adalah zip, termasuk semua dokumen Office; 25 50 44 46 adalah PDF. Dalam bentuk Base64, string yang diawali iVBORw0KGgo adalah PNG dan /9j/ adalah JPEG, dan keduanya terus-menerus muncul di payload API maupun data URI.

Jika hasil decode bukan teks dan bukan header yang dikenal, penjelasan yang biasa adalah stringnya berupa Base64 aman-URL tetapi didekode dengan alfabet standar, sudah di-encode dua kali, atau bukan Base64 melainkan heksadesimal atau base32. Ketiganya bisa dibedakan dalam sedetik: string aman-URL mengandung tanda minus atau garis bawah, yang ter-encode ganda akan menghasilkan string mirip Base64 lagi, dan heksadesimal hanya memakai enam belas karakter.