Bahasa Indonesia

Alat pengembang · Encoder & decoder Base64

Apa kepanjangan dari atob dan btoa, dan mengapa mereka hanya mengerti bahasa Latin-1

· Latar belakang

base64 javascript unicode

model unit byte string biner btoa dan atob, berbeda dari teks Unicode
Ilustrasi vektor ToolAcre asli

atob dan btoa berasal dari Netscape dan namanya berarti 'ASCII ke biner' dan 'biner ke ASCII'. Postingan ini membahas dari mana mereka berasal, bagaimana standar WHATWG mendefinisikannya, dan mengapa mereka tidak pernah mempelajari Unicode.

Nama fungsi yang terbaca seperti salah ketik — kebingungan yang disebabkan oleh nama dan jawaban satu baris

atob dan btoa adalah JavaScript fungsi bawaan yang diperkenalkan di Netscape pada tahun 1990an. Nama-nama tersebut merupakan singkatan: btoa adalah singkatan dari biner untuk ASCII dan atob adalah singkatan dari ASCII untuk biner. Nama-nama tersebut mencerminkan usia dan desainnya: mereka dibuat ketika biner berarti serangkaian nilai byte (0-255) daripada Uint8Array atau Buffer yang lebih modern. Mnemonik yang sering diberikan untuk nama kurang penting dibandingkan kontrak yang dapat diamati: satu fungsi memetakan string biner ke Base64 dan fungsi lainnya membalikkannya. Repositori ini tidak mendokumentasikan keputusan penamaan asli, sehingga artikel tersebut menghindari penyajian cerita rakyat sebagai sumber riwayat browser.

Fungsinya mengharapkan string biner: setiap unit kode karakter harus berada dalam rentang 0-255, yang mewakili satu byte. Jika Anda meneruskan karakter dengan unit kode di atas 255 (seperti emoji atau huruf beraksen dari luar Latin-1), fungsi akan memunculkan InvalidCharacterError atau secara diam-diam menghasilkan keluaran yang salah. btoa (biner ke ASCII) mengkodekan string biner ke base64.

Apa yang disarankan oleh namanya dan apa yang sebenarnya dibuktikan oleh kontrak byte-string

Inputnya harus berupa string yang setiap karakternya adalah satu byte (unit kode 0-255). btoa(hello) mengkodekan ASCII byte sebagai base64 dan mengembalikan aGVsbG8=. btoa dengan huruf e-acute tampaknya berfungsi karena huruf Latin-1 yang telah dikomposisi sebelumnya e-acute (U+00E9) memiliki unit kode 233, yang berada dalam 0-255. Namun, btoa mengkodekannya sebagai satu byte, 0xE9, bukan UTF-8 byte 0xC3 0xA9 yang seharusnya dihasilkan oleh e-acute. Sebelum array yang diketik menjadi wadah byte normal, JavaScript API menggunakan string yang unit kodenya mewakili byte. Model tersebut tetap terlihat karena btoa menolak unit kode di atas 255. Kronologi produk yang tepat tidak ditentukan oleh file-file ini; batas kegagalan ditentukan oleh pengujian yang dapat dilakukan.

Korupsi diam-diam ini lebih berbahaya daripada kesalahan: hasilnya tampak baik-baik saja namun salah. atob (ASCII ke biner) mendekode base64 kembali ke string biner. atob(aGVsbG8=) mengembalikan halo. Outputnya adalah string biner dengan unit kode setiap karakter adalah 0-255, yang mewakili satu byte. Jika Anda ingin mengonversinya menjadi teks Unicode yang tepat, Anda perlu menafsirkan byte sebagai UTF-8 dan mendekodekannya dengan TextDecoder.

Model string biner lama — perilaku yang dapat diamati tanpa klaim riwayat browser yang belum diverifikasi

Untuk ASCII, langkah tambahan ini tidak diperlukan (ASCII adalah subset dari UTF-8), namun untuk byte non-ASCII, langkah ini penting. atob tidak melakukan interpretasi itu; ia mengembalikan byte mentah sebagai string biner.

