Alat pengembang · URL encoder & decoder
Mengapa + menjadi spasi saat Anda mendekode string kueri, dan saat tidak
· Cara kerjanya
pengkodean url javascript alur kerja pengembang
Apakah + berarti spasi bergantung pada dekoder mana yang Anda panggil. Posting ini menjelaskan bagaimana decodeURIComponent, URLSearchParams, dan kerangka kerja server masing-masing memperlakukan +, dan bagaimana menghindari perubahan nyata plus menjadi spasi.
Mengapa + menjadi spasi saat Anda mendekode string kueri, dan saat tidak
HTML pengiriman formulir menggunakan format application/x-www-form-urlencoded, dimana spasi menjadi nilai tambah. Server yang menerima name=Alice+Smith mengganti setiap tanda plus dengan spasi sebelum mengekstraksi nilainya. Ketika nilai tambah nyata ada dalam data, seperti dalam penghitungan 5+3, nilai tersebut tiba di server sebagai 5 3 setelah langkah penguraian kode formulir. Pertobatan yang tidak terlihat ini adalah akar dari kebingungan.
Penguraian kode JavaScript menghasilkan hasil yang berbeda tergantung pada fungsi yang Anda gunakan. URLSearchParams memperlakukan plus sebagai spasi, mencocokkan perilaku server. Tapi decodeURIComponent membiarkan plus tidak tersentuh, memperlakukannya secara harfiah. Asimetri antar fungsi inilah yang menyebabkan input yang sama diterjemahkan secara berbeda. Pengembang yang mengharapkan kedua decoder menghasilkan hasil yang sama ternyata tidak.
Dua pengkodean yang mirip — RFC 3986 persen pengkodean versus aplikasi/x-www-form-urlencoded
Dua standar pengkodean terlihat serupa tetapi cara kerjanya berbeda. RFC 3986 mendefinisikan pengkodean persen: karakter apa pun menjadi %HH. Ruang menjadi %20. Standar application/x-www-form-urlencoded menambahkan singkatan: spasi bisa ditambah. Keduanya berfungsi dalam konteks formulir, tetapi nilai plus bersifat opsional dan spesifik untuk standar tersebut. Mereka adalah domain berbeda dengan tampilan serupa.
Memanggil decodeURIComponent hanya berlaku RFC 3986 decoding. Bunyinya %20 sebagai spasi dan plus sebagai plus literal. URLSearchParams menerapkan aturan penguraian kode formulir: persentase lolos menjadi karakternya, dan plus menjadi spasi. Kedua fungsi tersebut memecahkan masalah yang sama di domain berbeda. Mencampurnya menyebabkan nilai tambah yang sebenarnya hilang, atau ruang menjadi nilai tambah dan gagal diubah.
decodeURIComponent daun + sendirian; URLSearchParams mengubahnya menjadi spasi — dua perilaku JavaScript dibandingkan
Perilaku server bervariasi, sehingga menambah masalah. Rails atau Django secara otomatis menerapkan aturan formulir: plus menjadi spasi. Namun mengekstraksi dan mendekode string kueri mentah secara manual dengan dekoder URL tetap utuh. Nilai yang sama yang diproses oleh kerangka berbeda menghasilkan hasil yang berbeda. Kode server sering kali menangani hal ini secara implisit, menyembunyikan masalah hingga Anda menulis dekoder khusus.
Contoh: kolom nomor telepon menyimpan +1-555-0100 dengan plus sebagai kode negara. Formulir HTML mengkodekannya sebagai %2B1-555-0100 karena JavaScript dikodekan plus sebagai %2B. Server menerima ini. Jika menerapkan decoding formulir, %2B menjadi plus dan nilainya benar. Jika proxy menghapus pengkodean, memanggil decodeURIComponent pada hasilnya menghasilkan +1-555-0100. Setiap lapisan diterjemahkan satu kali.
Apa yang dilakukan server — perilaku kerangka kerja umum dalam string kueri dan isi permintaan, dijelaskan secara umum
JavaScript dapat menyandikan nilai menggunakan encodeURIComponent. Diberikan a+b, menghasilkan%2Bb. Ketika string yang dikodekan tersebut mencapai server atau dekoder yang sadar bentuk, %2B mendekode sebagai plus dan hasilnya benar. Jika Anda mengkodekan menggunakan aturan formulir, spasi menjadi plus dan plus nyata menjadi %2B. Apa pun pilihannya, pengkodean menghasilkan%2Bb. Interpretasinya bergantung pada aturan decoding mana yang berlaku.
Uji perjalanan pulang pergi: mulai dengan a+b. Encode dengan encodeURIComponent untuk mendapatkan%2Bb. Decode a%2Bb dengan decodeURIComponent dan pulihkan a+b. Berikan a+b ke URLSearchParams: ini memperlakukan plus sebagai spasi, menghasilkan a b. Berikan a%2Bb ke URLSearchParams untuk mendapatkan a+b kembali. Input yang sama yang didekodekan dengan dua cara menghasilkan output yang berbeda tergantung pada decoder yang Anda gunakan.
Contoh praktis: 'a+b' dan 'a%2Bb' melalui kedua decoder — empat hasil dalam sebuah tabel
Kesalahan umum terjadi secara langsung. Pengembang mendekode dengan decodeURIComponent dan bertanya-tanya mengapa data formulir yang masuk dengan nilai plus nyata rusak. Mereka seharusnya menggunakan URLSearchParams. Sebaliknya, seseorang menggunakan URLSearchParams ketika mereka harus menggunakan decodeURIComponent, dan setiap tanda plus literal menghilang. Pengkodean dua kali menghasilkan %252B, sehingga memerlukan pasangan encoder-decoder yang cocok untuk mendekode dengan benar.
Kesalahan lainnya adalah membuat string kueri dengan tangan sebagai ?q=value tanpa pengkodean. Setiap ampersand atau sama dengan nilai secara diam-diam akan membuat parameter baru. Browser tidak menebak-nebak jaringan; itu memperlakukan hasilnya sebagai bentuk yang benar. Hanya pengkodean yang disengaja dengan encodeURIComponent yang mencegah hal ini. URL encoder & decoder menampilkan ketiga fungsi tersebut, mengungkapkan apa yang dihasilkan masing-masing fungsi.
Kesalahan umum — mendekode dua kali, atau mengkodekan spasi sebagai + di segmen jalur
Aturan pengkodean formulir disebut application/x-www-form-urlencoded karena aturan ini menjelaskan header Tipe Konten isi permintaan HTTP. HTML formulir tanpa file yang diunggah mengirimkan isi formulir dalam format ini. String kueri dalam URL juga menggunakan konvensi ini, meskipun secara teknis tidak memiliki standar pengkodean resmi. URL spesifikasi memperlakukan kueri sebagai buram; makna plus tidak diwajibkan. Namun dalam aplikasi web, plus biasanya berarti ruang.
Untuk menjamin perilaku yang benar, enkodekan dengan sengaja dan dekodekan dengan fungsi pencocokan. Jika Anda menyandikan dengan encodeURIComponent, decode dengan decodeURIComponent. Jika membaca data formulir HTML atau badan permintaan dalam format formulir, gunakan URLSearchParams. Jangan pernah menebak berdasarkan penampilan. String seperti a+b bersifat ambigu. Decoder tidak dapat dipertukarkan.
Yang tidak tercakup dalam hal ini — data formulir multibagian dan JSON badan permintaan
Data formulir multibagian, badan permintaan JSON, dan standar lainnya memiliki aturan pengkodean terpisah. JSON tidak menggunakan tanda plus untuk pengkodean spasi atau persen; ia menggunakan pelolosan Unicode. Multipart menggunakan batasan yang berbeda. Artikel ini hanya mencakup string kueri dan isi yang dikodekan formulir saja, karena di situlah ambiguitas plus muncul. Selalu periksa header Content-Type dan RFC yang mendefinisikannya.
Selalu enkodekan nilai plus literal sebagai %2B jika nilai tersebut termasuk dalam nilai kueri. Encoder & decoder URL menunjukkan bagaimana plus dilindungi sebagai %2B dalam mode komponen, terpisah dari spasi yang menjadi %20. Lewati a+b dan a%2Bb melalui setiap mode, lalu periksa hasilnya. Perbandingan tersebut menunjukkan mengapa masukan yang sama diterjemahkan secara berbeda. Perbedaannya adalah perilaku yang benar dari dua standar yang berbeda.
Kesimpulan: selalu mengkodekan nilai tambah literal sebagai %2B — bagaimana encoder & decoder URL menunjukkan seperti apa suatu nilai sebagai nilai kueri yang dikodekan persen
Kesimpulan: plus dalam string kueri adalah singkatan pengkodean bentuk untuk spasi, bukan plus literal, kecuali jika berasal dari pengkodean yang melindunginya sebagai %2B. Decoder yang salah kehilangan perlindungan itu. URLSearchParams paling aman di JavaScript modern; itu menangani pengkodean formulir dan memberikan akses parameter bernama. Untuk string mentah, encodeURIComponent melindungi semuanya; decodeURIComponent menafsirkan %20 dan persen tetapi memperlakukan plus secara harfiah.
Uji ini: buat ?x=a+b dengan tangan dan tempelkan ke encoder & decoder URL. Periksa dan lihat URLSearchParams membaginya menjadi parameter x dengan nilai a b. Tempel ?x=a%2Bb dan lihat nilai a+b. Gunakan encodeURIComponent untuk membuat URL dan bandingkan. Konfirmasi visual tersebut memperjelas aturan: aturan bentuk menggunakan plus, pengkodean persen menggunakan %20, mencampurkannya adalah alasan mengapa plus menghilang ke luar angkasa.