Alat pengembang · URL encoder & decoder
RFC 3986 karakter yang dicadangkan dan tidak dicadangkan: apa yang dikatakan standar URI
· Latar belakang
pengkodean url rfc3986 pengkodean persen
RFC 3986 membagi karakter menjadi karakter yang dicadangkan, tidak dicadangkan, dan lainnya, dan pembagian tersebut menjelaskan setiap aturan pengkodean persen yang telah Anda penuhi. Posting ini membaca bagian yang relevan dengan jelas.
RFC 3986 karakter yang dicadangkan dan tidak dicadangkan—yang penting saat Anda membuat URL
RFC 3986 membagi karakter menjadi tiga kategori: tidak dicadangkan, dicadangkan, dan semua karakter lainnya yang harus dikodekan. Karakter yang tidak dicadangkan tidak memerlukan pengkodean—ini adalah huruf, angka, tanda hubung, titik, garis bawah, dan tanda gelombang. RFC mencantumkannya secara eksplisit di bagian 2.3, menyatakan bahwa aman untuk membiarkannya tanpa kode dalam konteks URI apa pun. Pengujian dalam encoder & decoder URL dengan karakter ini menunjukkan bahwa karakter tersebut lolos tanpa perubahan. Karakter yang dicadangkan dibagi lagi menjadi gen-delim (: / ? # [ ] @) dan sub-delim (! $ & ' ( ) * + , ; =), masing-masing dengan makna struktural dalam komponen URL yang berbeda.
Kapan suatu karakter perlu dikodekan? Karakter yang dicadangkan harus diberi kode persen hanya jika karakter tersebut menimbulkan ambiguitas. Garis miring menandai segmen jalur; dalam nilai kueri harus %2F. Tanda ampersand memisahkan parameter; & dalam suatu nilai memerlukan %26. Karakter yang tidak dicadangkan tidak perlu dikodekan—tanda hubung tetaplah tanda hubung. Standar URL memastikan penguraian yang benar. Pengujian dengan encoder & decoder URL: memasukkan "hello/world" dengan encodeURIComponent menghasilkan "hello%2Fworld"; dengan encodeURI itu mempertahankan garis miring.
Tanpa syarat: huruf, angka, tanda hubung, titik, garis bawah, dan tanda gelombang — karakter yang tidak perlu dikodekan dan tidak boleh dikodekan
Pengkodean persen menggunakan %HH dengan HH adalah notasi heksadesimal. ASCII huruf A (kode 65) menjadi %41. Non-ASCII é memerlukan pengkodean UTF-8: é (U+00E9) menjadi %C3%A9. Standar modern menetapkan UTF-8 secara seragam di seluruh browser.
URL lengkap memerlukan sintaksis struktural yang utuh; nilai kueri memerlukan karakter cadangan internal yang tidak berbahaya. Parameter kueri ?q=R&D harus mengkodekan & sebagai %26 jika manual, jika tidak, ampersand menjadi pemisah. Nilai dengan garis miring menjadi %2F dalam mode komponen. Pengkodean komponen (encodeURIComponent) menangani hal ini dengan menyandikan semuanya kecuali huruf, angka, dan - _ yang tidak dicadangkan. ! ~ * ' ( ). Pengujian menunjukkan perbedaan antar metode dengan jelas.
Dicadangkan: gen-delim dan sub-delim — kedua kelompok, anggotanya dan peran strukturalnya
String kueri menunjukkan mengapa karakter yang dicadangkan penting. Ampersand memisahkan pasangan kunci=nilai: ?utm_source=email&utm_campaign=sale berarti dua parameter. Di dalam suatu nilai, ampersand yang tidak lolos mengakhiri pasangan. Sama dengan memisahkan kunci dari nilai. Parsing terjadi pada banyak lapisan; masing-masing menerapkan aturan yang sama.
Karakter yang memerlukan pengkodean dalam nilai kueri mencakup ampersand, sama dengan, hash, tanda tanya, spasi, dan huruf non-ASCII. Hash paling licik: #apa pun menjadi pengidentifikasi fragmen, tidak pernah dikirim ke server. Nama kampanye yang diakhiri dengan hash kehilangan semuanya setelahnya sebelum permintaan meninggalkan browser. Spasi harus menjadi %20. Pengujian dengan encoder & decoder URL menunjukkan mode komponen dan bentuk. Pemahaman posisi menentukan kebutuhan pengkodean.
Ketika karakter yang dicadangkan harus dikodekan — hanya jika karakter tersebut akan disalahartikan sebagai pembatas, komponen demi komponen
Pengkodean persen tetap ada di RFC 3986. Set yang tidak dipesan tetap kecil untuk memastikan portabilitas. Karakter tanpa cadangan yang dikodekan dengan persen dapat didekode tanpa mengubah maknanya. Penguraian kode %41 ke A benar karena A tidak dicadangkan. Mendekode %2F menjadi / mengubah arti ketika garis miring adalah data, bukan pemisah. RFC 3986 bagian normalisasi 6 mencakup pendekatan sintaksis.
Karakter cadangan di posisi berbeda memiliki peran berbeda. Titik dua pada skema menandai skema: batas kewenangan; titik dua di info pengguna adalah data. Tanda tanya membuka bagian kueri; garis miring pada nilai kueri bersifat literal. Fragmen tanda pagar dimulai. Posisi menentukan kebutuhan pengkodean. String kueri membawa nilai yang merupakan URI itu sendiri. Mengkodekan pengalihan URL seperti https://example.com/page?param=value sebagai parameter memerlukan pengkodean garis miring dan titik dua ke %2F dan %3A. Konteks selalu mendefinisikan karakter aman.
Contoh praktis: mengklasifikasikan setiap karakter dari URL asli — tidak dicadangkan, dicadangkan sebagai pembatas, dicadangkan sebagai data
RFC 1738 (1994) menganggap banyak karakter tidak aman. Karena penerapan distandarisasi pada UTF-8, standar selanjutnya melonggarkan pembatasan. Tilde (~) mencontohkan evolusi: RFC 1738 diperlukan %7E, RFC 2396 (1998) memindahkan tilde ke unreserved, RFC 3986 mengonfirmasi status unreserved. Evolusi mencerminkan pembelajaran penerapan. Standar menjaga kompatibilitas ke belakang.
RFC normalisasi mengizinkan penguraian karakter yang tidak dikodekan dengan enkode persen yang tidak diperlukan. %41 dinormalisasi dengan aman ke A. Karakter khusus yang dikodekan seperti %2F tidak pernah didekode; mengubah makna merusak struktur. Konsensus modern menggunakan RFC 3986 sebagai acuan dasar. Encoder & decoder URL mengikuti RFC 3986 secara keseluruhan, menawarkan referensi tetap yang terpisah dari perilaku browser. WHATWG URL Standar menambahkan kumpulan pengkodean khusus komponen di luar RFC. Standar berlaku berdampingan: RFC 3986 untuk penguraian URL umum, WHATWG untuk browser web. Perpustakaan berbeda; periksa dokumentasi.
Panduan normalisasi di bagian 6 — aturan hex case, unreserved decoding, dan segmen jalur
Pengujian terhadap RFC 3986 memastikan URL berfungsi di seluruh perangkat lunak selama beberapa dekade. URL encoder & decoder memberikan RFC 3986 dasar pengkodean untuk diterapkan pada komponen yang dibuat. Baca dokumentasi standar yang menjelaskan setiap keputusan pengkodean di perpustakaan URL. WHATWG URL dibuat berdasarkan RFC 3986 dan bukan menggantikannya seluruhnya. Membangun URL untuk browser umum? Ikuti RFC 3986; browser menerapkan aturan WHATWG di atas. Sistem yang lebih lama? Uji implementasi aktual. Normalisasi untuk penyimpanan? Terapkan RFC 3986 secara konsisten. Memahami perbedaan yang dicadangkan/unreserved memberi tahu Anda karakter aman.
Pengkodean URL bukan sanitasi keamanan. Setiap konteks—SQL, HTML, JavaScript, URI—memerlukan pengkodean keluarannya sendiri. Pengkodean persen hanya melindungi struktur URL. Terapkan pertahanan yang tepat di lapisan kanan.
Apa yang tidak tercakup dalam hal ini — the WHATWG URL Kumpulan enkode standar yang berbeda dan IRI penanganan
RFC 2396 (1998) memperjelas jaringan karakter lebih teliti daripada RFC 1738. Ini memformalkan karakter khusus yang melayani struktur URI dan tidak dicadangkan sebagai data literal. Tanpa syarat diperluas termasuk tanda hubung, titik, garis bawah, tanda gelombang di atas definisi asli. RFC 2396 memperkenalkan perbedaan antara gen-delim (:, /, ?, #, [, ], @) dan sub-delim (!, $, &, ', (, ), *, +, ,, ;, =). Setiap kelompok memiliki peran struktural yang berbeda dalam URL. Penamaan memperjelas karakter yang dicadangkan dibagi menjadi dua kelompok. Mengetahui nama membantu diskusi teknis.
RFC 3986 (2005) adalah referensi modern. Itu tetap mempertahankan perbedaan/unreserved tetapi notasi disederhanakan. Badan standar tidak melanggar hukum secara surut. Encode dengan sengaja mengetahui standar Anda. Encoder & decoder URL menyediakan referensi RFC 3986.
Kesimpulan: standarnya singkat dan tepat — bagaimana dua mode encoder & decoder URL berhubungan dengan pengkodean data versus mempertahankan pembatas
Pemilihan standar bergantung pada konteks. Membangun URL untuk browser umum? Ikuti RFC 3986; browser menerapkan aturan WHATWG. Sistem yang lebih lama? Uji implementasi aktual. Normalisasi untuk penyimpanan? Terapkan RFC 3986 secara konsisten. Aturan pengkodean persen berevolusi dari RFC 1738 yang konservatif hingga RFC 2396 dan RFC 3986 yang diklarifikasi menjadi Standar WHATWG URL berlapis. Setiap generasi mencerminkan pengalaman. Pengembang modern mengikuti RFC 3986 atau WHATWG secara kontekstual. URL lama dan baru hidup berdampingan sehingga memerlukan pemikiran kompatibilitas. Memahami kategori mencegah kesalahan pengkodean.
Verifikasi URL yang dikodekan dengan benar sebelum penerapan. URL encoder & decoder mendemonstrasikan RFC 3986 aturan secara menyeluruh. Lihat nilai hex yang tepat dan pahami karakter mana yang dikodekan. Gunakan alat ini saat membuat URL dengan menggabungkan bagian-bagiannya. RFC 3986 kumpulan karakter partisi kategori yang dicadangkan dan tidak dicadangkan untuk penguraian URI yang konsisten.