Alat pengembang · Encoder & decoder Base64
Mendekode Base64 ke UTF-8 tanpa mojibake: atob plus TextDecoder
· Cara kerjanya
base64 pengkodean unicode
atob() mengembalikan byte yang disamarkan sebagai karakter, itulah sebabnya teks beraksen tampak rusak setelah decoding. Posting ini menunjukkan saluran yang benar dari Base64 ke byte ke UTF-8 teks, dan cara mengenali pola kegagalan.
Respons API yang diterjemahkan menjadi 'Café' — gejala mojibake yang nyata dan dua byte di belakang dua karakter yang salah
String Base64 Q2Fmw6k= diterjemahkan menjadi byte (67, 97, 102, 195, 169), yang merupakan UTF-8 teks Kafe. Tempelkan ke dekoder yang naif (hanya konversi atob dan string) dan keluarannya sering kali berupa Kafe, setiap aksen diganti dengan dua karakter yang salah. Mojibake ini terjadi karena atob mengembalikan string byte (unit kode 0–255), bukan teks UTF-8. Byte 195 dan 169 mengkodekan aksen é di UTF-8.
Memperlakukannya seolah-olah karakter Latin-1 yang terpisah memberikan pola mojibake. Pipa yang benar adalah atob (byte sebagai string), lalu TextDecoder (menafsirkan byte sebagai UTF-8), dan teks asli muncul kembali. Fungsi atob tidak rusak; ini dirancang untuk data biner. Namanya berasal dari ASCII-ke-biner, dan string biner yang dihasilkannya adalah jaringan unit kode 0–255, masing-masing mewakili satu byte.
Apa yang sebenarnya atob() kembalikan — serangkaian unit kode 0–255 yang mewakili byte, bukan teks yang didekodekan
Jika Anda memberinya Q2Fmw6k= (Base64 standar), ia akan mengeluarkan string yang setiap karakternya satu byte: unit kode 67, lalu 97, lalu 102, lalu 195, lalu 169. Jika menampilkan string tersebut secara langsung atau ditafsirkan sebagai teks Latin-1, Anda akan melihat keluaran yang kacau. Langkah yang hilang adalah mengonversi unit kode menjadi array byte dan kemudian mendekode array sebagai UTF-8.
Perulangan charCodeAt memulihkan nilai byte: untuk setiap karakter dalam keluaran atob, panggil charCodeAt untuk mendapatkan unit kode (nomor 0–255), simpan di Uint8Array. Setelah array byte ada, teruskan ke TextDecoder dengan charset utf-8. TextDecoder membaca urutan byte dan menafsirkannya sebagai teks UTF-8, menggabungkan urutan byte seperti (195, 169) menjadi karakter tunggal seperti é. Byte (67, 97, 102, 195, 169) menjadi string empat karakter Café. Perulangan ini sengaja dibuat membosankan: baca setiap unit kode yang dikembalikan dengan charCodeAt dan tetapkan ke posisi Uint8Array yang cocok. Tidak ada keputusan berdasarkan karakter yang terjadi di sana. Satu-satunya interpretasi muncul ketika TextDecoder menerima array itu dan menerapkan UTF-8 dengan penanganan kesalahan fatal.
Mengubah string itu menjadi Uint8Array - loop charCodeAt dan mengapa ini merupakan salinan byte, bukan konversi
Proses dua langkah ini—pemulihan byte, lalu interpretasi UTF-8—adalah apa yang dilakukan encoder & decoder Base64 secara internal. Pola mojibake adalah tanda kesalahan ini. Jika Café muncul sebagai Café, Anda melihat interpretasi Latin-1 sebesar UTF-8 byte. UTF-8 byte untuk é adalah 0xC3 0xA9 (desimal 195, 169). Dalam bahasa Latin-1, satuan kode 195 adalah Ã, dan satuan kode 169 adalah ©.
Ketika urutan byte UTF-8 dibaca seolah-olah setiap byte adalah karakter Latin-1 yang terpisah, setiap urutan UTF-8 multi-byte menghasilkan karakter pengganti yang salah. Jika Café muncul sebagai Caf diikuti dengan karakter pengganti, atau sebagai Caf? atau Caf plus U+FFFD, Anda melihat kegagalan yang berbeda: decoder tidak mengenali urutan byte sebagai UTF-8 yang valid. Contoh nyata: Base64 SGVsbG8sIOS4lueVjCEg8J-Zgg== diterjemahkan sebagai berikut.
TextDecoder dan keputusan charset — mendekode sebagai UTF-8, dan mengapa charset adalah fakta terpisah yang harus Anda ketahui
atob menghasilkan string biner dengan byte (72, 101, 108, 108, 111, 44, 32, 228, 184, 180, 149, 140, 33, 32, 240, 159, 152, 130). Enam byte pertama adalah ASCII: menjadi Halo,. Byte 228, 184, 180 adalah urutan tiga byte UTF-8 yang mewakili CJK karakter. Byte 149, 140 adalah bagian dari urutan berikutnya. Urutan lengkap mencakup urutan emoji empat byte (240, 159, 152, 130) untuk karakter akhir.
Jika diproses dengan benar melalui TextDecoder, semua byte digabungkan untuk menghasilkan teks skrip campuran asli. Urutan byte UTF-8 memiliki panjang yang dapat diprediksi: byte yang dimulai dengan 0xxxxxxx adalah byte tunggal ASCII; byte yang dimulai dengan 110xxxxx mengharapkan byte berikut yang dimulai dengan 10xxxxxx (total dua byte); byte yang dimulai dengan 1110xxxx mengharapkan dua byte berikut (total tiga byte); byte yang dimulai dengan 11110xxx mengharapkan tiga byte berikutnya (total empat byte). Untuk sampel campuran CJK-dan-emoji, tampilan byte sangat bersifat diagnostik karena intuisi ASCII tidak lagi membantu. Beberapa byte menjadi milik setiap simbol yang terlihat, dan penghapusan satu byte akan menggeser urutan yang tersisa menjadi UTF-8 yang tidak valid. Penguraian kode yang ketat mengubah perubahan tersebut menjadi kegagalan, bukan kerusakan yang tampak masuk akal.
Contoh praktis: mendekode string Base64 yang berisi CJK dan emoji — byte, poin kode, dan string terakhir dibandingkan dengan aslinya
Urutan yang dimulai dengan 1111110x tidak valid di UTF-8 (dicadangkan untuk masa depan, tidak digunakan). Byte yang dimulai dengan 10xxxxxx tidak boleh muncul sebagai byte utama; itu adalah kelanjutan. Jika aliran byte melanggar aturan, itu tidak valid UTF-8. TextDecoder dengan charset utf-8 menafsirkan array berdasarkan aturan ini dan berhasil untuk urutan yang valid. Untuk tidak valid, ini melaporkan kesalahan.
Encoder & decoder Base64 menggunakan TextDecoder dengan mode ketat flag true. Ini berarti UTF-8 yang tidak valid menimbulkan kesalahan daripada memasukkan karakter pengganti secara diam-diam (U+FFFD). Jika string Base64 didekodekan menjadi byte yang tidak valid UTF-8, mode ketat akan muncul alih-alih melanjutkan dengan teks yang kacau. Ini adalah pilihan desain: muatan biner (gambar, kunci, data terkompresi) bukan teks dan tidak boleh diterjemahkan sebagai teks.
Mengenali polanya: Ã, †dan � — cara membedakan masalah Base64 dari masalah jaringan karakter
Jika mencoba memecahkan kode JPEG sebagai Base64, aliran byte tidak akan mewakili UTF-8 yang valid, dan penguraian kode yang ketat akan menolaknya. Alat ini menawarkan tampilan hex untuk muatan tersebut: Anda dapat melihat byte mentah tanpa berpura-pura bahwa itu adalah teks. Mengenali kesalahan dekode UTF-8 melibatkan melihat byte dalam konteks. Apakah angkanya ganjil di mana urutan multi-byte diharapkan?
Apakah byte pertama dari urutan potensial tidak valid (dimulai dengan 10xxxxxx)? Apakah byte lanjutan hilang? Tombol keluaran byte memberikan percabangan terbersih dalam penyelidikan. Jika hex muncul tetapi decoding teks gagal, penguraian Base64 berhasil dan payloadnya berupa biner, rusak, atau dikodekan dengan jaringan karakter yang berbeda. Mengubah tanda baca Base64 tidak dapat memperbaiki ketidakcocokan jaringan karakter setelah byte yang benar muncul.
Apa yang tidak tercakup di sini — UTF-16 payload, keluaran biner seperti gambar, dan penanganan byte tidak valid
Polanya konsisten. Satu byte 0xFF tidak pernah valid di UTF-8; tidak boleh berupa ASCII byte (hanya 0–127 yang ASCII) dan tidak boleh berupa byte utama (byte utama berukuran 0xC0–0xFD, 0xFF dicadangkan). Pengganti tunggal (konsep UTF-16) tidak boleh muncul di UTF-8; jika melihat urutan byte 0xED 0xA0 0x80 (yang mengkodekan pengganti U+D800 dalam gaya UTF-8), itu tidak valid UTF-8.
Salah satu solusi historis adalah btoa(unescape(encodeURIComponent(text))). encodeURIComponent mengubah kafe menjadi %C3%A9 (pengkodean persen UTF-8 byte), unescape mengemas ulang sebagai unit kode, btoa mengkodekan unit kode. Ini berfungsi untuk sebagian besar teks tetapi rapuh di sekitar teks pengganti dan sulit dibaca. Pipeline modern—TextEncoder ke byte, lalu base64—lebih jelas dan standar. TextEncoder dibangun di semua browser modern dan Node.js, membuat pilihan tepat. UTF-16, pengkodean byte tunggal lama dan konten file arbitrer memerlukan dekoder yang dipilih untuk byte tersebut atau penampil yang sadar biner. ToolAcre sengaja tidak menebak di antara mereka. Menebak dapat mengubah urutan yang tidak valid menjadi teks yang menyesatkan, sementara hex dump menyimpan setiap byte untuk interpretasi yang lebih tepat di kemudian hari.
Kesimpulan: Base64 memberi Anda byte, UTF-8 memberi Anda teks — bagaimana encoder & decoder Base64 melakukan kedua langkah sehingga teks yang didekode sama persis dengan input
Ketika Anda memiliki string Base64 dan menginginkan teks UTF-8, langkah lengkapnya adalah: mendekode Base64 menjadi byte (menggunakan pustaka decoding atob atau base64), membuat Uint8Array dari byte, meneruskan array ke TextDecoder dengan charset utf-8, membaca hasil sebagai string.
Jika inputnya adalah data biner dan bukan teks, lewati TextDecoder dan periksa byte secara langsung. Encoder & decoder Base64 menyediakan tampilan byte heksadesimal, mempertahankan nilai yang akan ditolak oleh dekode UTF-8 yang ketat. Garpu itu bersifat diagnostik: byte yang berhasil ditambah teks yang gagal berarti penguraian Base64 berfungsi, sedangkan muatannya biner, rusak, atau dikodekan dengan jaringan karakter yang tidak dapat ditebak oleh alat ini.