Alat pengembang · Encoder & decoder Base64
RFC 4648 menjelaskan: standar yang mendefinisikan Base64, base32 dan base16
· Latar belakang
base64 pengkodean
RFC 4648 adalah dokumen singkat dan mudah dibaca di balik setiap implementasi Base64. Postingan ini membahas apa yang ditentukan, apa yang sengaja dibiarkan terbuka, dan mengapa penerapannya masih berbeda.
Dua perpustakaan, dua jawaban untuk string yang sama — sebuah teka-teki interoperabilitas nyata yang hanya diselesaikan oleh standar
Dua perpustakaan JavaScript dapat mengembalikan Base64 yang berbeda untuk string yang sama, masing-masing mengklaim kebenarannya. RFC 4648 adalah dokumen setebal dua belas halaman yang dapat dibaca yang seharusnya menyelesaikan perselisihan tersebut, namun penerapannya masih berbeda karena RFC dengan sengaja menyerahkan keputusan tertentu pada permohonan. Artikel ini membahas apa yang RFC 4648 tentukan, apa yang sengaja didelegasikan kepada penelepon, dan mengapa membaca standar sekali memecahkan sebagian besar teka-teki interoperabilitas yang sebenarnya. Alat encoder & decoder Base64 menyertakan RFC 4648 vektor pengujian sehingga Anda dapat memverifikasi implementasi terhadap contoh resmi.
RFC 4648 mengganti dan menggabungkan beberapa dokumen sebelumnya: Base64 dari MIME (RFC 2045), Base64 dari Privacy-Enhanced Mail (RFC 1421), base32 dari S/MIME (RFC 2630) dan base16 dari berbagai sumber. Konsolidasi diperlukan karena MIME dan PEM masing-masing memiliki alfabet dan aturannya sendiri, dan pembungkusan baris MIME bertentangan dengan blok kolom 64 PEM. RFC 4648 mendefinisikan lima keluarga pengkodean di satu tempat: base64, base64url, base32, base32hex dan base16, masing-masing dengan alfabet, aturan padding, dan contoh vektor pengujiannya sendiri. Alfabet base64 adalah A-Z, a-z, 0-9, plus dan garis miring, dalam urutan itu.
Apa yang ditetapkan oleh implementasi dan pengujian vektor — alfabet, padding, dan penanganan spasi standar dan URL-aman
Setiap karakter mewakili 6 bits; tiga byte masukan (24 bits) dipetakan ke empat karakter keluaran. Alfabetnya tidak sembarangan: menghindari karakter yang berbeda antara EBCDIC dan ASCII, menghindari karakter kontrol, tanda kutip, dan garis miring terbalik yang perlu di-escape dalam literal string C. Varian base64url menggantikan plus dengan tanda hubung dan garis miring dengan garis bawah untuk menghindari karakter khusus dalam URL dan nama file. Kedua varian tersebut sama-sama valid; RFC 4648 bagian 2 menentukan base64, bagian 5 menentukan base64url, dan aplikasi harus menyatakan mana yang digunakannya.
Padding dengan karakter yang sama membawa output ke kelipatan empat karakter. Jika masukannya adalah 1 byte (8 bits), keluarannya berupa dua karakter ditambah dua tanda sama dengan. Jika masukannya adalah 2 bytes (16 bits), keluarannya berupa tiga karakter ditambah satu tanda sama dengan. Jika inputnya merupakan kelipatan 3 bytes, tidak diperlukan padding. Beberapa aplikasi menghilangkan padding atau membiarkan padding hilang saat decode; RFC 4648 bagian 3.2 mendefinisikan pengkodean kanonik sebagai selalu diisi, namun bagian 3.3 mencatat bahwa dekoder mungkin menerima bantalan yang hilang untuk kompatibilitas.
Alfabet yang diterapkan alat ini — standar Base64 dan Base64url; pangkalan lain tetap berada di luar cakupannya
Perbedaan padding adalah alasan mengapa implementasi tidak setuju: decoder yang ketat menolak persamaan yang hilang, sementara decoder yang lunak menerimanya. RFC 4648 secara eksplisit mengatakan: karakter pad sama dengan biasanya dikodekan dalam persen ketika digunakan dalam URL, jadi jika output base64url digunakan secara langsung dalam parameter URL, padding tidak diperlukan dan harus dihilangkan. Kalimat ini adalah salah satu alasan URL-safe mode dan penghilangan padding sering dipasangkan, meskipun keduanya merupakan pilihan independen. Bagian 5 (base64url) tidak melarang padding; itu hanya mencatat praktik umum.
Penelepon yang memilih base64url harus memutuskan apakah padding diperlukan untuk sistem penerima. Karakter non-abjad dalam masukan ditangani secara berbeda oleh decoder yang berbeda. RFC 4648 bagian 3.1 menyatakan: Penerapan MUST menolak pengkodean jika berisi karakter di luar alfabet dasar. Namun, bagian 3.3 mencatat bahwa MIME Base64 (RFC 2045) mengizinkan jeda baris untuk pembungkusan karakter 76, dan dekoder untuk MIME harus melewati spasi. RFC membedakan antara decoding ketat (tolak semua non-abjad) dan decoding yang kompatibel dengan MIME (lewati spasi, tolak karakter lain).
Padding, karakter non-abjad, dan pengkodean kanonik — bagian yang menjelaskan sebagian besar ketidaksepakatan dekoder
Permohonan harus memilih aturan mana yang harus diikuti; standar mendefinisikan keduanya. Base32 menggunakan A-Z dan 2-7 (total 32 karakter), menyandikan lima byte masukan (40 bits) menjadi delapan karakter keluaran. Base32hex menggantikan 0-9 dan a-v untuk karakter alfabet, berguna dalam konteks di mana huruf kecil lebih disukai.
Base16 adalah heksadesimal: 0-9 dan a-f. Base32 dan base32hex memiliki aturan paddingnya sendiri di bagian 6 dan 7, dan RFC menyediakan vektor pengujian terpisah untuk setiap alfabet. Kebanyakan pengembang hanya memerlukan base64 dan base64url; base32, base32hex dan base16 disertakan dalam RFC untuk kelengkapan dan untuk aplikasi seperti TOTP rahasia (RFC 4226) dan pengkodean DNS.
Pilihan aplikasi terlihat dalam implementasi ini — pembungkusan baris, decoding teks yang ketat, dan penanganan kesalahan
Vektor uji di RFC 4648 adalah kebenaran dasar untuk memeriksa implementasi. Pengkodean string f, fo, foo, foob, fooba dan foobar menghasilkan output base64 spesifik: Zg==, Zm8=, Zm9v, Zm9vYg==, Zm9vYmE= dan Zm9vYmFy. Implementasi yang menghasilkan keluaran berbeda untuk string ini salah. RFC menyediakan vektor uji yang setara untuk base32, base32hex, dan base16. Alat encoder & decoder Base64 menyertakan vektor-vektor ini sehingga Anda dapat memverifikasi outputnya terhadap standar. Pembungkusan garis adalah masalah MIME, bukan masalah base64.
RFC 2045 menentukan 76 baris karakter; RFC 4648 bagian 3.1 mencatat ini dalam konteks MIME tetapi tidak menjadikannya persyaratan base64 itu sendiri. Beberapa aplikasi membungkus 64 karakter (standar PEM asli); yang lain tidak membungkus sama sekali. Decoder base64 RFC 4648 yang ketat hanya beroperasi pada alfabet dan padding. Dekoder yang kompatibel dengan MIME harus melewati jeda baris (CR, LF, CRLF). Aplikasi yang menggunakan base64 di luar MIME tidak boleh menambahkan jeda baris kecuali sistem penerima memerlukannya; RFC tidak mendefinisikan pembungkusan garis sebagai bagian dari base64.
Contoh praktis: vektor pengujian RFC sendiri — mengkodekan awalan 'foobar' dan memeriksanya di browser
Penanganan spasi adalah poin lain dari varian implementasi. RFC 4648 mengatakan decoder yang ketat harus menolak karakter non-abjad. MIME base64 yang dibungkus (RFC 2045 base64) memungkinkan spasi untuk pemformatan. Kedua standar tersebut sepakat tentang berapa byte keluaran yang seharusnya, tetapi berbeda dalam hal masukan apa yang valid. Kebanyakan implementasi JavaScript memilih kompatibilitas MIME dan melewatkan spasi; aturan ketat jarang digunakan di browser. Encoder & decoder Base64 menerima input yang berisi spasi (MIME) dan ketat, sehingga membuat perbedaannya menjadi eksplisit. Penguraian kode kanonik vs. pemaaf adalah varian besar terakhir.
Dekode kanonik mengikuti RFC 4648 bagian 3.2: menolak format padding yang salah, menolak padding yang hilang, menolak karakter non-abjad. Decoding yang memaafkan, digunakan dalam standar web (spesifikasi HTML menyebutnya forgiving-base64), menambahkan aturan: abaikan spasi, terima padding yang hilang, izinkan tanda hubung dan garis bawah sebagai garis miring plus yang setara bahkan dalam mode base64 standar. atob() JavaScript memaafkan; dekoder RFC 4648 yang ketat lebih ketat. Tidak ada yang salah; mereka melayani konteks yang berbeda. Aplikasi yang membaca data dari pengguna atau dari jaringan harus mengetahui aturan mana yang diharapkan pihak lain.
Apa yang tidak tercakup dalam hal ini — dokumen MIME dan PEM itu sendiri, dan API khusus bahasa
RFC memberikan sembilan pilihan pada aplikasi: yang mana dari lima alfabet, apakah memerlukan atau mengizinkan padding, apakah memerlukan atau mengizinkan spasi putih, apakah akan memperlakukan garis bawah tanda hubung sebagai persamaan plus garis miring, cara melaporkan kesalahan, cara menangani akhir input, apakah menerima padding yang hilang, berapa banyak byte output yang akan dialokasikan, dan cara memberi sinyal batas ukuran. Pilihan ini menjelaskan mengapa dua implementasi RFC 4648 bisa berbeda pendapat pada masukan yang sama. Baca RFC sekali; periksa implementasi Anda terhadap vektor pengujiannya; nyatakan opsi mana yang digunakan aplikasi Anda; uji interoperabilitas dengan rekan sebenarnya, bukan asumsi.
Pemahaman RFC 4648 menyelesaikan sebagian besar perselisihan Base64 karena perselisihan tersebut biasanya bukan mengenai RFC itu sendiri tetapi tentang opsi mana yang dipilih masing-masing pihak. RFC cukup singkat untuk dibaca menyeluruh dalam satu jam. Standar ini mendefinisikan alfabet, menyediakan vektor pengujian, dan memperingatkan di mana implementasi harus diputuskan. Alat encoder & decoder Base64 memungkinkan Anda bereksperimen dengan vektor pengujian dan melihat alfabet standar beraksi. Sebagian besar penggunaan base64 sehari-hari tidak memerlukan pengetahuan RFC yang mendalam; tetapi ketika men-debug ketidakcocokan pengkodean atau integrasi dengan API yang tidak dikenal, membaca standar sekali menghilangkan dugaan.
Kesimpulan: baca standarnya sekali — bagaimana encoder & decoder Base64 memberi Anda cara cepat untuk memeriksa vektor pengujian alfabet standar
RFC 4648 adalah konsolidasi praktik pengkodean dasar ad-hoc selama beberapa dekade ke dalam satu spesifikasi yang dapat dibaca. Itu tidak menentukan kapan harus menggunakan base64 (MIME, PEM, JWT, URI data, dll. masing-masing memiliki spesifikasinya sendiri); itu mendefinisikan apa itu base64. Dengan mendefinisikan lima kelompok pengkodean dan mencatat opsi mana yang kanonik, RFC memungkinkan untuk memeriksa apakah suatu implementasi sudah benar. Vektor uji otoritatif adalah titik awalnya: jika implementasi Anda mengkodekan foobar dan menghasilkan apa pun selain Zm9vYmFy, RFC mengatakan bahwa implementasinya salah.
Gunakan otoritas tersebut sebagai pos pemeriksaan verifikasi: enkode setiap vektor pengujian RFC, bandingkan karakter persisnya, lalu dekode hasilnya untuk mengonfirmasi bahwa byte asli tidak berubah. Pemeriksaan berbasis browser ini memisahkan kesalahan alfabet atau padding dari masalah di tempat lain dalam integrasi, sekaligus menjaga standar itu sendiri sebagai referensi daripada mengandalkan label perpustakaan.