Pengekod/Penyahkod URL

Tukar sebarang teks kepada pengekodan peratus selamat-URL serta-merta. Pengkod kami mengendalikan ruang kosong, aksara khas, Unicode, dan emoji.

Pilih antara:

• pengekodan komponen (untuk nilai pertanyaan)
• pengekodan URI (mengekalkan struktur URL)
• pengekodan data borang (+ untuk ruang kosong)

Nyahkod sebarang URL berkod peratus kembali kepada teks yang boleh dibaca. Tampal URL berkod, rentetan pertanyaan, atau parameter individu dan lihat teks asal serta-merta.

Mengendalikan:

• urutan %HH
• tambah sebagai ruang kosong
• aksara UTF-8 berbilang bait

Pengekodan URL berfungsi dengan menggantikan sebarang aksara yang tidak selamat atau dikhaskan dalam URL dengan tanda peratus diikuti oleh dua digit heksadesimal yang mewakili nilai bait aksara tersebut, satu skema yang ditakrifkan secara rasmi dalam RFC 3986 oleh IETF.

Ruang kosong menjadi %20, tanda ampersand menjadi %26, dan garis miring menjadi %2F. Aksara bukan ASCII mula-mula ditukar kepada urutan bait UTF-8 mereka, kemudian setiap bait dikodkan peratus, jadi huruf 'é' menjadi %C3%A9.

Menurut Dokumen Web MDN, pelayar mengenakan ini secara automatik melalui fungsi seperti encodeURIComponent. Hanya aksara tidak dikhaskan (A-Z, a-z, 0-9, tanda sempang, garis bawah, titik, tilde) dibiarkan tidak disentuh.

encodeURI mengekod URL lengkap sambil mengekalkan aksara struktur yang dikhaskan, manakala encodeURIComponent mengekod satu komponen tunggal dan melarikan aksara struktur tersebut juga.

Seperti yang didokumenkan oleh Dokumen Web MDN, encodeURI membiarkan :, /, ?, #, &, dan = utuh supaya keseluruhan alamat kekal berfungsi, menjadikannya betul untuk URL penuh. encodeURIComponent melarikan segala-galanya kecuali set tidak dikhaskan RFC 3986, jadi ia adalah pilihan yang betul untuk nilai parameter pertanyaan, segmen laluan, atau teks fragmen yang mungkin mengandungi aksara dikhaskan.

Menggunakan encodeURI di mana encodeURIComponent diperlukan ialah pepijat biasa: & yang tidak dikodkan di dalam nilai akan disalah baca sebagai pemisah parameter, merosakkan permintaan secara senyap.

RFC 3986 membahagikan aksara URL kepada set tidak dikhaskan dan dikhaskan, dan perbezaan ini menentukan apa yang dikodkan peratus.

• Aksara tidak dikhaskan ialah huruf A-Z dan a-z, digit 0-9, dan empat tanda tanda sempang, garis bawah, titik, dan tilde; ini tidak memerlukan pengekodan.
• Aksara dikhaskan termasuk pembatas am : / ? # [ ] @ dan sub-pembatas ! $ & ' ( ) * + , ; = yang membawa makna sintaksis.

Mengikut spesifikasi IETF, aksara dikhaskan boleh muncul tanpa dikodkan apabila menjalankan peranan pembatas mereka tetapi mesti dikodkan peratus apabila digunakan secara literal di dalam komponen. Segala-galanya di luar kedua-dua set, termasuk ruang kosong dan Unicode, harus sentiasa dikodkan.

URL menggunakan %20 untuk ruang kosong kerana aksara ruang kosong tidak dibenarkan muncul secara literal dalam URI di bawah RFC 3986, jadi ia dikodkan peratus kepada nilai bait ASCII, hex 20.

Terdapat konvensyen kedua: dalam data application/x-www-form-urlencoded, format yang digunakan oleh penyerahan borang HTML dan banyak rentetan pertanyaan, ruang kosong dikodkan sebagai tanda tambah (+) dan bukannya %20, seperti yang ditentukan oleh Piawaian URL WHATWG dan spesifikasi borang W3C.

Inilah sebabnya mengapa penyahkod mesti tahu konteksnya. %20 selamat secara universal dalam laluan, pertanyaan, dan fragmen, manakala + hanya bermaksud ruang kosong di dalam data pertanyaan berkod borang dan merupakan tanda tambah literal di tempat lain.

Pengekodan Unicode dikendalikan oleh pengekodan URL dengan menukar dahulu setiap aksara kepada urutan bait UTF-8 dan kemudian mengekod peratus setiap bait individu. Konsortium Unicode menentukan titik kod, dan UTF-8 (dinyatakan dalam RFC 3629) memetakannya kepada satu hingga empat bait.

