Alat pengembang · Encoder & decoder Base64
Padding Base64 menjelaskan: apa arti tanda = dan kapan diperlukan
· Cara kerjanya
base64 pengkodean alur kerja pengembang
Tanda = di akhir string Base64 bukanlah hiasan: ia mencatat berapa banyak byte yang pendek dari grup terakhir. Posting ini menjelaskan aritmatika, mengapa beberapa string tidak memilikinya, dan mengapa decoder tidak setuju tentang hilangnya padding.
Pengecualian 'padding salah' dari token yang tampak baik-baik saja — dekode yang gagal dan satu atau dua karakter hilang di belakangnya
Ketika decoder Base64 melaporkan padding yang salah, string terlihat lengkap tetapi membawa kesalahan struktural. Tanda sama dengan tidak bersifat kosmetik: masing-masing mengkodekan berapa byte pendek grup terakhir, memungkinkan decoder mengetahui secara pasti kapan data sebenarnya berakhir. Memahami tanda = tersebut—dan mengapa decoder yang ketat menolak string tanpa tanda tersebut—mengubah kesalahan misterius menjadi aritmatika yang dapat diprediksi. Segmen JWT mungkin memiliki satu =, tidak ada, atau dua. Respons API mungkin berakhir dengan rapi tanpa padding.
Ini mewakili pilihan yang disengaja, bukan varian implementasi. Proses decoding tidak memerlukan padding secara mekanis. Padding ada untuk membuat keluaran menjadi jelas: jika hanya diberi string Base64 tanpa metadata tentang panjangnya, dekoder membaca padding dan mengetahui secara pasti di mana data berakhir. Base64 mengkodekan grup tiga byte menjadi empat karakter. Tiga byte adalah 24 bits, dikelompokkan kembali dengan sempurna menjadi empat indeks 6-bit; masing-masing memilih salah satu dari 64 simbol Base64. Jika masukan bukan kelipatan tiga, pembuat enkode menghadapi sisa: satu atau dua byte tidak dapat dibagi tiga secara merata.
Kelompok tiga byte, blok empat karakter — mengapa panjang input modulo 3 memutuskan apakah tanda nol, satu atau dua = muncul
Encoder mengisi grup-grup tersebut dengan menggeser bit ke dalam indeks pertama, sehingga finalnya nol. Untuk menandai kesengajaan ini, ditambahkan tanda =: nol untuk grup lengkap, satu untuk final dua byte, dua untuk final satu byte. Aritmatikanya bersifat deterministik: mengetahui panjang input dalam byte memungkinkan Anda menghitung padding dengan segera. Satu byte menghasilkan dua karakter Base64 ditambah dua =. Dua byte menghasilkan tiga karakter ditambah satu =. Tiga byte menghasilkan empat tanpa padding.
Input apa pun yang bukan kelipatan tiga byte akan memiliki padding; apapun yang merupakan kelipatan tidak akan. Ini bukanlah pilihan—ini adalah aritmatika. Sebuah string tanpa padding harus mewakili tiga byte. Sebuah string dengan satu sama dengan harus mewakili dua. Padding mengkodekan panjang input modulo tiga. Periksa transformasi tiga input: single a, pair ab, triple abc. ASCII a adalah byte 0x61; Base64 mengkodekannya sebagai 0x61 00 00, dikelompokkan kembali menjadi grup enam-bit.
Apa isi bit padding dan mengapa decoder yang ketat memeriksanya — bit yang harus nol dan apa arti pengkodean kanonik
Indeks 24, 4, 0, 0 dipetakan ke Y, E, A, A. Karena dua grup merupakan padding, pembuat enkode menambahkan dua tanda =, menghasilkan YQ==. Untuk ab, byte 0x61 0x62 menjadi 0x61 0x62 00. Bits berkumpul kembali menjadi indeks 24, 22, 8, 0, output YWI=. Untuk abc, byte dikelompokkan kembali menjadi indeks 24, 22, 9, 35, keluaran YWJj tanpa padding. Padding tidak sembarangan: tidak sesuai dengan tata letak bit. Saat Anda mendekode string Base64, dekoder membaca setiap karakter, mencari indeks enam bitnya, mengemas bit menjadi byte.
Untuk YQ==, karakter Y, E, A, A dibongkar menjadi beberapa bit. Pengelompokan ulang menjadi byte delapan bit menghasilkan satu byte, 0x61. Decoder membuang bit padding (angka nol di belakangnya) dan melaporkan satu byte. Decoder yang ketat memeriksa bahwa bit padding sebenarnya nol; jika tidak, masukannya tidak kanonik, artinya seseorang menyandikan menggunakan tata letak bit yang berbeda dan dekodenya bersifat ambigu. Sistem yang menghilangkan padding sepenuhnya melakukan trade-off yang disengaja. Segmen JWT menggunakan Base64url tanpa padding, mengandalkan konsumen mengetahui panjang keluaran yang diharapkan atau menyimpulkannya.
Contoh praktis: mengkodekan 'a', 'ab' dan 'abc' dengan tangan — tiga input, tiga hasil padding, ditampilkan sedikit demi sedikit
RFC 4648 mengizinkan padding tidak ada tetapi memerintahkan decoder untuk menerimanya jika ada. Pustaka kode berbeda-beda: beberapa akan memulihkan padding yang hilang dan melanjutkan; yang lain akan gagal. Saat Anda menemukan token yang gagal didekode, menambahkan jumlah tanda = yang tepat sering kali akan memperbaikinya. Wajib = tanda selalu nol, satu atau dua, bergantung pada panjang string modulo empat. Jika panjang string Base64 bukan kelipatan empat, padding pasti hilang atau rusak.
Panjang 5 tidak dapat menjadi Base64 yang valid: setiap karakter lengkap mengkodekan enam bit, jadi empat karakter mengkodekan 24 bits (tiga byte), dan lima karakter mengkodekan 30 bits, yang bukan kelipatan delapan dan tidak dapat menjadi byte. Decoder harus menolak ini atau menambahkan padding. Jika panjangnya 2 modulo 4, tambahkan dua =. Jika 3 modulo 4, tambahkan satu =. Jika 0 modulo 4, tambahkan tidak ada. Sebuah string dengan panjang 3 tidak memiliki = yang dibutuhkannya; tambahkan satu dan itu menjadi valid sebelum decoding.
Mengapa beberapa sistem menghapus padding seluruhnya — JWT segmen dan URL token aman yang menghilangkan = dan cara memulihkannya dari panjangnya
Menggabungkan dua string Base64 berlapis rusak jika bantalan tertinggal di tempatnya. Dua pengkodean terpisah yang digabungkan secara langsung menghasilkan karakter padding liar yang merusak alfabet decoding. Inilah sebabnya mengapa beberapa sistem menghapus padding sebelum digabungkan: token yang terdiri dari tiga segmen Base64url yang digabungkan dengan titik tidak memiliki padding di dalam segmen, sehingga membuat penggabungan menjadi mudah. Jika membangun nilai Base64 dari bagian-bagian, verifikasi apakah setiap bagian diberi bantalan dan lepaskan atau tambahkan bantalan secara konsisten sebelum operasi apa pun.
Encoder & decoder Base64 menerapkan RFC 4648, yang memerlukan padding secara default. Saat Anda memasukkan teks dan meminta keluaran base64, alat tersebut menghasilkan hasil yang empuk: bentuk kanonik. Jika Anda melihat Base64 tanpa padding dan ingin mendekodekannya, periksa apakah decoder Anda menerima padding yang hilang. Alat ini menerima masukan dengan bantalan dan tanpa bantalan serta memulihkan byte asli dengan benar. Untuk debugging, menghitung panjang modulo empat memberi tahu Anda apakah padding telah dihapus, dan rumusnya memberi tahu padding apa yang harus ada.
Kesalahan umum: memangkas = seolah-olah itu adalah spasi, atau menggabungkan dua string berlapis — bagaimana masing-masing string merusak dekode
Base32 dan Base16 (heksadesimal) memiliki aturan padding berbeda yang ditentukan di RFC 4648 bagian 6 dan 7. Base32 menggunakan = tetapi grup terakhir dapat berupa 2, 4, 5, 7, atau 8 karakter bergantung pada panjang input modulo lima. Heksadesimal tidak memerlukan padding; itu selalu memetakan satu byte ke dua karakter tanpa sisa. MIME Pembungkus Base64 menyentuh bantalan: string yang dibungkus kolom 76 masih memiliki bantalan di bagian paling akhir, hanya beberapa baris kemudian.
Memahami padding untuk Base64 adalah tentang memahami tata letak bit dan panjang input modulo tiga; begitu Anda melihat aritmatika, padding menjadi konsekuensi langsung, bukan aturan yang harus dihafal. Padding dapat diturunkan, bukan ajaib.
Apa yang tidak tercakup dalam hal ini — aturan padding base32 dan base16, dan konvensi panjang garis MIME
Dengan adanya string Base64 dengan panjang berapa pun, Anda dapat memulihkan bentuk bantalan kanonik dengan membagi jumlah karakter menjadi empat, mengambil sisanya, dan menambahkan jumlah tanda = yang sesuai. Inilah sebabnya mengapa = yang hilang dapat diperbaiki dan mengapa decoder yang ketat dapat memaafkan: padding membawa informasi (di cabang mana dari tiga kasus masukan Anda), tetapi informasi tersebut dapat dihitung dari panjangnya saja.
Encoder & decoder Base64 segera menampilkan output empuk sehingga Anda dapat membandingkan byte yang didekodekan dengan teks asli dan memverifikasi bahwa perjalanan pulang pergi berhasil. Base64 dan pengkodean terkait memperluas prinsip pengelompokan ulang bit ke dalam lebar karakter yang berbeda. RFC 4648 menentukan ketiganya, dan memahami yang satu membuat yang lain menjadi sederhana secara konseptual. Wawasan utamanya adalah bahwa pengkodean adalah manipulasi bit murni: pilih ukuran alfabet Anda, kelompokkan bit Anda sesuai dengan itu, cari setiap grup dalam sebuah tabel.
Kesimpulan: padding dapat diturunkan, jadi = yang hilang dapat diperbaiki — bagaimana encoder & decoder Base64 menunjukkan kepada Anda bentuk kanonik yang diisi dari teks apa pun yang Anda enkode
Decoding terbalik: cari setiap karakter, ekstrak bit, kelompokkan kembali, tulis byte. Pemetaan dua arah deterministik inilah yang menjadi alasan Base64 bekerja dengan andal di semua platform dan bahasa. Kesalahan dalam pengkodean dan penguraian kode sering kali disebabkan oleh kesalahpahaman padding atau perbedaan alfabet. Jika dekode gagal dengan kesalahan padding, periksa apakah decoder mengharapkan Base64 kanonik (dilapisi secara ketat) atau menerima varian. Jika gagal dengan kesalahan karakter, periksa apakah inputnya adalah base64url dan decoder mengharapkan Base64 standar.
Encoder & decoder Base64 menerima alfabet dan memvalidasi padding secara konsisten, sehingga setiap contoh perhitungan tangan dapat diverifikasi secara instan. Menguji pengkodean dengan mendekodekannya kembali adalah cara paling pasti untuk mengetahui kesalahan sebelum menyebabkan masalah produksi.