Alat pengembang · URL encoder & decoder
Dari RFC 1738 hingga Standar URL: bagaimana aturan pengkodean persen telah berkembang
· Latar belakang
pengkodean url rfc-sejarah standar web
Aturan untuk meng-escape karakter dalam URL telah ditulis ulang beberapa kali sejak 1994. Postingan ini mengikuti RFC 1738, RFC 2396, RFC 3986 dan Standar WHATWG URL dan menjelaskan apa yang berubah setiap saat.
Dari RFC 1738 hingga Standar URL—bagaimana aturan pengkodean persen berkembang
Tilde (~) menunjukkan bagaimana aturan pengkodean berubah antar generasi dan penerapan standar. RFC 1738 (1994) diperlukan %7E di mana saja; RFC 2396 (1998) memindahkan tanda gelombang ke unreserved memungkinkan tidak dikodekan. RFC 3986 (2005) mengonfirmasi status tanpa reservasi. URL lama dengan %7E tetap valid; keluaran pengembang baru ~. Evolusi mencerminkan pelajaran penerapan seiring dengan semakin matangnya web dan standarisasi infrastruktur. RFC 1738 bersifat konservatif karena infrastruktur awal bersifat heterogen dan bervariasi.
RFC 1738 mengkodifikasikan 1994 perilaku browser. Penerapan distandarisasi pada UTF-8; pembatasan terbukti tidak diperlukan. Standar selanjutnya melonggarkan pembatasan karakter. RFC 3986 memungkinkan decoding yang aman dari karakter yang tidak dicadangkan.
RFC 1738 (1994): karakter 'tidak aman' dan aturan pelolosan pertama — apa yang dianggap berbahaya dan alasannya
RFC 1738 mendefinisikan karakter "tidak aman" sebagai karakter yang bertentangan dengan sintaksis URI (spasi, garis miring), yang pernah digunakan dalam protokol (karakter kontrol), atau yang tidak dapat ditransmisikan dengan aman oleh sistem. Daftar konservatif yang dikodekan persen jauh lebih banyak dari yang diperlukan untuk internet modern. Banyak sistem awal yang ada sebelum RFC; itu mengkodifikasikan perilaku mereka. Karakter kontrol benar-benar berbahaya dalam protokol; spasi adalah masalah transmisi untuk klien HTTP yang membaca dari baris perintah. Sistem modern menangani kasus ini dengan lebih baik melalui pengkodean eksplisit.
Pengujian terhadap RFC 1738 mengungkapkan apa yang diharapkan oleh sistem lama. Enkode karakter dari spesifikasi URL tahun 1990-an dan bandingkan dengan RFC 3986 modern. Perbedaan menunjukkan apa yang menjadi santai. Kumpulan tanpa reservasi diperluas seiring waktu. Tanda hubung, titik, garis bawah selalu aman. Tilde membutuhkan RFC 2396 agar aman. Pendekatan konservatif berarti kompatibilitas ke belakang. URL lama yang dibuat berdasarkan aturan RFC 1738 tetap valid hingga saat ini. Normalisasi di bagian RFC 3986 6 memungkinkan penguraian karakter yang tidak dicadangkan dengan enkode persen yang tidak perlu dengan aman.
RFC 2396 (1998) — dicadangkan versus tidak dicadangkan, sintaksis umum, dan tilde direhabilitasi
RFC 2396 (1998) memperjelas jaringan karakter lebih teliti daripada RFC 1738. Ini memformalkan karakter yang dicadangkan yang melayani struktur URI versus yang tidak dicadangkan sebagai data literal. Tanpa syarat diperluas termasuk tanda hubung, titik, garis bawah, tanda gelombang. Ini mengakui sintaksis URI generik yang terpisah dari aturan khusus skema. RFC 2396 memperkenalkan perbedaan antara gen-delim (:, /, ?, #, [, ], @) dan sub-delim (!, $, &, ', (, ), *, +, ,, ;, =). Penamaan memperjelas karakter yang dicadangkan dibagi menjadi dua kelompok dengan peran struktural yang berbeda.
RFC 2396 memperkenalkan panduan normalisasi yang menentukan karakter berkode persen mana yang dapat didekode tanpa perubahan makna. Decoding karakter yang tidak dicadangkan menjadi normal. Tongkat pengkodean karakter yang dicadangkan. RFC 3986 menyederhanakan notasi lebih lanjut. Standar sangat menjaga kompatibilitas ke belakang.
RFC 3986 (2005) — ! * ' ( ) pindah ke sub-delim, gen-delim diberi nama, dan panduan normalisasi tiba
RFC 3986 (2005) adalah standar referensi modern untuk pengkodean persen. Itu tetap mempertahankan perbedaan/unreserved tetapi menyederhanakan notasi dan menambahkan panduan normalisasi. Tilde bergerak tanpa ragu-ragu. Karakter tanpa cadangan dengan kode persen yang diklarifikasi standar dapat didekode tanpa perubahan makna. RFC 3986 bagian 3 menjelaskan sintaksis URI dengan tepat. Bagian 2 mendefinisikan kategori karakter. Bagian 6 mendedikasikan aturan formal untuk normalisasi sintaksis. Normalisasi berbasis perbandingan menganggap URI identik jika bentuk yang dinormalisasi cocok. Penghapusan segmen titik dari jalur menjadi normal tanpa perubahan berarti.
Normalisasi penting untuk analitik, caching, mengikuti tautan. URL yang hanya berbeda dalam huruf hex digit (RFC 3986 lebih memilih huruf besar) dalam praktiknya harus sama. Normalisasi mencegah duplikat entri log dan cache hilang. Cache yang dikunci pada URL yang dinormalisasi menyajikan konten terlepas dari preferensi pengkodean pemohon. RFC 3986 panduan normalisasi memungkinkan sistem membuat keputusan yang konsisten. Namun penegakan yang ketat membuat URL berfungsi dengan baik di internet saat ini.
Standar WHATWG URL: menguraikan apa yang sebenarnya diterima browser — kumpulan enkode, skema khusus, dan toleransi kesalahan
WHATWG URL Standar (2016–sekarang) muncul dari pengalaman browser dengan URL yang tidak mengikuti RFC 3986 dengan sempurna. Browser menghadapi ruang yang tidak dikodekan, pengkodean campuran, dan keanehan. WHATWG menjelaskan penguraian browser yang sebenarnya, bukan tata bahasa teoretis. Browser dunia nyata telah mengembangkan aturan praktis untuk menoleransi spasi, menangani karakter yang lolos, memulihkan dari input yang salah. RFC 3986 tiba di 2005 dan mendefinisikan tata bahasa formal, namun praktiknya sudah sedikit berbeda.
WHATWG mendefinisikan sembilan set penyandian dengan aturan khusus konteks. Ruang di jalur menjadi %20; garis miring pada info pengguna menjadi %2F. Browser menerapkan standar yang lebih sempit untuk web. RFC 3986 memberikan garis dasar; WHATWG dibangun di atasnya.
Contoh praktis: satu URL dengan tanda gelombang, spasi, dan karakter non-ASCII — bagaimana setiap generasi aturan mengkodekannya
Domain yang diinternasionalkan menggunakan pengkodean punycode (München menjadi xn--mnchen-3ya). Jalur dan kueri masih menggunakan pengkodean persen. Bagian domain menggunakan punycode; bagian jalur dan kueri menggunakan pengkodean persen. Lapisan tidak bercampur atau mengganggu.
IDNA (Nama Domain yang Diinternasionalisasi dalam Aplikasi) memecahkan masalah nama host. Punycode mengkodekan non-ASCII menjadi ASCII untuk kompatibilitas DNS. Awalan xn-- memberi sinyal pengkodean punycode. Algoritma bersifat deterministik: münchen selalu menjadi xn--mnchen-3ya. Karakter non-ASCII harus dikonversi sebelum resolusi DNS. Pengkodean persen tidak berfungsi untuk nama host karena batasan DNS dan batasan label. Setiap pendekatan memecahkan masalah yang berbeda dengan benar. Standar berevolusi secara terpisah karena alasan yang baik.
Apa yang tidak tercakup dalam hal ini — IRI dan nama domain yang diinternasionalkan, yang memiliki sejarahnya sendiri
Pemilihan standar bergantung pada konteks. Membangun URL untuk browser? Ikuti RFC 3986; browser menerapkan WHATWG. Sistem yang lebih lama? Implementasi pengujian. Memahami evolusi mencegah kebingungan.
Pengembang modern harus mengikuti RFC 3986 atau WHATWG secara kontekstual. URL lama dan baru hidup berdampingan sehingga memerlukan pemikiran kompatibilitas yang cermat. Encoder & decoder URL mengikuti RFC 3986 secara keseluruhan, menawarkan referensi tetap yang terpisah dari perilaku browser. WHATWG menambahkan kumpulan pengkodean khusus komponen di luar dasar RFC. Mengetahui apa yang berubah saat membantu memahami mengapa sistem tidak setuju. Menguji URL Anda dengan kedua standar akan mengungkapkan kontrol standar mana di lingkungan Anda. Kedua standar tersebut benar.
Kesimpulan: ketahui buku aturan mana yang diikuti kode Anda — bagaimana encoder & decoder URL memberi Anda perilaku RFC 3986 sebagai titik referensi tetap
RFC 3986 normalisasi memungkinkan penguraian karakter yang tidak dicadangkan dengan enkode persen yang tidak perlu dengan aman. %41 dinormalisasi menjadi A. Karakter khusus yang dikodekan seperti %2F tidak pernah didekode; mengubah makna merusak struktur. Badan standar sangat menjaga kompatibilitas ke belakang. Perbaikannya memerlukan koordinasi di seluruh dunia yang mustahil dilakukan setelah beberapa dekade. Buku standar tidak merusak web secara surut. Mengubah keputusan pengkodean akan merusak miliaran sistem yang ada secara bersamaan.
Pengkodean persen mencakup tiga dekade evolusi yang cermat: dari RFC 1738 hingga RFC 2396 dan RFC 3986 hingga Standar WHATWG URL modern. Kode modern harus mengikuti garis dasar RFC 3986. URL lama dengan pengkodean sebelumnya tetap valid. Pengujian bolak-balik memastikan kebenaran dan kompatibilitas.