Alat pembangun · URL pengekod & penyahkod
Cara pengekodan peratus berfungsi: daripada aksara kepada UTF-8 bait kepada %XX jujukan
· Bagaimana ia berfungsi
pengekodan url utf-8 pengekodan peratus pemaju
Pengekodan peratusan tidak mengekod aksara; ia mengekodkan bait. Siaran ini menunjukkan cara watak menjadi UTF-8 bait dan kemudian pasangan hex, dan sebab huruf beraksen mengambil dua %XX kumpulan manakala emoji mengambil empat.
Mengapa 'é' bertukar menjadi %C3%A9 dan bukannya %E9 — pemerhatian yang mendedahkan lapisan bait di bawahnya
Apabila pembangun junior melihat %C3%A9 dalam URL, pengekodan peratus beroperasi pada bait, bukan aksara. Watak é bukan satu bait; UTF-8 mengekodnya sebagai dua: C3 A9. Peraturan pengekodan peratus daripada RFC 3986 adalah mudah: mengekod setiap bait sebagai tanda peratus diikuti dengan dua digit hex. Perbezaan itu mengubah penjelasan daripada misteri kepada logik.
Memahami pengekodan peratus memerlukan pemahaman UTF-8. Teks mesti ditukar kepada bait menggunakan pengekodan aksara. UTF-8 ialah standard untuk URL dan web. Ia menyatakan aksara sebagai urutan bait panjang berubah: ASCII menggunakan satu bait, huruf beraksen menggunakan dua, emoji menggunakan empat. Setiap peringkat adalah berbeza: aksara, titik kod Unikod, UTF-8 bait, kemudian %XX pasangan. Melangkau ke hex tanpa memahami bait tidak bermakna.
Peraturan pengekodan peratus daripada RFC 3986 — satu % diikuti dengan dua digit heks setiap bait, huruf besar diutamakan
RFC 3986 mentakrifkan satu peraturan: mengekod setiap bait sebagai peratus diikuti dengan dua digit heksadesimal huruf besar. Aksara tidak terpelihara yang tidak memerlukan pengekodan ialah huruf, angka, sempang, garis bawah, noktah dan tilde. Semua yang lain mesti dikodkan. Ruang menjadi %20, garis miring menjadi %2F dan tanda peratus menjadi %25. Ini menghalang aksara khas dalam nilai pertanyaan daripada memecahkan struktur URL.
Ruang mengekod sebagai bait 0x20, menjadi %20. Garis miring ke hadapan ialah 0x2F, menjadi %2F. Ini ialah ASCII aksara yang memerlukan satu bait. Huruf beraksen dan emoji berbeza. Tanda peratus menjadi %25. Pembatas tersimpan seperti titik bertindih dikodkan untuk mengekalkan struktur. Ini menghalang ampersand terbenam atau sama dalam parameter pertanyaan daripada memecahkan penghuraian. Setiap bait menjadi %HH.
UTF-8 sebagai set aksara yang diandaikan — sebab URL moden UTF-8 dan di mana pengecualian warisan berada
UTF-8 menggunakan pengekodan panjang berubah-ubah. ASCII daripada titik kod 0 hingga 127 ialah satu bait. Aksara daripada 128 hingga 2047, termasuk huruf Latin beraksen, ialah dua bait. Aksara daripada 2048 hingga 65535, biasa dalam skrip Asia Timur, ialah tiga bait. Aksara di atas 65535, termasuk kebanyakan emoji, ialah empat bait. Setiap bait diawali dengan bit yang menandakan bilangan bait yang diikuti.
Huruf beraksen é ialah titik kod Unikod U+00E9. UTF-8 mengekodnya sebagai dua bait: 0xC3 dan 0xA9. Pengekodan peratus menghasilkan %C3%A9. Jerman ü (U+00FC) mengekod sebagai 0xC3 0xBC, menjadi %C3%BC. Bahasa Sepanyol ñ (U+00F1) mengekod sebagai 0xC3 0xB1, menjadi %C3%B1. Coraknya adalah konsisten: bait pertama menandakan urutan dua bait. Satu huruf beraksen mengembang enam aksara dalam pengekodan.
Contoh yang berfungsi: pengekodan 'kafe 😀' bait demi bait — titik kod, UTF-8 bait dan rentetan yang terhasil
Emoji menjadikan lapisan bait jelas. Emoji ibu jari 👍 ialah titik kod U+1F44D. UTF-8 mengekodnya sebagai empat bait: F0 9F 91 8D. Pengekodan peratusan menghasilkan %F0%9F%918D: dua belas aksara untuk satu simbol. Senyuman 😀 (U+1F600) mengekod sebagai F0 9F 98 80, menjadi %F0%9F%9880. Urutan empat bait menjadi dua belas peratus aksara yang dikodkan.
Teks bercampur menunjukkan sebab memahami bait penting. Frasa "kafe 😀" mengandungi ASCII biasa, loghat dan emoji. Huruf c, a, f mengekod sebagai 63, 61, 66. E dikodkan sebagai C3 A9. Ruang mengekod sebagai 20. Emoji mengekod sebagai F0 9F 98 80. Hasilnya ialah "caf%C3%A9%20%F0%9F%9880". Memahami bait yang memerlukan pengekodan menjadikan output boleh diramal.
Penyahkodan secara terbalik — mengumpul %XX kumpulan ke dalam bait dan kemudian mentafsirkannya sebagai UTF-8
Penyahkodan membalikkan proses. Penyahkod mengimbas untuk %XX pasangan dan mengumpulkannya ke dalam nilai bait. Melihat %C3%A9, ia mengekstrak bait C3 dan A9. UTF-8 penyahkodan mentafsirkannya sebagai aksara é. Jika urutan tidak lengkap, seperti %C3 sahaja, hasilnya adalah ralat. Penyahkod mengetahui daripada UTF-8 bit awalan bahawa C3 memerlukan bait kedua.
Kes tidak penting dalam digit heks; %C3%A9 dan %c3%a9 menyahkod secara sama. RFC membenarkan huruf besar atau huruf kecil, walaupun huruf besar lebih diutamakan. Tetapi kes penting untuk aksara: é (sebagai %C3%A9) tidak sama dengan É (sebagai %C3%89). URL perbandingan mesti menormalkan pengekodan peratus atau berisiko menganggap sumber yang sama sebagai berbeza. Rangka kerja menjadi normal sebelum caching.
Mengapa huruf besar tidak penting dalam digit heks tetapi berlaku di tempat lain — peraturan penormalan dan URL perbandingan
RFC 3986 menyebut punycode untuk nama domain dan pengekodan borang untuk penyerahan sebagai peraturan berasingan. Punycode mengekod nama domain bukan ASCII tanpa tanda peratus untuk keserasian DNS. Domain 😀.example menjadi "xn--js8h.example". Pengekodan borang mengubah suai pengekodan peratus dengan satu pengecualian: ruang menjadi tanda tambah dan bukannya %20. Borang yang diserahkan sebagai permohonan/x-www-form-urlencoded gunakan tambah untuk ruang.
Alat pengekod URL menunjukkan ketiga-tiga mod: pengekodan komponen, pengekodan keseluruhan-URL dan pengekodan borang. Pengekodan komponen dengan encodeURIComponent mengekod setiap aksara khas termasuk pembatas, sesuai untuk nilai pertanyaan. Pengekodan keseluruhan-URL dengan encodeURI mengekalkan aksara struktur untuk URL lengkap. Pengekodan borang adalah untuk badan POST. Masing-masing menggunakan UTF-8; ia berbeza sahaja di mana bait dibiarkan tanpa dikodkan.
Punycode dan pengekodan borang: standard adik-beradik, bukan sambungan pengekodan peratus
Perspektif bait menyelesaikan URL misteri. Mengapakah satu emoji memerlukan dua belas aksara? Kerana UTF-8 menggunakan empat bait, setiap satu menjadi %HH. Mengapakah sesetengah URL mempunyai %2F untuk garis miring manakala yang lain mempunyai garis miring biasa? Kerana mod pengekodan memutuskan: garis miring dalam segmen laluan kekal tidak dikodkan, tetapi dalam nilai pertanyaan ia mestilah %2F untuk mengelakkan salah baca.
Fikirkan dalam bait untuk pengekodan peratus yang boleh diramal. Watak ialah titik kod Unicode. UTF-8 ialah perwakilan baitnya. Pengekodan peratus ialah format penghantaran. Pengembangan aksara berlaku pada lapisan UTF-8. Kes hex tidak menjejaskan penyahkodan tetapi kes aksara menjejaskan. Urutan bait tidak sah gagal pada UTF-8 disebabkan oleh peraturan awalan yang ketat. Alat pengekod URL menunjukkan perkembangan ini.
Bawa pulang: fikir dalam bait — cara pengekod & penyahkod URL menunjukkan output %XX yang tepat untuk sebarang teks yang anda tampal, dalam pelayar
Contoh yang berfungsi: pengekodan "kafe 😀". Perkataan café mempunyai huruf c, a, f sebagai ASCII bait tunggal: 63, 61, 66. É ialah UTF-8 dua bait: C3 A9. Ruang adalah 20. Emoji 😀 ialah empat bait: F0 9F 98 80. Huruf ASCII tidak disimpan kekal kelihatan. Keputusan: "caf%C3%A9%20%F0%9F%9880". Ini menunjukkan sebab satu emoji berkembang kepada dua belas aksara.
Bawa pulang: fikir dalam bait, bukan aksara. Pengekodan peratusan digunakan selepas pengekodan UTF-8. Setiap bait menjadi %HH. Panjang boleh ubah UTF-8 bermaksud aksara berkembang secara berbeza: ASCII menjadi %XX (dua aksara), aksen dua bait menjadi %XX%XX (emoji enam bait), empat bait %XX%XX%XX%XX (dua belas aksara). Tampalkan teks ke dalam alat pengekod URL dan perhatikan perkembangannya.