Standar WHATWG (standar hidup untuk API web) mendefinisikan atob dan btoa dalam spesifikasi HTML. Definisi tersebut mencakup algoritme dekode base64 yang memaafkan untuk atob: ia melewatkan spasi dan menerima padding yang hilang, membuat base64 dunia nyata (termasuk base64 yang dibungkus MIME dengan jeda baris) dapat didekodekan. ToolAcre menormalkan spasi, URL tanda baca yang aman, dan bantalan yang hilang sebelum memanggil dekoder browser. Ia kemudian menyalin unit kode yang dikembalikan ke Uint8Array dan menerapkan decoder UTF-8 yang fatal. Kombinasi tersebut memisahkan sintaksis Base64 yang memaafkan dari interpretasi teks yang ketat.

Perilaku saat ini dalam implementasi ini — memaafkan normalisasi alfabet dan decoding teks UTF-8 yang ketat

Tanda tangan fungsi tidak berubah, namun definisi standar adalah wewenang atas apa yang dilakukan fungsi tersebut. Mengapa atob dan btoa hanya menerima bahasa Latin-1? Karena ketika dirancang pada tahun 1990-an, JavaScript tidak memiliki cara untuk merepresentasikan byte secara langsung (tidak ada Uint8Array atau ArrayBuffer). Satu-satunya cara untuk meneruskan byte ke suatu fungsi adalah sebagai string yang setiap karakternya mewakili satu byte.

Ini disebut string biner dan membingungkan menurut standar modern. String JavaScript adalah teks Unicode, bukan urutan byte. Desainnya menggabungkan keduanya: string yang setiap unit kodenya 0-255 adalah string biner. Penamaannya mencerminkan era: ASCII dalam btoa secara harfiah berarti tujuh bit untuk ASCII teks, tetapi implementasinya menerima byte apa pun (0-255). Menambahkan mode Unicode langsung ke btoa akan mengubah kontrak byte-string yang sudah lama ada dan kompatibilitas risiko. Sumber yang ditinjau malah menulis TextEncoder sebelum melakukan pengkodean. Artikel ini dapat memverifikasi komposisi tersebut; itu menghilangkan klaim tentang motif komite standar yang tidak dicatat dalam repositori.

Contoh praktis: menelusuri forgiving-base64 pada string dengan spasi dan padding yang hilang - apa yang diterima atob dan ditolak oleh decoder yang ketat

Alternatif modern menghindari model string biner. Pengkodean API menyediakan TextEncoder untuk mengonversi teks menjadi UTF-8 byte, dan TextDecoder untuk mengonversi UTF-8 byte kembali menjadi teks.

Pengkodean dan penguraian kode Base64 kini ditentukan dalam spesifikasi HTML untuk string (atob dan btoa) dan array yang diketik. Alat encoder & decoder Base64 menggunakan TextEncoder dan TextDecoder di sekitar atob dan btoa, sehingga Anda dapat dengan aman menyandikan dan mendekode teks Unicode tanpa batasan Latin-1. Nilai dengan spasi atau tanpa bantalan berhasil karena normalisasi menghilangkan spasi dan memulihkan panjang blok yang diperlukan. Nilai yang panjangnya dibersihkan menyisakan sisa satu ditolak sebelum atob. Perbedaan ini menunjukkan apa yang dimaksud dengan “memaafkan” di sini: format yang dapat dipulihkan diterima, sedangkan masukan yang secara struktural tidak mungkin diterima tidak.

Standar yang lebih baru berfungsi di Base64 untuk array yang diketik — dijelaskan secara kualitatif, dengan catatan untuk memeriksa dukungan browser saat ini

