Alat pengembang · URL encoder & decoder
Cara kerja pengkodean persen: dari karakter hingga UTF-8 byte hingga urutan %XX
· Cara kerjanya
pengkodean url utf-8 pengkodean persen pengembang
Pengkodean persen tidak mengkodekan karakter; itu mengkodekan byte. Postingan ini menunjukkan bagaimana karakter menjadi UTF-8 byte dan kemudian berpasangan hex, dan mengapa huruf beraksen membutuhkan dua grup %XX sedangkan emoji membutuhkan empat grup.
Mengapa 'é' berubah menjadi %C3%A9 daripada %E9 — pengamatan yang mengungkapkan lapisan byte di bawahnya
Saat pengembang junior melihat %C3%A9 dalam URL, pengkodean persen beroperasi pada byte, bukan karakter. Karakter é bukan satu byte; UTF-8 mengkodekannya menjadi dua: C3 A9. Aturan pengkodean persen dari RFC 3986 sederhana saja: enkode setiap byte sebagai tanda persen diikuti oleh dua digit hex. Pembedaan itu mengubah penjelasan dari misterius menjadi logis.
Memahami pengkodean persen memerlukan pemahaman UTF-8. Teks harus dikonversi ke byte menggunakan pengkodean karakter. UTF-8 adalah standar untuk URL dan web. Ini mengekspresikan karakter sebagai urutan byte dengan panjang variabel: ASCII menggunakan satu byte, huruf beraksen menggunakan dua, emoji menggunakan empat. Setiap tahapan berbeda: karakter, titik kode Unicode, UTF-8 byte, lalu %XX berpasangan. Melewati ke hex tanpa memahami byte tidak tepat sasaran.
Aturan pengkodean persen dari RFC 3986 — satu % diikuti oleh dua digit hex per byte, lebih disukai huruf besar
RFC 3986 mendefinisikan satu aturan: mengkodekan setiap byte sebagai persen diikuti oleh dua digit heksadesimal huruf besar. Karakter yang tidak dicadangkan yang tidak memerlukan pengkodean adalah huruf, angka, tanda hubung, garis bawah, titik, dan tanda gelombang. Segala sesuatu yang lain harus dikodekan. Spasi menjadi %20, garis miring menjadi %2F, dan tanda persen menjadi %25. Hal ini mencegah karakter khusus dalam nilai kueri melanggar struktur URL.
Spasi dikodekan sebagai byte 0x20, menjadi %20. Garis miring ke depan adalah 0x2F, menjadi %2F. Ini adalah ASCII karakter yang membutuhkan satu byte. Huruf beraksen dan emoji berbeda. Tanda persen menjadi %25. Pembatas khusus seperti titik dua dikodekan untuk mempertahankan struktur. Hal ini mencegah ampersand atau sama dengan yang tertanam dalam parameter kueri agar tidak melanggar penguraian. Setiap byte menjadi %HH.
UTF-8 sebagai jaringan karakter yang diasumsikan — mengapa URL modern UTF-8 dan di mana pengecualian lama berada
UTF-8 menggunakan pengkodean dengan panjang variabel. ASCII dari titik kode 0 hingga 127 berukuran satu byte. Karakter dari 128 hingga 2047, termasuk huruf Latin beraksen, berukuran dua byte. Karakter dari 2048 hingga 65535, yang umum dalam skrip Asia Timur, berukuran tiga byte. Karakter di atas 65535, termasuk sebagian besar emoji, berukuran empat byte. Setiap byte diawali dengan bit yang menandakan berapa banyak byte berikutnya.
Huruf beraksen é adalah kode Unicode titik U+00E9. UTF-8 mengkodekannya sebagai dua byte: 0xC3 dan 0xA9. Pengkodean persen menghasilkan %C3%A9. Jerman ü (U+00FC) dikodekan sebagai 0xC3 0xBC, menjadi %C3%BC. Spanyol ñ (U+00F1) dikodekan sebagai 0xC3 0xB1, menjadi %C3%B1. Polanya konsisten: byte pertama menandakan urutan dua byte. Satu huruf beraksen bertambah enam karakter dalam pengkodean.
Contoh praktis: pengkodean 'café 😀' byte demi byte — titik kode, UTF-8 byte, dan string yang dihasilkan
Emoji membuat lapisan byte terlihat jelas. Emoji jempol ke atas 👍 adalah kode titik U+1F44D. UTF-8 mengkodekannya sebagai empat byte: F0 9F 91 8D. Pengkodean persen menghasilkan %F0%9F%918D: dua belas karakter untuk satu simbol. Smiley 😀 (U+1F600) dikodekan sebagai F0 9F 98 80, menjadi %F0%9F%9880. Urutan empat byte menjadi dua belas persen karakter yang dikodekan.
Teks campuran menunjukkan mengapa memahami byte itu penting. Frasa "café 😀" mengandung ASCII biasa, aksen, dan emoji. Huruf c, a, f dikodekan sebagai 63, 61, 66. é dikodekan sebagai C3 A9. Spasi dikodekan sebagai 20. Emoji dikodekan sebagai F0 9F 98 80. Hasilnya adalah "caf%C3%A9%20%F0%9F%9880". Memahami byte mana yang memerlukan pengkodean membuat keluaran dapat diprediksi.
Penguraian kode secara terbalik - mengumpulkan %XX grup menjadi byte dan baru kemudian menafsirkannya sebagai UTF-8
Decoding membalikkan proses. Dekoder memindai pasangan %XX dan mengumpulkannya menjadi nilai byte. Melihat %C3%A9, ia mengekstrak byte C3 dan A9. UTF-8 decoding menafsirkannya sebagai karakter é. Jika suatu urutan tidak lengkap, seperti %C3 saja, hasilnya adalah kesalahan. Dekoder mengetahui dari bit awalan UTF-8 bahwa C3 memerlukan byte kedua.
Huruf besar/kecil tidak menjadi masalah dalam digit hex; %C3%A9 dan %c3%a9 mendekode secara identik. RFC mengizinkan huruf besar atau kecil, meskipun huruf besar lebih disukai. Namun huruf besar-kecil penting untuk karakter: é (seperti %C3%A9) tidak sama dengan É (seperti %C3%89). Perbandingan URL harus menormalkan pengkodean persen atau berisiko memperlakukan sumber daya yang identik sebagai sumber daya yang berbeda. Kerangka kerja dinormalisasi sebelum melakukan cache.
Mengapa huruf besar/kecil tidak penting dalam digit hex tetapi berpengaruh di tempat lain — aturan normalisasi dan perbandingan URL
RFC 3986 menyebutkan punycode untuk nama domain dan pengkodean formulir untuk pengiriman sebagai aturan terpisah. Punycode mengkodekan nama domain non-ASCII tanpa tanda persen untuk kompatibilitas DNS. Domain 😀.example menjadi "xn--js8h.example". Pengkodean formulir mengubah pengkodean persen dengan satu pengecualian: spasi menjadi tanda tambah, bukan %20. Formulir yang dikirimkan sebagai application/x-www-form-urlencoded menggunakan plus untuk spasi.
Alat pembuat enkode URL menampilkan ketiga mode: pengkodean komponen, pengkodean seluruh-URL, dan pengkodean formulir. Pengkodean komponen dengan encodeURIComponent mengkodekan setiap karakter khusus termasuk pembatas, cocok untuk nilai kueri. Pengkodean seluruh-URL dengan encodeURI mempertahankan karakter struktural untuk URL lengkap. Pengodean formulir ditujukan untuk POST badan. Masing-masing menggunakan UTF-8; mereka hanya berbeda dalam byte mana yang tidak dikodekan.
Punycode dan pengkodean formulir: standar saudara, bukan ekstensi pengkodean persen
Perspektif byte memecahkan URL misteri. Mengapa satu emoji memerlukan dua belas karakter? Karena UTF-8 menggunakan empat byte, masing-masing menjadi %HH. Mengapa beberapa URL memiliki %2F untuk garis miring sementara yang lain memiliki garis miring biasa? Karena mode pengkodean memutuskan: garis miring di segmen jalur tetap tidak dikodekan, namun di dalam nilai kueri harus %2F untuk menghindari kesalahan pembacaan.
Pikirkan dalam byte untuk pengkodean persen yang dapat diprediksi. Karakter adalah titik kode Unicode. UTF-8 adalah representasi byte-nya. Pengkodean persen adalah format transmisi. Perluasan karakter terjadi pada lapisan UTF-8. Kasus hex tidak mempengaruhi decoding tetapi kasus karakter mempengaruhi. Urutan byte yang tidak valid gagal di UTF-8 karena aturan awalan yang ketat. Alat pembuat enkode URL menunjukkan perkembangan ini.
Kesimpulan: pikirkan dalam byte — bagaimana encoder & decoder URL menampilkan keluaran %XX yang tepat untuk teks apa pun yang Anda tempel, di browser
Contoh praktis: mengkodekan "café 😀". Kata café memiliki huruf c, a, f sebagai ASCII byte tunggal: 63, 61, 66. é adalah UTF-8 dua byte: C3 A9. Ruang adalah 20. Emoji 😀 berukuran empat byte: F0 9F 98 80. Surat ASCII yang tidak dipesan tetap terlihat. Hasil: "caf%C3%A9%20%F0%9F%9880". Ini menunjukkan mengapa satu emoji bertambah menjadi dua belas karakter.
Kesimpulan: pikirkan dalam byte, bukan karakter. Pengkodean persen diterapkan setelah pengkodean UTF-8. Setiap byte menjadi %HH. Panjang variabel UTF-8 berarti karakter diperluas secara berbeda: ASCII menjadi %XX (dua karakter), aksen dua byte menjadi %XX%XX (enam karakter), emoji empat byte menjadi %XX%XX%XX%XX (dua belas karakter). Tempelkan teks ke alat pembuat enkode URL dan amati perkembangannya.