Pemberi/Penerima Sandi Base64

Ubah teks apa pun ke pengkodean Base64 secara instan. Pemberi kode kami menangani karakter UTF-8, string JSON, HTML, dan masukan teks apa pun.

Salin keluaran Base64 untuk digunakan dalam:

• API
• URI data
• pengkodean email
• file konfigurasi

Dekode string Base64 apa pun kembali ke teks yang dapat dibaca. Tempel konten ber-Base64 dan lihat teks aslinya secara instan.

Menangani:

• Base64 standar
• Base64 aman untuk URL
• Base64 dengan atau tanpa karakter padding

Pengkodean Base64 bekerja dengan mengubah data biner menjadi sekumpulan 64 karakter ASCII yang dapat dicetak, seperti yang ditentukan dalam RFC 4648 dari IETF.

Algoritma ini mengambil bita masukan dan mengelompokkannya kembali dari bita 8-bit menjadi potongan 6-bit, karena 2 pangkat 6 sama persis dengan 64 nilai yang mungkin. Setiap kelompok 6-bit dipetakan ke satu karakter dalam alfabet A-Z, a-z, 0-9, plus, dan garis miring.

Karena setiap 3 bita masukan (24 bit) menjadi 4 karakter keluaran, teks terenkode kira-kira 33 persen lebih besar dari aslinya. Jika panjang masukan bukan kelipatan 3, satu atau dua tanda sama dengan akan ditambahkan sebagai padding, sesuai spesifikasi RFC 4648.

Base64 adalah pengkodean, bukan enkripsi, dan tidak memberikan keamanan atau kerahasiaan sama sekali. Siapa pun dapat mendekode string Base64 secara instan karena tidak ada kunci rahasia yang terlibat, dan pemetaan terbalik didokumentasikan secara publik di RFC 4648.

OWASP secara eksplisit memperingatkan bahwa Base64 bukanlah pengganti kriptografi dan tidak boleh digunakan untuk melindungi kata sandi, token, atau data pribadi. Satu-satunya tujuannya adalah pengangkutan data biner yang aman melalui saluran khusus teks seperti email, URL, and JSON.

Untuk kerahasiaan yang sebenarnya, gunakan enkripsi standar seperti AES-256 seperti yang direkomendasikan oleh NIST, dan untuk integritas gunakan hashing seperti SHA-256. Anggap setiap string Base64 dalam log Anda sebagai teks biasa yang dapat dibaca sepenuhnya.

Base64 yang aman untuk URL adalah varian yang ditentukan dalam Bagian 5 RFC 4648 yang mengganti karakter plus dengan tanda hubung dan karakter garis miring dengan garis bawah.

Penggantian ini penting karena plus dan garis miring memiliki arti khusus dalam URL dan jalur file, tempat karakter tersebut dapat disalahartikan atau memerlukan pengkodean persentase. Alfabet yang aman untuk URL memungkinkan nilai terenkode berjalan di dalam string kueri, segmen jalur, dan nama file tanpa kerusakan.

Tanda sama dengan padding sering kali diabaikan dalam konteks ini, karena dekoder dapat menyimpulkan panjang aslinya. JSON Web Tokens, yang dijelaskan dalam RFC 7519, mengandalkan pengkodean base64url ini untuk segmen tajuk dan muatannya, itulah sebabnya string JWT tidak pernah berisi karakter plus atau garis miring.

Base64 meningkatkan ukuran data sekitar 33 persen karena merepresentasikan setiap 3 byte input menggunakan 4 karakter output.

Tiga byte berisi 24 bit, dan Base64 membagi 24 bit tersebut menjadi empat kelompok 6-bit, sehingga rasio karakter 4-ke-3 menambahkan sepertiga pada panjangnya, seperti yang ditentukan dalam RFC 4648. Padding menambahkan hingga dua karakter lagi pada blok terakhir.

Kelebihan beban (overhead) ini adalah kompromi yang disengaja demi kompatibilitas ASCII: data biner yang seharusnya merusak email atau JSON menjadi sepenuhnya aman untuk teks. Menurut MDN Web Docs, inilah sebabnya mengapa menyematkan gambar sebagai URI data Base64 membuat berkas HTML dan CSS menjadi jauh lebih besar daripada menautkan berkas biner asli secara langsung.

Untuk mengonversi berkas atau gambar ke Base64, byte mentah dibaca dan diproses melalui algoritma standar RFC 4648, menghasilkan string teks yang dapat Anda sematkan langsung ke dalam kode.

