URL Encoder / Decoder Gratis

Encode atau decode URL dan komponen URI secara instan.

Tidak ada data yang meninggalkan perangkat Anda

encodeURIComponent encodeURI

Masukan

Keluaran

Tentang URL Encoding

URL encoding (juga disebut percent-encoding) mengonversi karakter yang tidak diizinkan dalam URL menjadi format yang dapat dikirimkan dengan aman. Karakter khusus diganti dengan tanda persen (%) diikuti oleh dua digit heksadesimal yang mewakili nilai byte karakter.

Sejarah Singkat Aturan Encoding

Konvensi percent-encoding berasal dari RFC 1738 ("Uniform Resource Locators (URL)", Tim Berners-Lee, Larry Masinter dan Mark McCahill, Desember 1994), spesifikasi URL formal pertama yang diterbitkan oleh IETF. RFC 1738 mendefinisikan set karakter "reserved" asli (karakter dengan makna struktural di URL yang harus di-encode ketika digunakan sebagai data) dan set "unreserved" asli (karakter yang tidak pernah perlu di-encode). Spesifikasi direvisi secara substansial dalam RFC 2396 (Berners-Lee, Fielding, Masinter, Agustus 1998) dan lagi: secara definitif: dalam RFC 3986 ("Uniform Resource Identifier (URI): Generic Syntax", Berners-Lee, Fielding, Masinter, Januari 2005), yang masih merupakan spesifikasi URI formal hari ini. RFC 3986 memperluas set unreserved untuk menyertakan karakter tilde (~), memformalkan UTF-8 sebagai pengkodean untuk karakter non-ASCII di IRI, dan memperketat aturan tentang kapan karakter reserved harus di-percent-encode vs dibiarkan apa adanya. Untuk URI non-ASCII, RFC 3987 ("Internationalized Resource Identifiers", Duerst dan Suignard, Januari 2005) mendefinisikan ekstensi IRI yang memungkinkan URL berisi karakter Unicode asli, memetakan bentuk IRI ke bentuk URI standar melalui UTF-8 + percent-encoding. Untuk nama domain secara khusus, RFC 3492 mendefinisikan Punycode (Costello, Maret 2003), pengkodean yang digunakan untuk merepresentasikan label domain Unicode (xn--exmpla-...) dalam DNS, yang secara struktural mirip tetapi menggunakan algoritma yang berbeda. Spesifikasi URL de facto web modern adalah WHATWG URL Living Standard, diedit oleh Anne van Kesteren, yang mengkodekan perilaku aktual browser: kadang-kadang menyimpang dari RFC 3986 untuk kompatibilitas mundur dengan cara URL bekerja dalam praktik.

Reserved, Unreserved, dan Karakter yang Selalu Di-Encode

Spasi menjadi %20, ampersand menjadi %26, tanda sama dengan menjadi %3D, dan karakter non-ASCII seperti huruf beraksen atau emoji di-encode ke urutan byte UTF-8 mereka. Huruf, angka, dan karakter - _ . ~ tidak pernah di-encode (karakter tidak terpesan).

encodeURI vs encodeURIComponent: Kapan Menggunakan yang Mana

JavaScript mengirim dua encoder bawaan, keduanya distandarisasi di ECMAScript sejak 1999 (ES3). Pilihan di antaranya adalah keputusan URL-encoding tunggal yang paling umum dalam kode web, dan salah memilih menghasilkan bug halus yang lulus tes pada input sederhana tetapi rusak pada data pengguna nyata yang berisi ampersand, hash, atau garis miring.

