Bahasa Indonesia

Alat pengembang · URL encoder & decoder

Apa yang dikodekan oleh konstruktor URL untuk Anda: kumpulan persen kode browser

· Cara kerjanya

pengkodean url javascript apa web-apis

Kumpulan pengkodean standar WHATWG URL diterapkan secara berbeda di seluruh jalur URL, kueri, dan komponen fragmen
Ilustrasi vektor ToolAcre asli

URL API secara diam-diam mengkodekan beberapa karakter dan membiarkan karakter lainnya, bergantung pada bagian mana dari URL tempat karakter tersebut berada. Posting ini menjelaskan kumpulan enkode WHATWG dan cara memprediksi hasilnya.

Spasi yang menjadi %20 dan | yang tetap ada - kasus nyata di mana new URL() mengkodekan sebagian jalur

Saat URL("https://example.com/hello world") baru berjalan, ruang menjadi %20 tanpa suara. Namun new URL("https://example.com/hello|world") tidak menyentuh pipa. Perbedaan ini tidak terjadi secara acak. Standar WHATWG URL mendefinisikan jaringan karakter terpisah yang akan dikodekan untuk setiap komponen URL: jalur, kueri, fragmen, dan info pengguna, masing-masing memiliki aturannya sendiri. Memahami kumpulan ini berarti memprediksi apa yang akan dilakukan konstruktor.

Ruang memerlukan pengkodean persen karena tidak aman pada HTTP dan mengganggu keterbacaan. Pipanya berbeda: bukan karakter khusus yang membagi struktur, jadi browser membiarkannya. Batas antara keamanan dan keterbacaan ditentukan oleh WHATWG, bukan dugaan. Menguji "hello world" menunjukkan pengkodean; pengujian "hello|world" mengungkapkan batasan untuk setiap bagian URL.

Satu URL, beberapa set penyandian — jalur, kueri, fragmen, dan info pengguna masing-masing memiliki daftar karakternya sendiri untuk di-escape

Satu URL berisi beberapa wilayah, masing-masing memiliki aturan pengkodeannya sendiri. Jalurnya mengikuti satu set, kueri yang lain, fragmen yang ketiga, info pengguna yang keempat. Sebuah spasi menjadi %20 di jalur dan kueri. Tanda sama dengan tetap ada dalam kueri, yang memisahkan kunci dan nilai, tetapi encodeURIComponent mengubahnya menjadi %3D. Konstruktor URL mengetahui konteksnya dan menerapkan aturan yang benar untuk setiap bagian.

Kumpulan enkodenya tepat dan kecil. Path memiliki daftar karakternya sendiri; kueri memiliki daftar yang serupa tetapi berbeda. Hal ini mencerminkan karakter mana yang memiliki makna struktural. Garis miring ke depan membagi segmen jalur, jadi encodeURIComponent mengkodekannya sebagai %2F. Dalam sebuah fragmen, garis miring ke depan bisa muncul tanpa merusak apa pun. Memahami aturan WHATWG berarti memprediksi keluaran tanpa menjalankan kode.

Mengapa pengkodean persen bersifat satu arah: apa yang tetap dikodekan akan tetap seperti itu

Konstruktor URL melakukan normalisasi satu arah. Teruskan "%20" ke URL baru dan menghasilkan %20 tidak berubah. Konstruktor mengenalinya sebagai sudah dikodekan dan membiarkannya. Inilah sebabnya mengapa pengkodean ganda penting: pengkodean sekali, melewati konstruktor, dan pengkodean tetap. Konstruktor tidak mendekode, menafsirkan ulang, dan menyandikan ulang; itu terbaca ke depan.

Properti satu arah ini memengaruhi aplikasi yang memercayai URL.href sebagai kanonik. Jika Anda menggabungkan masukan pengguna dengan jalur Anda, masukan tersebut akan dinormalisasi tetapi tidak didekodekan. Nilai seperti "file+saya" tetap apa adanya, atau menjadi "file%2Bsaya" dalam beberapa konteks. Kode selanjutnya yang menggunakan decodeURIComponent mungkin dibaca plus sebagai spasi jika dari data formulir. Konstruktor melakukan normalisasi satu kali; setelah itu, nilai Anda tetap.

Contoh praktis: meneruskan string berantakan yang sama melalui URL() baru dan membaca href, pathname, dan searchParams — tiga tampilan berbeda

Ambil "hello world&foo=bar|test#anchor" dan letakkan di URL baru dengan komponen berbeda. Ruang menjadi %20 di mana-mana. Tanda ampersand di jalur tetap ada (tidak ada makna struktural di sana), tetapi dalam kuerinya juga tetap (memisahkan parameter, jadi normalisasi akan menghilangkan batas antara "q=" dan "foo=bar"). Pipa dan hash berperilaku berbeda berdasarkan lokasi.

Membaca href, pathname, dan searchParams menunjukkan tiga tampilan berbeda. nama jalur menunjukkan jalur yang dikodekan tanpa skema, host, atau kueri. searchParams memberikan parameter yang didekodekan, sehingga "hello+world" dari data formulir menjadi spasi. Properti pencarian mempertahankan string literal. href menunjukkan URL lengkap yang dinormalisasi. Ini hidup berdampingan pada satu objek; mana yang akan digunakan tergantung pada langkah Anda selanjutnya.

