Panduan Enkoder dan Dekoder Base64: UTF-8, Base64url, dan Kesalahan
ToolMellow ·
Base64 merepresentasikan byte dengan sekumpulan kecil karakter yang dapat dicetak. Untuk mengenkode teks, ToolMellow terlebih dahulu mengubah Unicode dengan struktur valid menjadi byte UTF-8; untuk mendekode, byte tersebut harus membentuk teks UTF-8 yang valid. Tempel input, pilih Base64 standar atau aman untuk URL, lalu tekan Enkode atau Dekode. Konversi berjalan secara lokal di browser Anda.
Panduan ini menjelaskan format tepat yang diterima alat teks ini, contoh yang berguna, dan kesalahan umum. Base64 adalah pengodean yang dapat dibalik, bukan enkripsi atau kompresi. Konversi yang berhasil tidak mengautentikasi token, tidak mengamankan kata sandi, dan tidak membuktikan bahwa suatu file tidak berbahaya. Contoh di bawah merupakan ilustrasi tetap, bukan pengukuran data Anda.
Cara mengenkode atau mendekode teks
Buka enkoder dan dekoder Base64, lalu tempel teks atau string yang sudah dienkode. Biarkan Base64 aman untuk URL nonaktif untuk menggunakan alfabet standar, atau aktifkan jika format penerima memerlukan Base64url. Enkode mengubah seluruh input menjadi Base64; Dekode mengubahnya kembali menjadi teks UTF-8. Mengetik saja tidak menjalankan konversi.
Baca hasil sebelum menggunakan Salin hasil atau Unduh. Gunakan hasil sebagai input mengganti isi editor dengan hasil yang masih memenuhi batas input; setelah itu, pilih tindakan sebaliknya untuk menguji konversi pulang-pergi. Mengedit input atau mengubah opsi konversi membatalkan hasil lama. Bungkus baris mengubah pembungkusan tampilan, bukan karakter yang dienkode atau menambahkan karakter baris baru.
- Mulailah dengan contoh yang diketahui seperti
foodanZm9vsebelum memecahkan masalah nilai aplikasi. - Pilih alfabet yang diperlukan aplikasi; huruf dan angka yang sama pada kedua varian saja mungkin tidak menunjukkan varian suatu string.
- Simpan aslinya jika pelestarian persis per byte penting. Impor teks, pengodean karakter, dan tambahan akhir baris dapat mengubah apa yang Anda enkode.
Apa yang dilakukan Base64 terhadap byte?
Base64 membagi setiap kelompok tiga byte menjadi empat nilai enam bit, lalu memetakan nilai tersebut ke karakter alfabet. Kelompok terakhir yang pendek memerlukan penanganan khusus dan dapat menggunakan padding. Huruf yang terlihat merupakan representasi byte input, bukan bahasa baru atau kunci rahasia.
Contoh alfabet standar ini mencakup string kosong serta akhiran ASCII satu, dua, dan tiga byte. Spasi dan akhir baris dalam teks yang Anda enkode merupakan byte nyata yang mengubah hasil. Mendekode pengodean kanonis yang sama memulihkan teks UTF-8 asli, termasuk karakter tersebut.
| Teks UTF-8 | Base64 standar |
|---|---|
| String kosong | String kosong |
f | Zg== |
fo | Zm8= |
foo | Zm9v |
Hello | SGVsbG8= |
😀 | 8J+YgA== |
Base64 standar dibandingkan dengan Base64url
Kedua varian menggunakan huruf dan angka. Base64 standar menggunakan + dan / sebagai dua simbol alfabet terakhir; Base64url menggunakan - dan _. ToolMellow menyertakan = di akhir dalam mode standar jika diperlukan, dan menghilangkannya dalam mode aman untuk URL. Misalnya, emoji di atas menjadi 8J-YgA dalam mode aman untuk URL.
Dekoder hanya menerima alfabet yang dipilih. Kedua mode menerima input tanpa padding atau dengan padding opsional yang ditempatkan dengan benar. Base64url sendiri tidak selalu melarang padding: protokol yang menggunakannya menentukan apakah padding wajib, diizinkan, atau dihilangkan. Pilih format yang diperlukan, jangan menganggap setiap URL atau token memakai aturan yang sama.
| Sifat | Mode standar | Mode aman untuk URL |
|---|---|---|
| Simbol alfabet terakhir | + dan / | - dan _ |
| Padding enkode ToolMellow | Disertakan jika diperlukan | Dihilangkan |
| Padding dekode ToolMellow | Padding benar atau tanpa padding | Padding benar atau tanpa padding |
| Simbol campuran dari kedua varian | Ditolak | Ditolak |
Unicode, emoji, dan dekode UTF-8
Teks dikonversi melalui UTF-8, sehingga aksen, tulisan Mandarin, Arab, dan emoji dapat dikonversi kembali dengan benar jika input Unicode memiliki struktur valid. Panjang string JavaScript menghitung unit kode UTF-16; panjang byte UTF-8 berbeda. Emoji 😀 memakai dua unit UTF-16 tetapi empat byte UTF-8, yang menghasilkan delapan karakter Base64 dengan padding.
Enkode menolak surrogate Unicode yang tidak berpasangan. Dekode menolak UTF-8 tidak valid alih-alih diam-diam mengganti byte yang rusak. BOM UTF-8 di awal yang sudah dienkode dipertahankan sebagai U+FEFF dalam string hasil dekode; karakter ini mungkin tidak terlihat di editor. Teks valid juga dapat berisi karakter kontrol atau bentuk normalisasi Unicode yang berbeda. Base64 tidak menormalisasi teks atau membuatnya aman untuk dieksekusi.
RFC 3629: Pengodean karakter UTF-8WHATWG Encoding: TextEncoder, TextDecoder, dan penanganan BOMECMAScript: Panjang string dan isWellFormed
Padding, spasi, dan bit tidak terpakai yang kanonis
Padding terdiri atas paling banyak dua karakter = di akhir, dengan panjang yang sudah diberi padding habis dibagi empat. Dekoder juga mengizinkan input tanpa padding dengan akhiran valid, tetapi panjang tersisa satu tidak dapat merepresentasikan satu byte lengkap. Zg== dan Zg sama-sama didekode menjadi f; Zg= tidak valid. Input kosong memiliki hasil kosong yang valid.
Sebelum mendekode, ToolMellow hanya menghapus TAB, LF, CR, dan SPACE. Form feed, tab vertikal, spasi yang tidak dapat diputus (nonbreaking space), dan karakter spasi Unicode lainnya ditolak. Batas input asli diperiksa sebelum penghapusan ini. Dengan demikian, perilakunya lebih sempit daripada janji umum untuk mengabaikan semua karakter spasi.
Bit yang tidak terpakai dalam simbol alfabet terakhir harus bernilai nol di alat ini. Alat memeriksa bahwa pengodean ulang byte hasil dekode cocok dengan input yang sudah dinormalisasi tanpa padding. Zh== ditolak meskipun dekoder yang longgar mungkin menghasilkan byte yang sama dengan bentuk kanonis Zg==. RFC 4648 mengizinkan penolakan yang lebih ketat ini; diterima oleh dekoder lain tidak membuktikan bahwa input tersebut kanonis.
RFC 4648: Base64, Base64url, padding, dan pengodean kanonisWHATWG Infra: Dekode Base64 dengan aturan longgarWHATWG HTML: atob dan btoa
Seberapa besar Base64, dan apa yang memenuhi batas?
Untuk n byte input, panjang Base64 dengan padding adalah 4 × ceil(n / 3) karakter. Nol byte menghasilkan nol karakter; satu byte menghasilkan empat, dua menghasilkan empat, dan tiga menghasilkan empat. Pertambahan ukuran mendekati sepertiga untuk input besar, tetapi tidak tepat 33% untuk setiap nilai. Output aman untuk URL tanpa padding menghapus satu atau dua karakter padding terakhir jika ada.
Hitung byte UTF-8 untuk rumus ukuran dan unit kode UTF-16 untuk batas editor ini. Alat mengizinkan hingga 1,000,000 unit kode input sebelum karakter spasi dekode dihapus. Batas yang sama tidak diterapkan pada output: satu juta byte ASCII menghasilkan 1,333,336 karakter dengan padding. Salin dan Unduh tetap berfungsi, tetapi Gunakan hasil sebagai input tidak dapat memuat hasil yang melebihi batas input.
| Batas | Batas atau perilaku sebenarnya |
|---|---|
| Input editor/konversi | Hingga 1,000,000 unit kode UTF-16 |
| Ukuran byte file lokal | Harus kurang dari 4,000,000 byte |
| Panjang teks impor | Hingga 1,000,000 unit kode UTF-16 |
| Output terenkode | Dapat melebihi batas input; salin/unduh tetap tersedia |
RFC 4648: Base64, Base64url, padding, dan pengodean kanonisWHATWG Encoding: TextEncoder, TextDecoder, dan penanganan BOMECMAScript: Panjang string dan isWellFormed
Membuka file teks berbeda dengan mengenkode file biner
Kontrol file membaca file lokal sebagai teks UTF-8 melalui File.text(). File berukuran 4,000,000 byte atau lebih ditolak; teks yang lebih panjang dari 1,000,000 unit UTF-16 juga ditolak setelah dibaca. Aplikasi tidak mengunggah file untuk menjalankan konversi ini. Ekstensi nama file tidak membuktikan bahwa byte di dalamnya merupakan teks UTF-8.
Pembacaan file sebagai teks biasa menghapus BOM UTF-8 di awal dan mengganti urutan UTF-8 yang rusak. Hal ini dapat mengubah byte asli sebelum enkode. Perilaku tersebut berbeda dengan dekoder Base64, yang menolak UTF-8 rusak dan mempertahankan U+FEFF hasil dekode. Untuk gambar, PDF, byte sembarang, atau pemulihan file yang harus persis per byte, gunakan alat Base64 ke file yang terpisah jika sesuai; ruang kerja teks ini bukan enkoder file biner mentah.
W3C File API: Pembacaan teks BlobWHATWG Encoding: TextEncoder, TextDecoder, dan penanganan BOM
Mengapa input Base64 saya tidak valid?
Pertama, tentukan format yang diharapkan dan apakah nilai tersebut seharusnya menghasilkan teks. Hapus sintaks aplikasi di sekitarnya dengan sengaja, jangan menghapus karakter yang tidak dikenal sampai konversi berhasil. Dekoder ini tidak otomatis mengekstrak payload data URL, segmen token, string JSON dalam tanda kutip, atau HTML. Pembungkus tersebut memiliki aturan penguraian dan validasinya sendiri.
Jika alfabet dan bentuknya valid tetapi byte hasil dekode bukan UTF-8, data mungkin berupa file biner atau menggunakan pengodean karakter lain. Ini merupakan kesalahan cakupan teks, bukan bukti bahwa byte Base64 rusak. Jika akses papan klip tidak tersedia, pilih hasil dan salin secara manual. Browser yang tidak didukung atau worker yang diblokir juga dapat mencegah konversi; gunakan browser terkini yang didukung dan baca kesalahan yang ditampilkan.
| Gejala | Kemungkinan penyebab | Pemeriksaan berikutnya |
|---|---|---|
A | Panjang akhir yang tidak mungkin | Pastikan seluruh nilai telah disalin |
Zg= | Padding tidak lengkap | Gunakan input dengan padding benar atau tanpa padding |
Zh== | Bit tidak terpakai bernilai bukan nol | Periksa pembuat aslinya; bentuk kanonisnya Zg== |
8J-YgA dalam mode standar | Alfabet yang dipilih salah | Gunakan mode aman untuk URL jika protokol memerlukannya |
/w== | Byte hasil dekode bukan UTF-8 valid | Tentukan apakah payload berupa biner |
| Karakter tak terlihat yang tidak diharapkan | BOM atau karakter kontrol dalam teks hasil dekode | Periksa titik kode sebelum memakai kembali hasil |
RFC 4648: Base64, Base64url, padding, dan pengodean kanonisRFC 3629: Pengodean karakter UTF-8
Base64url, pengodean persen, dan data URL
Base64url dan pengodean persen menyelesaikan masalah yang berbeda. Pengodean persen merepresentasikan byte URL tertentu dengan urutan %; Base64url merepresentasikan seluruh urutan byte dengan alfabetnya sendiri. Tanda plus berubah menjadi spasi khusus dalam penguraian application/x-www-form-urlencoded, bukan dalam setiap URL secara umum. Gunakan enkoder dan dekoder URL untuk tugas terpisah itu.
Data URL memiliki skema data:, tipe media opsional, dan koma sebelum payload, serta penanda Base64 jika berlaku. Menempelkan seluruh pembungkus ke dekoder teks ini akan gagal pada pemeriksaan alfabet. Uraikan payload yang dimaksud menggunakan alat yang sesuai dan pertimbangkan apakah isinya teks atau biner. Base64 tidak membuat skrip yang disematkan, dokumen, atau file yang diunduh dapat dipercaya.
WHATWG URL: Penguraian formulir dengan pengodean URLRFC 2397: Skema data URL
Segmen JWT dan HTTP Basic adalah data protokol
JWS ringkas menggunakan tiga segmen yang dipisahkan titik; JWE ringkas menggunakan lima. Mendekode segmen teks JWT dapat menampilkan JSON, tetapi tidak memverifikasi tanda tangan, tidak mendekripsi konten terenkripsi, tidak memvalidasi kedaluwarsa, dan tidak menetapkan otorisasi. Segmen tanda tangan dapat berupa byte sembarang dan tidak harus dapat didekode menjadi UTF-8. Ikuti protokol token yang sebenarnya dan pustaka verifikasi yang dipelihara dalam aplikasi Anda.
Kredensial HTTP Basic menggunakan representasi Base64 dari urutan nama pengguna dan kata sandi dengan aturan pengodean karakter khusus protokol. Base64 tidak menambahkan kerahasiaan. Alat teks UTF-8 ini tidak membuktikan bahwa suatu kredensial cocok dengan interpretasi setiap server. Jangan menerbitkan kredensial asli sebagai contoh, dan gunakan transportasi aman serta prosedur autentikasi yang diwajibkan.
RFC 7515: Serialisasi ringkas JSON Web SignatureRFC 7516: Serialisasi ringkas JSON Web EncryptionRFC 7617: Autentikasi HTTP Basic
Base64 bukan enkripsi, hashing, atau kompresi
Siapa pun yang memiliki nilai Base64 dapat membalik representasinya tanpa kunci rahasia. Enkripsi memerlukan konstruksi kriptografi dan pengelolaan kunci; hash menghasilkan digest dengan tujuan dan sifat yang berbeda. Mengubah kata sandi ke Base64 tidak sesuai untuk penyimpanan kata sandi. Alat hash yang terpisah menghasilkan digest, bukan sistem penyimpanan kata sandi atau pengganti enkripsi.
Base64 juga memperbesar representasi byte, bukan memampatkannya. Base64 dapat membawa byte yang dienkripsi, dikompresi, atau ditandatangani, tetapi tidak membuat perlindungan itu sendiri. Tentukan kebutuhan aplikasi sebelum menambahkan lapisan pengodean, dan jangan sertakan rahasia dalam contoh yang dibagikan, tangkapan layar, atau hasil unduhan.
Salin, unduh, konversi pulang-pergi, dan hapus
Unduh menyimpan hasil sebagai teks UTF-8 dalam toolmellow-result.txt. Ini bukan rekonstruksi biner atau laporan konversi. Output kosong yang berhasil tetap mengaktifkan Salin hasil dan Unduh. Untuk pemeriksaan sederhana, enkode teks yang diketahui, gunakan hasil sebagai input jika masih memenuhi batas, lalu dekode dengan alfabet yang sesuai dan bandingkan teks aslinya.
Hapus menghilangkan input, hasil, kesalahan, isi pencarian/penggantian, dan riwayat editor, sambil mempertahankan pilihan aman untuk URL dan Bungkus baris. Menyegarkan atau menutup ruang kerja membuang data kerja yang tersimpan di memori; file yang sudah diunduh tetap berada di perangkat Anda. Hapus tidak menjamin penghapusan seluruh jejak yang dapat dipulihkan dari memori browser atau sistem operasi.
Arti dan batas pemrosesan lokal
Konversi berjalan dalam worker browser. Aplikasi tidak mengirim teks yang ditempel, isi file yang dipilih, atau hasil konversi ke server konversi. Input kerja disimpan di halaman saat ini, bukan sebagai riwayat akun. Baca halaman privasi situs untuk penjelasan lengkap mengenai penyimpanan dan pemindahan sementara.
Memuat situs web tetap membuat permintaan jaringan. Infrastruktur hosting menerima metadata koneksi dan permintaan biasa, dan situs publik menggunakan Google Analytics untuk kunjungan halaman dengan cookie serta informasi browser/perangkat. Konversi lokal bukan anonimitas atau janji tanpa lalu lintas jaringan maupun tanpa pencatatan infrastruktur. File unduhan dan hasil yang disalin secara manual dapat meninggalkan ruang kerja melalui tindakan Anda sendiri.
Sematkan alat Base64 beserta backlink-nya
Buka bagian integrasi di bawah ruang kerja alat, pilih bahasa halaman, lalu salin atau unduh cuplikan HTML yang disediakan. Tempelkan di area HTML yang mengizinkan iframe dan skrip eksternal. Cuplikan tersebut menyertakan iframe ruang kerja ToolMellow, skrip pengatur ukurannya, dan backlink yang terlihat ke halaman alat ToolMellow dalam bahasa yang sesuai. Pertahankan tautan kredit tersebut.
Pratinjau sematan dan periksa layar sempit. Cakupan teks dan batas inputnya tetap sama; sematan ini bukan API konversi jarak jauh atau enkoder file biner. Akses papan klip bergantung pada izin browser, dan platform Anda harus mengizinkan sumber daya eksternal. Backlink yang disediakan menggunakan nofollow dan noopener; keberadaannya tidak menjamin peningkatan peringkat pencarian.
Pertanyaan umum
Bagaimana cara mengenkode teks ke Base64?
Tempel teks Unicode dengan struktur valid, pilih mode standar atau aman untuk URL, lalu tekan Enkode. ToolMellow mengubahnya menjadi byte UTF-8 dan mengenkode byte tersebut secara lokal. Salin atau unduh teks hasilnya.
Bagaimana cara mendekode Base64 menjadi teks?
Pilih alfabet yang sesuai lalu tekan Dekode. Alat memvalidasi format dan bit tidak terpakai yang kanonis, kemudian mewajibkan UTF-8 valid. Padding opsional yang benar dan input tanpa padding diterima; data biner mungkin gagal pada pemeriksaan teks.
Apa perbedaan Base64 dan Base64url?
Dua simbol alfabet terakhir berbeda: standar menggunakan + dan /; aman untuk URL menggunakan - dan _. ToolMellow menyertakan padding standar jika diperlukan dan menghilangkan padding aman untuk URL. Kedua mode yang dipilih menerima input dekode dengan padding benar atau tanpa padding.
Mengapa Base64 diakhiri tanda sama dengan?
Satu atau dua tanda sama dengan di akhir melengkapi kelompok empat karakter terakhir jika jumlah byte tidak habis dibagi tiga. Padding bergantung pada format; dekoder ini juga mengizinkan bentuk tanpa padding yang valid.
Apakah Base64 mendukung emoji dan teks non-Latin?
Ya, melalui UTF-8. Jumlah unit UTF-16 dan byte UTF-8 yang digunakan emoji dapat berbeda. Enkode menolak surrogate tanpa pasangan, dan dekode menolak UTF-8 rusak alih-alih menggantinya.
Seberapa besar ukuran bertambah dengan Base64?
Panjang dengan padding adalah 4 × ceil(byte input / 3). Pertambahannya mendekati sepertiga untuk input besar dan bergantung pada pembulatan untuk input pendek. Hitung byte UTF-8, bukan karakter yang ditampilkan; output aman untuk URL tanpa padding menghapus padding akhir.
Mengapa dekoder lain menerima nilai yang ditolak ToolMellow?
Dekoder berbeda dalam alfabet, karakter spasi, padding, bit padding tidak terpakai, dan pengodean karakter teks yang diterima. ToolMellow menggunakan alfabet yang dipilih, menghapus hanya TAB, LF, CR, dan SPACE jika ada, serta mensyaratkan bit tidak terpakai bernilai nol dan UTF-8 yang valid. Penerimaan longgar di tempat lain bukan bukti input kanonis.
Bisakah saya mendekode PDF atau gambar di sini?
Alat ini menghasilkan teks UTF-8, bukan byte file sembarang. Gunakan alat Base64 ke file yang terpisah untuk rekonstruksi biner yang sesuai. Input file lokal di sini membaca teks dan dapat menghapus BOM atau mengganti UTF-8 tidak valid sebelum enkode.
Karakter spasi apa yang dapat saya sertakan saat mendekode?
Hanya TAB, LF, CR, dan SPACE yang dihapus. Form feed, tab vertikal, NBSP, dan karakter spasi Unicode lainnya ditolak. Batas input asli satu juta unit UTF-16 berlaku sebelum penghapusan karakter spasi.
Apakah Base64 merupakan enkripsi atau penyimpanan kata sandi yang aman?
Tidak. Base64 dapat dibalik tanpa kunci dan tidak menambahkan kerahasiaan. Base64 bukan enkripsi, hash kata sandi, atau kompresi. Mendekode token autentikasi juga tidak memverifikasi atau mengotorisasinya.
Mengapa hasil dapat diunduh tetapi tidak dapat digunakan sebagai input?
Output terenkode dapat lebih panjang daripada batas input satu juta unit UTF-16. Salin dan Unduh tetap tersedia, tetapi Gunakan hasil sebagai input menolak hasil yang terlalu besar. Satu juta byte ASCII menghasilkan 1,333,336 karakter dengan padding.
Bisakah saya menyematkan alat ini di situs web saya?
Ya. Gunakan cuplikan HTML dalam bahasa yang sesuai di bawah ruang kerja, pertahankan backlink ToolMellow yang terlihat, dan pastikan platform mengizinkan iframe serta skrip pengatur ukuran. Sematan memakai batas teks yang sama dan bukan API konversi server.
Sumber dan bacaan lanjutan
- RFC 4648: Base64, Base64url, padding, dan pengodean kanonis
- RFC 3629: Pengodean karakter UTF-8
- WHATWG Encoding: TextEncoder, TextDecoder, dan penanganan BOM
- ECMAScript: Panjang string dan isWellFormed
- WHATWG Infra: Dekode Base64 dengan aturan longgar
- WHATWG HTML: atob dan btoa
- W3C File API: Pembacaan teks Blob
- WHATWG URL: Penguraian formulir dengan pengodean URL
- RFC 2397: Skema data URL
- RFC 7515: Serialisasi ringkas JSON Web Signature
- RFC 7516: Serialisasi ringkas JSON Web Encryption
- RFC 7617: Autentikasi HTTP Basic