Contohnya:

• Aksara ASCII bait tunggal seperti 'A' kekal sebagai 'A'
• 'é' dikodkan kepada %C3%A9
• aksara CJK '日' menjadi %E6%97%A5
• emoji seperti 😀 dikodkan kepada empat bait, %F0%9F%98%80

MDN Web Docs menyatakan bahawa encodeURIComponent JavaScript beroperasi pada UTF-8 secara lalai. Penyahkod menterbalikkan ini dengan mengumpul bait berkod peratus dan mentafsir semula sebagai strim UTF-8 untuk mendapatkan semula teks asal.

Pengekodan berganda berlaku apabila rentetan yang telah dikodkan peratus dikodkan semula, menukarkan setiap % kepada %25 supaya %20 menjadi %2520 dan nilai itu tidak lagi dapat dibaca dengan betul.

Ini adalah sumber biasa pautan rosak dan, mengikut OWASP, kebimbangan keselamatan kerana penyerang menggunakan pengekodan berganda untuk melepasi input berniat jahat melepasi penapis yang menyahkod sekali sahaja.

Untuk mengelakannya, kodkan nilai tepat sekali pada titik di mana ia memasuki URL, dan jangan sekali-kali mengekod semula data yang datang daripada sumber berkod lain. Jika anda tidak pasti sama ada rentetan telah dikodkan, nyahkodnya dahulu; jika output berubah dan kelihatan boleh dibaca, ia telah dikodkan, dan anda tidak seharusnya mengekodnya semula.

Pengekodan URL tidak selamat dan tidak memberikan kerahsiaan; ia adalah transformasi boleh balik untuk keselamatan pengangkutan, bukan penyulitan. Sesiapa sahaja boleh menyahkod rentetan berkod peratus serta-merta, jadi data sensitif yang diletakkan dalam URL kekal boleh dibaca sepenuhnya dan, seperti yang diberi amaran oleh OWASP, turut terdedah dalam sejarah pelayar, log pelayan dan pengepala Referer.

Pengekodan hanya memastikan aksara khas tidak merosakkan sintaks URL. Penyulitan, sebaliknya, menggunakan kunci dan algoritma seperti AES (diberi piawaian oleh NIST) untuk menjadikan data tidak boleh dibaca tanpa kunci tersebut.

Penggunaan keselamatan pengekodan yang betul digabungkan dengan pelarian output yang betul untuk mengelakkan serangan suntikan; jangan sekali-kali menganggapnya sebagai cara untuk menyembunyikan atau melindungi maklumat.

Untuk mengekod rentetan pertanyaan dengan betul, gunakan encodeURIComponent pada setiap kunci dan nilai parameter secara berasingan sebelum menggabungkannya dengan & dan =, dan bukannya mengekod keseluruhan rentetan yang dipasang sekali gus.

Ini memastikan bahawa aksara rizab di dalam nilai, seperti & atau = dalam input pengguna, dilepaskan kepada %26 dan %3D supaya ia tidak boleh disalah anggap sebagai penanda sempadan, mengikut peraturan application/x-www-form-urlencoded yang diterangkan oleh Piawaian URL WHATWG. Contohnya, nilai 'hello world&x=1' mesti menjadi 'hello%20world%26x%3D1'.

Menurut MDN Web Docs, API URLSearchParams mengautomasikan ini dengan selamat. Sentiasa kodkan data bekalan pengguna sebelum memasukkannya ke dalam rentetan pertanyaan untuk mengelakkan suntikan parameter dan permintaan yang cacat.

Kesilapan pengekodan URL yang paling biasa ialah memilih fungsi yang salah: menggunakan encodeURI pada nilai pertanyaan membiarkan &, =, dan ? tidak dilepaskan, membiarkan input pengguna merosakkan struktur URL.

Ralat kerap yang lain, beberapa ditandakan oleh OWASP dan MDN Web Docs, termasuk:

• mengekod dua kali nilai supaya %20 menjadi %2520
• lupa bahawa + bermaksud ruang kosong hanya dalam data berkod borang
• mengekod keseluruhan URL selepas ia dibina dan bukannya mengekod setiap komponen terlebih dahulu

Pembangun juga tersilap mengendalikan UTF-8 dengan menyahkod bait sebagai Latin-1, yang menghasilkan mojibake untuk teks beraksen dan bukan Latin. Akhir sekali, jangan sekali-kali bergantung pada pengekodan untuk keselamatan; kegagalan untuk melepaskan output untuk konteks sasaran meninggalkan kerentanan suntikan terbuka walaupun terdapat pengekodan peratus yang sah.