Pengekod/Penyahkod Base64

Tukar sebarang teks kepada pengekodan Base64 serta-merta. Alat kami mengendalikan aksara UTF-8, rentetan JSON, HTML, dan sebarang input teks.

Salin output Base64 untuk digunakan dalam:

• API
• URI data
• pengekodan e-mel
• fail konfigurasi

Nyahkod sebarang rentetan Base64 kembali kepada teks yang boleh dibaca. Tampal kandungan yang di-encode Base64 dan lihat teks asal serta-merta.

Menyokong:

• Base64 standard
• Base64 selamat untuk URL
• Base64 dengan atau tanpa aksara padding

Pengekodan Base64 berfungsi dengan menukar data binari kepada set 64 aksara ASCII boleh cetak, seperti yang ditentukan dalam RFC 4648 daripada IETF.

Algoritma ini mengambil bait input dan mengumpulkannya semula daripada bait 8-bit kepada bahagian 6-bit, memandangkan 2 kuasa 6 bersamaan tepat dengan 64 nilai yang mungkin. Setiap kumpulan 6-bit dipetakan kepada satu aksara dalam abjad A-Z, a-z, 0-9, tambah, dan garis miring.

Oleh kerana setiap 3 bait input (24 bit) menjadi 4 aksara output, teks yang di-encode adalah kira-kira 33 peratus lebih besar daripada yang asal. Apabila panjang input bukan gandaan 3, satu atau dua tanda sama dengan dilampirkan sebagai padding, mengikut spesifikasi RFC 4648.

Base64 adalah pengekodan, bukan penyulitan (encryption), dan ia menawarkan sifar keselamatan atau kerahsiaan. Sesiapa sahaja boleh menyahkod rentetan Base64 serta-merta kerana tiada kunci rahsia yang terlibat, dan pemetaan boleh balik didokumenkan secara terbuka dalam RFC 4648.

OWASP secara terang-terangan memberi amaran bahawa Base64 bukan pengganti kepada kriptografi dan tidak boleh digunakan untuk melindungi kata laluan, token, atau data peribadi. Satu-satunya tujuan adalah pengangkutan data binari yang selamat melalui saluran teks sahaja seperti e-mel, URL, dan JSON.

Untuk kerahsiaan sebenar, gunakan penyulitan bersetara seperti AES-256 seperti yang disyorkan oleh NIST, dan untuk integriti gunakan penghashan seperti SHA-256. Anggaplah sebarang rentetan Base64 dalam log anda sebagai teks biasa yang boleh dibaca sepenuhnya.

Base64 selamat untuk URL ialah varian yang ditentukan dalam Seksyen 5 RFC 4648 yang menggantikan aksara tambah dengan tanda sempang dan aksara garis miring dengan garis bawah.

Penggantian ini penting kerana tanda tambah dan garis miring mempunyai makna rizab dalam URL dan laluan fail, di mana ia boleh disalahtafsirkan atau memerlukan pengekodan peratus. Abjad selamat untuk URL membolehkan nilai yang di-encode bergerak di dalam rentetan pertanyaan, segmen laluan, dan nama fail tanpa sebarang kerosakan.

Tanda sama dengan padding sering diabaikan dalam konteks ini, kerana decoder boleh menyimpulkan panjang asal. Token Web JSON (JSON Web Tokens), yang diterangkan dalam RFC 7519, bergantung pada pengekodan base64url ini untuk segmen pengepala dan muatan (payload) mereka, itulah sebabnya rentetan JWT tidak pernah mengandungi aksara tambah atau garis miring.

Base64 meningkatkan saiz data sebanyak kira-kira 33 peratus kerana ia mewakili setiap 3 bait input menggunakan 4 aksara output.

Tiga bait mengandungi 24 bit, dan Base64 membahagikan 24 bit tersebut kepada empat kumpulan 6-bit, jadi nisbah aksara 4-kepada-3 menambah satu pertiga kepada panjangnya, seperti yang dinyatakan dalam RFC 4648. Padding menambah sehingga dua aksara lagi pada blok akhir.

Overhead ini adalah pertukaran yang disengajakan untuk keserasian ASCII: data binari yang boleh merosakkan e-mel atau JSON menjadi selamat sepenuhnya sebagai teks. Menurut MDN Web Docs, inilah sebabnya mengapa membenamkan imej sebagai URI data Base64 menjadikan fail HTML dan CSS lebih besar dengan ketara berbanding memautkan fail binari asal secara terus.

Untuk mengekod fail atau imej kepada Base64, bait mentah dibaca dan dilalui melalui algoritma standard RFC 4648, menghasilkan rentetan teks yang boleh anda benamkan secara terus dalam kod.