Menangani Unicode dengan btoa memerlukan pengkodean teks ke UTF-8 byte terlebih dahulu. Solusi lama adalah btoa(unescape(encodeURIComponent(text))), yang membingungkan tetapi berfungsi: encodeURIComponent persen mengkodekan UTF-8 byte, unescape mengubah triplet kembali ke karakter, dan btoa mengkodekan string biner yang dihasilkan. Ini berfungsi tetapi bergantung pada fungsi yang tidak digunakan lagi dan sulit dibaca. Kode modern harus menggunakan TextEncoder(text).map(byte => String.fromCharCode(byte)) diikuti oleh btoa, atau lebih baik, langsung dikonversi ke Uint8Array dan menggunakan Encoding API.

Atob tidak secara otomatis memberi Anda teks; itu memberi Anda biner. atob(Y2Fmw6kg8J+YgA==) mengembalikan string biner yang berisi byte teks berkode UTF-8 dengan aksen caf dan emoji. Untuk memulihkan teks, konversikan string biner menjadi Uint8Array dan teruskan ke TextDecoder(utf-8). Alat encoder & decoder Base64 melakukan ini secara otomatis: Anda menempelkan teks, itu mengkodekannya ke UTF-8 byte, lalu ke base64. API Base64 Typed-array berkembang di seluruh browser, tetapi sumber ini tidak menggunakannya. Bergantung pada salah satunya memerlukan pemeriksaan kompatibilitas dan rencana cadangan saat ini. Konversi array byte eksplisit ToolAcre tetap dapat diperiksa dan tercakup dalam jaringan pengujian saat ini.

Alternatif array yang diketik terus berkembang — verifikasi dukungan browser saat ini sebelum bergantung pada alternatif tersebut

Anda menempelkan base64, itu diterjemahkan ke UTF-8 byte, lalu ke teks. Langkah string biner perantara disembunyikan karena merupakan detail implementasi API tahun 1990-an. Memahami atob dan btoa berguna untuk men-debug kode lama atau bekerja dengan API lama yang memberikan string biner kepada Anda. Kebanyakan kode baru harus menghindari model string biner sepenuhnya.

Jika Anda perlu menyandikan atau mendekode base64, alat encoder & decoder Base64 menangani Unicode dengan benar. Jika Anda membuat API, terima Uint8Array atau tampilan array yang diketik, atau dokumentasikan dengan jelas apakah base64 Anda adalah UTF-8 atau Latin-1. Saat meninjau kode yang menggunakan btoa dengan teks non-ASCII tanpa TextEncoder, ada bug: output mengkodekan byte yang salah. Node Buffer dan runtime non-browser menentukan API dan aturan penerimaan yang berbeda. Mereka sengaja dikucilkan. Klaim dalam artikel ini berkaitan dengan primitif browser dan pembungkus yang diterapkan di apps/dev, tidak semua fungsi bernama atob atau btoa di setiap lingkungan.

Kesimpulan: dua fungsi tahun 1990-an dengan kontrak byte-string — bagaimana encoder & decoder Base64 melakukan UTF-8 mengelilinginya sehingga memberi aksen, CJK, dan emoji bolak-balik

Nama atob dan btoa adalah artefak khas komputasi tahun 1990an. Penamaan modern adalah base64Encode dan base64Decode, dan API akan menerima Uint8Array atau string dengan deklarasi pengkodean eksplisit. Namun atob dan btoa tetap ada di browser untuk kompatibilitas ke belakang. Memahami maksudnya (dan apa yang tidak bisa dilakukan) membantu Anda menghindari kerusakan diam-diam saat menyandikan teks Unicode.

Alat encoder & decoder Base64 menjembatani kesenjangan tersebut: alat ini berbicara dalam bahasa UTF-8 dan base64 yang dibutuhkan kode modern. Pola kuatnya bersifat komposisi: menyandikan teks menjadi UTF-8 byte, mengonversi byte menjadi kontrak string biner, lalu memanggil btoa; membalikkan langkah-langkah tersebut di sekitar atob. Coba aksen, CJK karakter, dan emoji, lalu minta teks yang didekode agar cocok dengan setiap titik kode asli.