URLSearchParams dan aturan pengkodean formulir — mengapa ia menghasilkan + untuk spasi sementara nama jalur menghasilkan %20

URLSearchParams menerapkan pengkodean formulir: spasi menjadi plus, bukan %20. URLSearchParams baru({q: "hello world"}) menghasilkan "q=hello+world", bukan "q=hello%20world". Ini adalah aturan application/x-www-form-urlencoded historis. Namun jika Anda meneruskan string ini sebagai kueri mentah ke URL baru, nilai plusnya tetap plus; hanya URLSearchParams yang menerjemahkannya sebagai spasi. Konstruktor setia pada apa yang dilihatnya.

Perbedaan tanda plus ini menyebabkan bug umum. URL dari bilah alamat menggunakan %20 untuk spasi. Data formulir menggunakan plus. Jika Anda mendekode dengan decodeURIComponent (yang secara harafiah dibaca plus) alih-alih URLSearchParams.get, spasi menjadi karakter plus. Encoder & decoder URL menampilkan keduanya: tempel "hello+world" dan bandingkan mode komponen dan formulir untuk melihat di mana ruang muncul.

Membandingkan dengan encodeURI - di mana keduanya setuju dan di mana mereka berbeda

Konstruktor URL dan komponen encodeURI adalah alat yang berbeda. encodeURIComponent mengkodekan hampir semuanya kecuali huruf, angka, dan - _ yang tidak dicadangkan. ! ~ * ' ( ). Ini mengasumsikan tidak ada konteks. Konstruktor URL mem-parsing URL aktual dan menerapkan aturan WHATWG per komponen. encodeURIComponent mengubah "hello/world" menjadi "hello%2Fworld"; URL baru melihat garis miring sebagai pemisah jalur. Masukan yang sama, keluaran yang berbeda.

Gunakan encodeURIComponent saat membuat URL dengan menggabungkan bagian-bagian. Gunakan URLSearchParams atau konstruktor URL untuk URL lengkap atau sebagian. Jangan gunakan encodeURIComponent secara keseluruhan URL; kamu akan merusak skemanya. Bandingkan hasilnya dengan niat. Browser menerapkan opini struktur URL, dan URL baru mengimplementasikannya. Encoder & decoder URL menampilkan kedua tampilan secara berdampingan.

Apa yang tidak tercakup di sini — penguraian host, IDNA dan skema khusus versus non-khusus

Standar WHATWG URL adalah sumber kebenaran, meskipun membacanya memerlukan kesabaran. Kumpulan enkode ditentukan dalam fragmen algoritme, bukan daftar biasa. Dalam praktiknya, memahami prinsip lebih penting daripada menghafal jaringan. Jalur memungkinkan lebih banyak karakter (garis miring bersifat struktural); kueri memiliki aturannya sendiri; fragmen memiliki batasan paling sedikit (ditangani di sisi klien, tidak pernah dikirim ke server). Setiap komponen memiliki aturannya sendiri; mengetahui hal ini memberitahu Anda di mana mencarinya.

Normalisasi dan validasi adalah batasan yang berbeda. Konstruktor melakukan normalisasi: membersihkan pengkodean persen, menerapkan aturan komponen, memberikan bentuk kanonik. Itu tidak memvalidasi: karakter yang tidak valid dilempar, tetapi host kosong diterima. Konstruktornya ketat dalam hal format tetapi toleran dalam interpretasi. Untuk kepatuhan spesifikasi yang tepat, baca bagian byte yang dikodekan persen WHATWG. Untuk pembangunan sehari-hari, gunakan URLSearchParams, URL API, dan contoh nyata.

Kesimpulan: parser mempunyai opini - bagaimana encoder & decoder URL menunjukkan kepada Anda pengkodean persen nilai atau alamat sehingga Anda dapat membandingkannya dengan apa yang dihasilkan browser

Fitur WHATWG yang tidak didukung di sini mencakup penguraian host dengan konversi IDNA (nama domain internasional menjadi ASCII) dan penanganan skema khusus versus non-khusus. File: URL menggunakan otoritas garis miring ganda; data: URL tidak. Konstruktor menerapkan aturan ini. Mengonversi nama host dan menentukan status khusus merupakan bagian dari pembacaan spesifikasi, bukan pengkodean persen. Ini penting ketika membuat URL di berbagai skema.

Uji konstruksi URL Anda dengan membandingkan interpretasi browser dengan ekspektasi. Bangun dengan URL baru, baca properti yang penting: href untuk formulir lengkap, nama path untuk jalur, cari kueri mentah, searchParams untuk didekodekan. Jika hasilnya mengejutkan Anda, tempelkan ke encoder & decoder URL dan ikuti transformasi langkah demi langkah. Alat ini menunjukkan keluaran yang dinormalisasi bersama dengan pengkodean mentah, sehingga menunjukkan perbedaannya. Memahami kumpulan WHATWG berarti memahami pilihan browser dan cara menggunakannya.