Kegunaan biasa ialah skema URI data yang didokumenkan oleh MDN Web Docs, di mana imej menjadi nilai src yang terkandung sendiri seperti data:image/png;base64 diikuti oleh bait yang dikodkan. Ini menghilangkan keperluan permintaan HTTP yang berasingan, yang boleh mempercepatkan pemuatan ikon kecil.

Walau bagaimanapun, kerana Base64 menambah saiz sebanyak 33 peratus dan tidak boleh di-cache secara berasingan, ia paling baik rizab untuk aset yang sangat kecil. Imej yang lebih besar, fon, dan PDF biasanya disajikan sebagai fail binari biasa berbanding Base64 terbenam.

Base64 mengendalikan Unicode dengan mula-mula menukar teks kepada bait UTF-8, kemudian mengekod bait tersebut dengan abjad standard Base64. Base64 sendiri hanya beroperasi pada bait mentah, jadi langkah pengekodan aksara berlaku sebelum pengekodan dan selepas penyahkodan.

UTF-8, yang ditentukan dalam RFC 3629 dan diselenggara bersama Piawaian Unicode daripada Konsortium Unicode, mewakili emoji, ideograf CJK, dan huruf berakcent sebagai urutan pelbagai bait yang kemudiannya dipelihara tepat oleh Base64. Proses dua langkah inilah sebabnya alat kami mengembalikan aksara dengan betul seperti tanda euro atau emoji.

Dalam JavaScript, MDN Web Docs menyatakan bahawa fungsi btoa lama hanya menerima Latin-1, jadi kod moden mengekod kepada bait UTF-8 dengan TextEncoder sebelum memanggil btoa.

Base64 digunakan di mana sahaja data binari mesti melalui sistem yang hanya mengendalikan teks.

• Lampiran e-mel dikodkan Base64 di bawah standard MIME yang ditentukan dalam RFC 2045, iaitu cara imej dan dokumen bertahan dalam pengangkutan mel teks biasa.
• Halaman web membenamkan imej kecil dan fon sebagai URI data Base64, seperti yang didokumenkan oleh MDN Web Docs.
• JSON Web Tokens mengikut RFC 7519 mengekod tuntutan mereka sebagai rentetan base64url, dan Pengesahihan Asas HTTP, yang diterangkan dalam RFC 7617, mengekod Base64 pasangan nama pengguna dan kata laluan titik bertindih.
• Base64 juga muncul dalam muatan API, sijil TLS dalam format PEM, dan fail konfigurasi.

Dalam setiap kes, matlamatnya adalah pengangkutan yang selamat dan tanpa kehilangan data berbanding mampatan atau keselamatan.

Kesilapan Base64 yang paling biasa adalah menganggapnya sebagai langkah keselamatan, sedangkan RFC 4648 menentukan transformasi yang boleh diterbalikkan sepenuhnya dan tanpa kunci yang boleh dinyahkod oleh sesiapa sahaja.

• Satu lagi ralat yang kerap berlaku ialah mencampurkan abjad standard dan selamat URL, menyebabkan kegagalan penyahkodan apabila aksara tambah atau garis miring ditukar dengan tanda sempang dan garis bawah.
• Padding tanda sama dengan yang hilang atau salah juga memecahkan penyahkod yang ketat, walaupun ramai, termasuk pelaksanaan MDN Web Docs, bertolak ansur dengan ketiadaan padding.
• Pembangun selalunya lupa langkah UTF-8 dan mendapat teks yang bercelaru untuk input bukan ASCII.
• Akhir sekali, mengekod data yang sudah ber-Base64 secara tidak sengaja menggandakan overhead.

Mengesahkan varian tepat, peraturan padding, dan set aksara terhadap spesifikasi RFC 4648 menghalang hampir semua kegagalan penyahkodan ini.

Base64, Base32, dan heksadesimal kesemuanya adalah pengekodan binari-ke-teks yang ditentukan bersama dalam RFC 4648, tetapi mereka menukar ketumpatan untuk kebolehbacaan secara berbeza.

• Heksadesimal menggunakan 16 aksara dan menggandakan saiz data, menjadikannya yang paling mudah dibaca oleh manusia dan biasa dalam cincangan (hashes) dan kod warna.
• Base32 menggunakan 32 aksara yang tidak sensitif huruf besar-kecil, mengembangkan data sebanyak kira-kira 60 peratus, dan mengelakkan simbol yang samar, yang sesuai untuk sistem yang tidak sensitif huruf besar-kecil dan rahsia TOTP.
• Base64 adalah yang paling padat daripada ketiga-tiganya pada kira-kira 33 peratus overhead, menggunakan 64 aksara.

Pilih heksadesimal untuk penyahpepijatan dan pengecam pendek, Base32 apabila sensitiviti huruf besar-kecil adalah masalah, dan Base64 apabila kekompakan paling penting, seperti yang dijelaskan oleh panduan IETF dalam RFC 4648.