Penggunaan yang umum adalah skema URI data yang didokumentasikan oleh MDN Web Docs, di mana sebuah gambar menjadi nilai src yang mandiri seperti data:image/png;base64 diikuti oleh byte yang telah dienkode. Ini menghilangkan permintaan HTTP terpisah, yang dapat mempercepat pemuatan ikon kecil.

Namun, karena Base64 menambah ukuran sebesar 33 persen dan tidak dapat di-cache secara terpisah, cara ini paling baik dicadangkan untuk aset yang sangat ukuran kecil. Gambar yang lebih besar, fon, dan PDF biasanya disajikan sebagai berkas biner biasa daripada disematkan sebagai Base64.

Base64 menangani Unicode dengan terlebih dahulu mengubah teks menjadi byte UTF-8, kemudian mengodekan byte tersebut dengan alfabet standar Base64. Base64 sendiri hanya beroperasi pada byte mentah, sehingga langkah pengodean karakter terjadi sebelum pengodean dan setelah dekode.

UTF-8, yang didefinisikan dalam RFC 3629 dan dikelola bersama Standar Unicode dari Konsorsium Unicode, merepresentasikan emoji, ideograf CJK, dan huruf beraksen sebagai urutan multi-byte yang kemudian dipertahankan persis oleh Base64. Proses dua langkah inilah yang membuat alat kami dengan benar memproses kembali karakter seperti simbol euro atau emoji.

Di JavaScript, MDN Web Docs mencatat bahwa fungsi lama btoa hanya menerima Latin-1, sehingga kode modern mengodekan ke byte UTF-8 dengan TextEncoder sebelum memanggil btoa.

Base64 digunakan di mana pun data biner harus dikirimkan melalui sistem yang hanya menangani teks.

• Lampiran email dienkode dalam Base64 di bawah standar MIME yang didefinisikan dalam RFC 2045, yang merupakan cara gambar dan dokumen bertahan dalam pengiriman surat teks biasa.
• Halaman web menyematkan gambar kecil dan fon sebagai URI data Base64, seperti yang didokumentasikan oleh MDN Web Docs.
• JSON Web Token per RFC 7519 mengodekan klaim mereka sebagai string base64url, dan Otentikasi Dasar HTTP, yang dijelaskan dalam RFC 7617, mengodekan Base64 pada pasangan nama pengguna dan kata sandi bertitik dua.
• Base64 juga muncul dalam payload API, sertifikat TLS dalam format PEM, dan berkas konfigurasi.

Dalam setiap kasus, tujuannya adalah pengiriman yang aman dan tanpa kehilangan (lossless) alih-alih kompresi atau keamanan.

Kesalahan Base64 yang paling umum adalah memperlakukannya sebagai tindakan pengamanan, padahal RFC 4648 mendefinisikan transformasi yang sepenuhnya dapat dibalik dan tanpa kunci yang dapat didekode oleh siapa saja.

• Kesalahan lain yang sering terjadi adalah mencampur alfabet standar dan alfabet yang aman untuk URL, yang menyebabkan kegagalan dekode saat karakter plus atau garis miring ditukar dengan tanda hubung dan garis bawah.
• Padding tanda sama dengan yang hilang atau salah juga merusak dekoder yang ketat, meskipun banyak dekoder, termasuk implementasi MDN Web Docs, menoleransi tidak adanya padding.
• Pengembang sering lupa langkah UTF-8 dan mendapatkan teks yang rusak untuk input non-ASCII.
• Terakhir, mengodekan data yang sudah berformat Base64 secara tidak sengaja akan menggandakan beban.

Memverifikasi varian yang tepat, aturan padding, dan kumpulan karakter terhadap spesifikasi RFC 4648 mencegah hampir semua kegagalan dekode ini.

Base64, Base32, dan heksadesimal semuanya adalah pengodean biner-ke-teks yang didefinisikan bersama dalam RFC 4648, tetapi ketiganya memperdagangkan kepadatan demi keterbacaan secara berbeda.

• Heksadesimal menggunakan 16 karakter dan menggandakan ukuran data, menjadikannya yang paling mudah dibaca manusia dan paling umum dalam hash dan kode warna.
• Base32 menggunakan 32 karakter yang tidak membedakan huruf besar dan kecil, memperbesar data sekitar 60 persen, dan menghindari simbol yang ambigu, yang cocok untuk sistem yang tidak sensitif huruf besar-kecil dan rahasia TOTP.
• Base64 adalah yang paling ringkas di antara ketiganya dengan overhead sekitar 33 persen, menggunakan 64 karakter.

Pilih heksadesimal untuk debugging dan pengenal pendek, Base32 saat sensitivitas huruf menjadi masalah, dan Base64 saat kekompakan paling penting, sebagaimana dijelaskan dengan jelas oleh panduan IETF dalam RFC 4648.