Alat pembangun · Pengekod & penyahkod Base64
Pelapik Base64 menjelaskan: apakah maksud tanda = dan bila ia diperlukan
· Bagaimana ia berfungsi
asas64 pengekodan aliran kerja pembangun
= pada penghujung rentetan Base64 bukan hiasan: ia merekodkan bilangan bait kumpulan terakhir adalah pendek. Siaran ini menerangkan aritmetik, sebab sesetengah rentetan tiada dan mengapa penyahkod tidak bersetuju tentang kehilangan padding.
Pengecualian 'lapik yang salah' daripada token yang kelihatan baik — penyahkod yang gagal dan satu atau dua aksara yang hilang di belakangnya
Apabila penyahkod Base64 melaporkan padding yang salah, rentetan kelihatan lengkap tetapi membawa ralat struktur. Tanda sama bukan kosmetik: setiap satu mengekodkan bilangan bait kumpulan terakhir adalah pendek, membolehkan penyahkod mengetahui dengan tepat bila data sebenar tamat. Memahami = tanda tersebut—dan mengapa penyahkod yang ketat menolak rentetan tanpanya—menukar ralat misteri kepada aritmetik yang boleh diramal. Segmen JWT mungkin mempunyai satu =, tiada atau dua. Respons API mungkin berakhir dengan bersih tanpa pelapik.
Ini mewakili pilihan yang disengajakan, bukan varian pelaksanaan. Proses penyahkodan tidak memerlukan padding secara mekanikal. Padding wujud untuk menjadikan output tidak jelas: sahaja diberikan rentetan Base64 tanpa metadata tentang panjang, penyahkod membaca padding dan mengetahui dengan tepat di mana data berakhir. Base64 mengekod kumpulan tiga bait kepada empat aksara. Tiga bait ialah 24 bits, mengumpul semula dengan sempurna kepada empat indeks 6-bit; masing-masing memilih satu daripada 64 simbol Base64. Apabila input bukan gandaan tiga, pengekod menghadapi sisa: satu atau dua bait tidak boleh membahagi sama rata dengan tiga.
Kumpulan tiga bait, blok empat aksara — mengapa modulo panjang input 3 memutuskan sama ada sifar, satu atau dua = tanda muncul
Pengekod melapisi kumpulan tersebut dengan mengalihkan bit ke dalam indeks pertama, meninggalkan sifar akhir. Untuk menandakan ini disengajakan, ia menambahkan = tanda: sifar untuk kumpulan lengkap, satu untuk dua bait akhir, dua untuk satu bait akhir. Aritmetik adalah deterministik: mengetahui panjang input dalam bait membolehkan anda mengira padding dengan segera. Satu bait menghasilkan dua aksara Base64 ditambah dua =. Dua bait menghasilkan tiga aksara tambah satu =. Tiga bait menghasilkan empat tanpa padding.
Sebarang input bukan gandaan tiga bait akan mempunyai padding; mana-mana yang berbilang tidak akan. Ini bukan pilihan—ia adalah aritmetik. Rentetan tanpa padding mesti mewakili tiga bait. Rentetan dengan satu sama mesti mewakili dua. Padding mengekod panjang input modulo tiga. Periksa penjelmaan tiga input: a tunggal, pasangan ab, tiga abc. ASCII a ialah bait 0x61; Base64 mengekodnya sebagai 0x61 00 00, mengumpul semula kepada kumpulan enam bit.
Apa yang terkandung dalam bit padding dan sebab penyahkod yang ketat menyemaknya — bit yang mesti sifar dan maksud pengekodan kanonik
Indeks 24, 4, 0, 0 peta ke Y, E, A, A. Oleh kerana dua kumpulan sedang berlapik, pengekod menambahkan dua = tanda, menghasilkan YQ==. Untuk ab, bait 0x61 0x62 menjadi 0x61 0x62 00. Bits berkumpul semula kepada indeks 24, 22, 8, 0, keluaran YWI=. Untuk abc, bait berkumpul semula kepada indeks 24, 22, 9, 35, keluaran YWJj tanpa padding. Padding tidak sewenang-wenangnya: ia terkeluar daripada reka letak bit. Apabila anda menyahkod rentetan Base64, penyahkod membaca setiap aksara, mencari indeks enam bitnya, membungkus bit ke dalam bait.
Untuk YQ==, aksara Y, E, A, A bongkarkan kepada bit. Pengumpulan semula kepada bait lapan bit memberikan satu bait, 0x61. Penyahkod membuang bit padding (sifar di belakang) dan melaporkan satu bait. Penyahkod yang ketat menyemak bahawa bit padding sebenarnya sifar; jika tidak, input itu bukan kanonik, bermakna seseorang yang dikodkan menggunakan reka letak bit yang berbeza dan nyahkod adalah samar-samar. Sistem yang mengecualikan pelapik sepenuhnya membuat pertukaran yang disengajakan. JWT segmen menggunakan Base64url tanpa pelapik, bergantung pada pengguna mengetahui jangkaan panjang output atau membuat kesimpulan.
Contoh yang berfungsi: pengekodan 'a', 'ab' dan 'abc' dengan tangan — tiga input, tiga hasil padding, ditunjukkan sedikit demi sedikit
RFC 4648 membenarkan padding tidak hadir tetapi mengarahkan penyahkod untuk menerimanya jika ada. Pustaka kod berbeza: sesetengahnya akan memulihkan padding yang hilang dan meneruskan; orang lain akan gagal. Apabila anda menemui token yang gagal menyahkod, menambahkan bilangan tanda = yang betul sering membetulkannya. Diperlukan = tanda sentiasa sifar, satu atau dua, bergantung pada panjang rentetan modulo empat. Jika panjang rentetan Base64 bukan gandaan empat, padding pasti tiada atau rosak.
Panjang 5 tidak boleh sah Base64: setiap aksara lengkap mengekod enam bit, jadi empat aksara mengekod 24 bits (tiga bait) dan lima mengekod 30 bits, yang bukan gandaan lapan dan tidak boleh menjadi bait. Penyahkod mesti sama ada menolak ini atau menambah padding. Jika panjang ialah 2 modulo 4, tambah dua =. Jika 3 modulo 4, tambah satu =. Jika 0 modulo 4, jangan tambahkan satu pun. Rentetan panjang 3 tidak mempunyai = yang diperlukan; tambah satu dan ia menjadi sah sebelum penyahkodan.
Mengapa sesetengah sistem menggugurkan padding sepenuhnya — JWT segmen dan URL-token selamat yang meninggalkan = dan cara memulihkannya dari panjang
Menggabungkan dua tali Base64 berlapik putus jika padding dibiarkan di tempatnya. Dua pengekodan berasingan yang digabungkan secara langsung menghasilkan aksara padding sesat yang memecahkan abjad penyahkodan. Inilah sebabnya mengapa sesetengah sistem menanggalkan padding sebelum menggabungkan: token yang terdiri daripada tiga segmen Base64url yang dicantumkan dengan titik tidak mempunyai padding dalam segmen, menjadikan penyambungan menjadi mudah. Jika membina nilai Base64 daripada bahagian, sahkan sama ada setiap bahagian berlapik dan jalur atau tambah padding secara konsisten sebelum sebarang operasi.
Pengekod & penyahkod Base64 menggunakan RFC 4648, yang memerlukan pelapik secara lalai. Apabila anda memasukkan teks dan meminta output base64, alat ini menghasilkan hasil empuk: bentuk kanonik. Jika anda melihat Base64 tanpa padding dan ingin menyahkodnya, semak sama ada penyahkod anda menerima padding yang tiada. Alat ini menerima input berlapik dan tidak berlapik dan memulihkan bait asal dengan betul. Untuk penyahpepijatan, pengiraan panjang modulo empat memberitahu anda sama ada padding telah dilucutkan dan formula memberitahu padding yang sepatutnya ada.
Kesilapan biasa: memangkas = seolah-olah ruang kosong, atau menggabungkan dua rentetan empuk — bagaimana setiap satu merosakkan penyahkod
Base32 dan Base16 (heksadesimal) mempunyai peraturan pelapik berbeza yang ditakrifkan dalam RFC 4648 bahagian 6 dan 7. Penggunaan Base32 = tetapi kumpulan akhir boleh 2, 4, 5, 7 atau 8 aksara bergantung pada panjang input modulo lima. Perenambelasan tidak memerlukan pelapik; ia sentiasa memetakan satu bait kepada dua aksara tanpa baki. MIME Pelapik sentuhan pembungkusan Base64: rentetan berbalut 76-lajur masih mempunyai pelapik di hujungnya, sahaja beberapa baris kemudian.
Memahami padding untuk Base64 adalah tentang memahami susun atur bit dan panjang input modulo tiga; sebaik sahaja anda melihat aritmetik, padding menjadi akibat langsung, bukan peraturan untuk menghafal. Padding boleh diperolehi, bukan ajaib.
Perkara ini tidak meliputi — peraturan pelapik base32 dan base16 serta MIME konvensyen panjang baris
Memandangkan rentetan Base64 dengan sebarang panjang, anda boleh memulihkan bentuk berlapik kanonik dengan membahagikan kiraan aksara dengan empat, mengambil baki dan menambahkan nombor yang sepadan bagi tanda =. Inilah sebabnya missing = boleh dibetulkan dan mengapa penyahkod yang ketat boleh memaafkan: padding membawa maklumat (cawangan tiga kes yang dimasukkan ke dalam input anda), tetapi maklumat itu boleh dikira dari panjang sahaja.
Pengekod & penyahkod Base64 menunjukkan keluaran empuk serta-merta supaya anda boleh membandingkan bait yang dinyahkod dengan teks asal dan mengesahkan perjalanan pergi dan balik berfungsi. Base64 dan pengekodan yang berkaitan memanjangkan prinsip mengumpul semula bit ke dalam lebar aksara yang berbeza. RFC 4648 menentukan ketiga-tiganya, dan memahami satu menjadikan orang lain mudah dari segi konsep. Wawasan utama ialah pengekodan ialah manipulasi bit tulen: pilih saiz abjad anda, kumpulkan bit anda dengan sewajarnya, cari setiap kumpulan dalam jadual.
Bawa pulang: padding boleh terbit, jadi missing = boleh dibetulkan — cara pengekod & penyahkod Base64 menunjukkan kepada anda bentuk kanonik empuk bagi mana-mana teks yang anda kodkan
Penyahkodan terbalik: cari setiap aksara, ekstrak bit, kumpulkan semula, tulis bait. Pemetaan dua hala yang menentukan ini adalah sebab Base64 berfungsi dengan pasti merentas semua platform dan bahasa. Ralat dalam pengekodan dan penyahkodan selalunya disebabkan oleh salah faham padding atau perbezaan abjad. Jika penyahkod gagal dengan ralat pelapik, semak sama ada penyahkod menjangkakan Base64 berkanun (berlapik ketat) atau menerima varian. Jika ia gagal dengan ralat aksara, semak sama ada input ialah base64url dan penyahkod menjangkakan Base64 standard.
Pengekod & penyahkod Base64 menerima kedua-dua abjad dan mengesahkan pelapik secara konsisten, jadi sebarang contoh yang dikira tangan boleh disahkan serta-merta. Menguji pengekodan dengan menyahkod semula adalah cara paling pasti untuk menangkap kesilapan sebelum menyebabkan masalah pengeluaran.