encodeURIComponent: meng-encode semuanya kecuali set unreserved. Gunakan ini ketika Anda meng-encode satu potongan data yang akan disematkan ke URL: nilai parameter query, segmen path, pengidentifikasi fragmen, nilai field formulir. String hello world&more menjadi hello%20world%26more: ampersand di dalamnya di-encode, sehingga tidak diparsing sebagai pemisah parameter-query ketika URL kemudian dibaca. Ini adalah alat yang tepat untuk "saya memiliki input pengguna, saya ingin meletakkannya di URL dengan aman."
encodeURI: meng-encode hanya karakter yang ilegal di mana pun di URL. Itu sengaja meninggalkan karakter reserved (: / ? # [ ] @ ! $ & ' ( ) * + , ; =) utuh karena karakter tersebut mungkin melakukan pekerjaan struktural. Gunakan ini ketika Anda meng-encode seluruh URL yang telah dirakit dengan strukturnya sudah di tempat: URL yang berisi pemisah ? dan & miliknya sendiri, URL dengan karakter non-ASCII di path atau query yang perlu di-encode tanpa mengganggu tata bahasa URL. String https://example.com/search?q=hello world menjadi https://example.com/search?q=hello%20world: garis miring dan tanda tanya dipertahankan, hanya spasi yang di-encode.

Aturan mental: encodeURIComponent untuk data, encodeURI untuk URL. Gunakan yang salah dan Anda akan merusak struktur URL (encodeURIComponent pada seluruh URL meng-escape garis miring dan ampersand yang Anda butuhkan) atau gagal meng-escape input pengguna (encodeURI pada nilai query melepas ampersand dan data Anda diparsing sebagai beberapa parameter).

application/x-www-form-urlencoded: Pengkodean Lainnya

Ada pengkodean kedua yang terkait yang digunakan secara khusus untuk pengiriman formulir HTML: application/x-www-form-urlencoded. Itu terlihat hampir identik dengan percent-encoding URL kecuali untuk satu detail: spasi di-encode sebagai + daripada %20. Konvensi ini berasal dari spesifikasi formulir HTML asli dan dipertahankan di URL Living Standard untuk serializer application/x-www-form-urlencoded secara khusus. Decoder untuk data form-encoded harus membalikkan konvensi: + literal dalam data formulir di-encode sebagai %2B, dan + dalam string yang di-encode di-decode kembali ke spasi. API URLSearchParams JavaScript menangani konvensi ini secara otomatis; encodeURIComponent tidak: itu selalu meng-encode spasi sebagai %20. Untuk string query yang dirakit dengan tangan untuk action formulir HTML, gunakan URLSearchParams daripada memanggil encodeURIComponent pada setiap nilai secara individual.

Kapan Anda Sebenarnya Memerlukan Alat Ini

Men-debug panggilan API. Anda menekan endpoint REST dengan parameter query yang berisi spasi atau karakter khusus dan mendapatkan kembali kesalahan 400 atau hasil yang tidak terduga. Encode nilai parameter di sini, tempel hasilnya ke permintaan Anda, dan konfirmasi API memperlakukan input dengan benar.
Membangun URL yang dapat dibagikan dengan tangan. Membangun deep-link ke halaman hasil pencarian, tampilan yang difilter dari dashboard SaaS, atau formulir yang sudah diisi: di mana pun Anda perlu menyematkan kueri pencarian atau status pemilihan ke URL.
Mendekode URL yang ditangkap untuk membaca apa yang sebenarnya ada di dalamnya. URL yang dicatat berisi %E2%9C%93%20done: itu didekode menjadi apa? Tempel, tekan Decode, lihat ✓ done.
URL OAuth dan webhook. Parameter redirect_uri dalam alur OAuth harus di-percent-encode dengan tepat; salah memilih menghasilkan kesalahan "redirect_uri mismatch" yang opaque. URL webhook yang berisi parameter query dengan data pengguna memerlukan pengkodean yang hati-hati.
Nama file dengan karakter non-ASCII di link unduh. Tautan langsung ke file bernama café-menu.pdf memerlukan é di-percent-encode agar tautan berfungsi di semua browser dan alat shell.
String koneksi database. URL database PostgreSQL, MySQL, dan serupa (postgres://user:p@ssw0rd@host/db) memerlukan kata sandi di-percent-encode jika berisi @, :, / atau karakter reserved lain yang akan membingungkan parser URL.

Keamanan: Mengapa Pengkodean Penting Di Luar Estetika

Pengkodean URL yang salah adalah sumber kerentanan web yang sudah lama berdiri. HTTP response splitting mengeksploitasi jeda baris yang tidak di-encode (CR, LF: %0D%0A) dalam parameter URL yang dipantulkan ke header HTTP, memungkinkan penyerang menyuntikkan header sembarang atau bahkan respons lengkap. Open redirect mengeksploitasi penanganan URL naif yang tidak men-decode dan memvalidasi URL yang disediakan pengguna dengan benar sebelum mengarahkan ulang. Server-side request forgery (SSRF) dapat menyalahgunakan karakter yang di-encode untuk melewati allowlist URL: regex yang memblokir "http://internal" melewatkan "http://%69nternal" jika server men-decode setelah pemeriksaan regex. SQL injection melalui parameter URL bukan masalah URL-encoding per se tetapi diperburuk ketika tanda kutip tunggal dan meta-karakter SQL lainnya bertahan ke kueri database. Rekomendasi OWASP sejak awal 2000-an adalah: encode di batas saat masuk, decode di batas saat keluar, jangan pernah mencampur bentuk yang di-encode dan di-decode dalam buffer yang sama. Alat ini melakukan persis langkah encode/decode: apa yang Anda lakukan dengan hasilnya terserah Anda, dan tanggung jawab keamanan ada di lapisan aplikasi.

Pengkodean Ganda: Bug Paling Umum

Pengkodean ganda terjadi ketika string yang sudah di-encode di-encode lagi. Karakter spasi dalam URL yang sudah di-encode adalah %20; encode itu lagi dan Anda mendapatkan %2520 (karena % meng-encode menjadi %25). Ketika penerima men-decode sekali, mereka mendapatkan %20 kembali alih-alih spasi. Ketika mereka men-decode dua kali (dalam kasus langka di mana decode-ganda didukung), mereka mendapatkan spasi: tetapi sebagian besar parser tidak, dan URL secara diam-diam berisi %20 yang terlihat di address bar. Perbaikannya selalu: decode dulu jika Anda tidak tahu apakah input sudah di-encode, lalu encode tepat satu kali. Pola yang sama berlaku dalam kode: jangan pernah memanggil encodeURIComponent dua kali pada string yang sama. Jika Anda harus me-round-trip nilai, decode pengkodean sebelumnya sebelum re-encode untuk konteks baru. Tombol Swap alat ini membantu dengan siklus diagnostik: tempel URL yang dicurigai, klik Decode untuk melihat apa yang ada di dalamnya, klik Swap, klik Encode untuk mendapatkan bentuk yang di-encode kanonis kembali.

Privasi: Eksekusi Hanya-Browser

URL sering menyematkan data sensitif: token autentikasi dalam parameter query, pengidentifikasi pengguna dalam segmen path, kueri pencarian yang berisi konteks pribadi, nilai status OAuth, URL webhook yang menyertakan kunci API. Encoder URL sisi-server mengambil salinan setiap URL yang Anda tempel ke log mereka. Alat ini menggunakan fungsi bawaan JavaScript encodeURIComponent, encodeURI, decodeURIComponent, dan decodeURI yang berjalan secara lokal di tab browser Anda. Tidak ada langkah upload, tidak ada telemetri, tidak ada logging: verifikasi di tab Network DevTools saat Anda mengklik Encode (tidak ada permintaan yang dikirim), atau bawa halaman offline (mode pesawat) setelah dimuat dan encoder masih berfungsi. Aman untuk URL yang berisi token, kunci API, endpoint internal, atau URL apa pun yang tidak ingin Anda salin ke hard drive orang asing.

Pertanyaan yang Sering Diajukan

Kapan saya harus meng-URL-encode teks?

Anda harus meng-URL-encode teks setiap kali Anda menyertakan input pengguna dalam URL, misalnya, kueri pencarian dalam string kueri, nama file dalam path, atau data dalam parameter permintaan API. Tanpa encoding, karakter khusus dapat merusak struktur URL atau menimbulkan kerentanan keamanan.

Apa itu double encoding dan bagaimana cara menghindarinya?

Double encoding terjadi ketika teks yang sudah di-encode di-encode lagi, mengubah %20 menjadi %2520. Ini biasanya terjadi ketika kode meng-encode string yang sudah di-encode. Selalu decode terlebih dahulu jika Anda tidak yakin apakah teks sudah di-encode, lalu encode sekali.

Apakah alat ini aman untuk URL sensitif?

Ya. Alat ini berjalan sepenuhnya di browser Anda menggunakan fungsi encoding bawaan JavaScript. Tidak ada data yang dikirim ke server mana pun. Anda dapat memverifikasi ini dengan memutuskan koneksi dari internet, alat ini tetap akan berfungsi.

Mengapa data formulir saya memiliki tanda plus alih-alih %20?

Pengiriman formulir HTML menggunakan pengkodean terkait tetapi terpisah yang disebut application/x-www-form-urlencoded, yang meng-encode spasi sebagai + daripada %20 sebagai konvensi historis. Kedua bentuk valid dalam string query URL; parser modern menerima keduanya. API URLSearchParams JavaScript menggunakan konvensi form-encoded; encodeURIComponent selalu menggunakan %20. Jika data Anda perlu beroperasi bersama dengan kode penanganan formulir lama, gunakan URLSearchParams; jika menuju ke tempat lain, kedua bentuk berfungsi.

Bagaimana dengan karakter non-ASCII dan emoji?

Pengkodean URL modern menggunakan UTF-8: setiap karakter non-ASCII dikonversi ke representasi UTF-8 multi-byte-nya, kemudian setiap byte di-percent-encode. Tanda euro (€, tiga byte UTF-8) menjadi %E2%82%AC; emoji seperti roket 🚀 (empat byte) menjadi %F0%9F%9A%80. RFC 3987 (IRI) dan WHATWG URL Standard keduanya memformalkan konvensi UTF-8-pertama ini. Sistem yang lebih lama kadang-kadang menggunakan Latin-1 atau pengkodean lain; jika Anda men-decode URL kuno dan hasilnya terlihat kacau, sumbernya mungkin telah menggunakan pengkodean karakter yang berbeda sebelum percent-encoding.