Alat pengembang · Encoder & decoder Base64
Base64 vs hex vs base32: membandingkan tiga cara menulis byte sebagai teks
· Latar belakang
base64 pengkodean
Hex, base32, dan Base64 memecahkan masalah yang sama dengan perbedaan ukuran, keterbacaan, dan keamanan. Postingan ini membandingkannya dalam hal kepadatan, sensitivitas huruf, keamanan URL, dan kesalahan manusia.
Kunci API yang salah ketik karena l, 1, I dan O — kegagalan keterbacaan nyata yang tidak akan terjadi pada hex
Tiga cara umum untuk merepresentasikan byte sebagai teks adalah hex, base32, dan base64. Semuanya memecahkan masalah yang sama (mengekspresikan byte arbitrer dalam ASCII yang dapat dicetak) tetapi dengan trade-off yang berbeda dalam ukuran, keterbacaan, dan ketahanan kesalahan. Hex adalah 2 karakter per byte (F3 A2 B1 ...), jadi 16 bytes menjadi 32 karakter. Base32 adalah 1.6 karakter per byte (kira-kira 5 karakter per 3 bytes), jadi 16 bytes menjadi 26 karakter.
Base64 berisi 1.33 karakter per byte (tepatnya 4 karakter per 3 bytes), jadi 16 bytes menjadi 24 karakter atau kurang. Jika ukuran file penting, base64 adalah yang paling ringkas. Jika transkripsi manusia penting, hex dan base32 lebih aman. Perbedaan keterbacaan sangat penting ketika suatu nilai diketik, disalin, atau diucapkan. Hex menggunakan 0-9 dan a-f (tidak peka huruf besar-kecil di sebagian besar konteks). Saluran transkripsi mengubah keputusan karena representasi yang dioptimalkan untuk mesin dapat menyulitkan manusia. Base64 peka huruf besar-kecil dan menggunakan dua simbol tanda baca; hex menggunakan kosakata visual yang lebih kecil. Implementasinya di sini menguji string yang tepat, bukan tingkat kesalahan manusia, sehingga tidak ada probabilitas yang ditemukan.
Kepadatan: 2×, 1.6× dan 1.33× — berapa banyak karakter yang dibutuhkan setiap pengkodean per byte dan alasannya
Base32 menggunakan A-Z dan 2-7, menghindari 0, 1, O dan I yang mudah tertukar di atas kertas. Base64 menggunakan A-Z, a-z, 0-9, + dan /, termasuk huruf besar dan kecil, menjadikannya peka huruf besar-kecil dan mencampurkan angka yang terlihat serupa (0 versus O, 1 versus I versus huruf kecil l). Kunci API dalam hex mungkin f3a2b1e4; byte yang sama di base64 mungkin 86KrvE== (dengan padding), atau di base32 6VEV7FI= (dengan padding).
Jika pengguna harus mengetikkan nilainya dengan tangan, hex atau base32 lebih aman daripada base64. Karakter yang dicadangkan dalam URL penting. Hex dan base32 aman untuk URL; keduanya hanya menggunakan karakter alfanumerik (hex juga menggunakan 0-9, base32 juga menggunakan 2-7). Base64 menggunakan plus dan garis miring yang dicadangkan URL (plus mewakili spasi dalam data yang disandikan formulir, garis miring adalah pemisah jalur). Kepadatan Base64 mengikuti langsung dari enam bit berguna per simbol keluaran dan padding ke blok empat karakter. Hex membawa empat bit per simbol, menghasilkan dua karakter per byte. Base32 dibahas sebagai konteks perbandingan hanya karena repositori ini tidak menyediakan alfabet atau encoder untuk memverifikasi keluaran.
Kepadatan dari lebar bit — aritmatika Base64 dan hex yang tepat, dengan Base32 diperlakukan sebagai konteks perbandingan
String base64 dalam parameter URL harus dikodekan persen (ditambah menjadi %2B, garis miring menjadi %2F), menambahkan 4 karakter tambahan untuk setiap kemunculan. Base64url (RFC 4648 bagian 5) menggantikan tanda plus dengan tanda hubung dan garis miring dengan garis bawah, menjadikannya URL-aman tanpa pengkodean persen. Kebanyakan API yang menggunakan base64 di URL sebenarnya menggunakan base64url, namun perbedaannya sering kali tidak eksplisit dalam dokumentasi.
Rahasia TOTP (kode yang digunakan oleh aplikasi pengautentikasi) biasanya didistribusikan sebagai base32. Layar pendaftaran TOTP menampilkan rahasia base32 karena lebih mudah untuk mengetik dan menyalin daripada byte yang sama di base64 atau hex. SHA intisari hash sering ditampilkan dalam hex karena ini adalah format tradisional dan karena hex tidak membedakan huruf besar/kecil, sehingga mengurangi kemungkinan terjadinya kesalahan ketik. Sensitivitas huruf besar-kecil penting ketika seseorang membacakan nilai dengan keras atau mengetik ulang, karena mengubah huruf besar-kecil akan mengubah indeksnya. ToolAcre mempertahankan huruf besar-kecil dengan tepat dan akan memecahkan kode byte berbeda yang dihasilkan tanpa mengetahui ada kesalahan transkripsi yang dilakukan manusia. Representasinya sendiri tidak memiliki checksum.
Karakter yang dicadangkan dan keamanan URL — di mana + dan / menggigit, dan bagaimana base32 dan hex menghindari masalah
JWT menggunakan base64url. Checksum file mungkin hex atau base64; keduanya umum. Pilihannya adalah konvensi sejarah, bukan kebutuhan teknis. Ketahanan terhadap kesalahan adalah perbedaan yang halus namun penting. Base32 menghindari digit 0, 1, 8, dan 9 (yang terlihat seperti huruf), sehingga mengurangi kesalahan transkripsi. Base64 mencakup semua digit, membuat 1 menjadi ambigu (apakah huruf I, huruf kecil l, atau digit 1?).
Hex bahkan lebih rawan kesalahan: 0 terlihat seperti O, aku terlihat seperti 1. Checksum yang harus diketik atau dibaca dari hasil cetakan lebih aman di base32. Kunci API yang ditempel langsung dari komputer aman dalam format apa pun; keterbacaan hanya penting jika mata manusia terlibat. Bytenya sama, tetapi pengkodeannya berbeda: urutan byte 16 [0xf3, 0xa2, 0xb1, ...] menjadi f3a2b1... Plus dan garis miring Base64 standar memerlukan penanganan yang sadar saluran; URL-mode aman menggantikannya dengan tanda hubung dan garis bawah. Hex menghindari pemisah tersebut hanya dengan menggunakan angka dan huruf. Konvensi Base32 bervariasi, jadi artikel ini menghindari properti keamanan yang menjanjikan yang tidak diterapkan atau diuji oleh repositori.
Contoh praktis: 16 bytes yang sama di ketiga pengkodean — perbandingan panjang dan inspeksi visual
dalam hex, 6VEV7FI=... di base32, dan 86KrvE== di base64. Tak satu pun dari string ini yang dapat dipertukarkan. Aplikasi yang menerima f3a2b1... mengharapkan hex dan akan mencoba menguraikannya sebagai hex. Menerima 86KrvE== akan gagal jika aplikasi mengharapkan hex. Format pengkodean adalah bagian dari kontrak data: pengirim dan penerima harus menyetujui pengkodean mana yang digunakan. Padding adalah perbedaan lainnya.
Hex tidak menggunakan padding (4 bytes selalu 8 karakter hex, tidak ada pengecualian). Base32 dan base64 keduanya menggunakan padding yang sama untuk menyelaraskan output ke beberapa karakter (8 untuk base32, 4 untuk base64). Padding diperlukan secara matematis; ini memastikan bahwa setiap masukan n-byte menghasilkan jumlah karakter deterministik. Aturan padding bervariasi: beberapa aplikasi memerlukan padding, yang lain mengizinkannya untuk dihilangkan. Perbandingan yang berhasil menggunakan urutan byte tetap dan menghitung Base64 dan hex secara mekanis. Panjang Base32-nya dapat didiskusikan dari pengelompokan lima bit, namun nilai teks Base32 yang tepat dihilangkan karena tidak ada implementasi yang ditinjau yang menghasilkannya. Aritmatika panjang dan verifikasi keluaran dibuat berbeda.
Dimana masing-masing bersifat konvensional — hash dalam hex, rahasia TOTP di base32, JWT dan data: URI di Base64
Saat menempelkan nilai base32 atau base64 tanpa padding, decoder dapat menerima atau menolaknya bergantung pada implementasi. Kunci dan token kriptografi menunjukkan perbedaan pengkodean.
Kunci HMAC adalah 32 bytes, yang menjadi 64 karakter hex, 52 karakter base32 (dengan padding), atau 44 karakter base64 (dengan padding). Saat mendistribusikan kunci, pengkodeannya harus didokumentasikan. Jika dokumentasi menyatakan kuncinya adalah 44 karakter base64 tetapi Anda menerima 52 karakter, ada sesuatu yang salah. Konvensi dapat memandu pembaca tetapi tidak membuktikan kesesuaiannya. Intisari hash biasanya ditampilkan sebagai hex, sedangkan segmen JWT menggunakan Base64url. Pilihan yang tepat masih bergantung pada aturan saluran, apakah orang menyalin nilainya, dan apakah protokol lain telah memperbaiki representasinya.
Apa yang tidak tercakup di sini - pengkodean base58, base85 dan checksum
Pengkodean base64 yang lebih pendek membuatnya lebih mudah untuk memasukkan token ke dalam sistem dengan batas karakter (seperti kode QR atau URL). Pilihan pengkodean suatu nilai ditentukan oleh ekosistem apa pun asalnya. API Web sering kali menggunakan base64url. Dokumentasi kriptografi sering kali menggunakan hex. Aplikasi autentikator menggunakan base32. Saat membangun sebuah sistem, pilih satu pengkodean, dokumentasikan dengan jelas, dan pertahankan.
Mencampur pengkodean (mengatakan base64 atau base32) menimbulkan kebingungan. Saat melakukan debug, langkah pertama adalah mengidentifikasi pengkodean mana yang digunakan nilai tersebut; alat encoder & decoder Base64 dapat membantu dengan mencoba memecahkan kodenya dengan berbagai cara dan melihat mana yang menghasilkan keluaran yang masuk akal. Tidak ada pengkodean yang lebih baik secara universal. Base64 paling ringkas untuk penyimpanan mentah. Hex paling familiar bagi kriptografer dan paling mudah dibaca manusia untuk jaringan kecil. Pengkodean Base58, Base85, dan checksum membuat trade-off yang berbeda dan tidak ada di panel Base64 ToolAcre. Alfabet, aturan ambiguitas, dan checksumnya harus dievaluasi dengan sumber dan implementasi khusus, bukan diekstrapolasi dari perilaku yang diuji pada alat ini.
Kesimpulan: pilih pengkodean untuk saluran dan pembaca — bagaimana encoder & decoder Base64 mencakup case Base64 di browser, di samping kalkulator hash SHA di produk yang sama
Base32 paling tahan terhadap kesalahan transkripsi. Pilihannya bergantung pada konteks: di mana nilai tersebut berada, bagaimana nilai tersebut dibagikan, dan sistem apa yang akan menggunakannya.
Memahami trade-off membantu Anda memilih dengan bijak saat merancang API atau sebuah sistem. Alat encoder & decoder Base64 mendemonstrasikan pengkodean base64; menggunakannya bersama alat hex atau base32 memungkinkan Anda melihat byte yang sama dalam ketiga format dan memahami perbedaan ukuran dan keterbacaannya. Untuk kasus Base64, kodekan sampel, catat jumlah persis UTF-8-byte dan karakter keluaran, dan uji tanda baca standar versus URL-aman. Untuk pekerjaan intisari, gunakan panel SHA terpisah. Menjaga agar operasi tersebut tetap berbeda akan mencegah pilihan pengkodean disalahartikan sebagai hashing atau perlindungan integritas.