Decode URL
Kembalikan %E2%9C%93 menjadi ✓. String yang ter-encode dua kali, encoding formulir, dan input yang setengah rusak tetap ditangani, bukan ditolak. Tidak ada yang disimpan.
- Tidak pernah disimpan
- Tanpa antre, tanpa menunggu
- Tanpa daftar, tanpa watermark
Hasil decode akan muncul di sini.
Cara kerjanya
Tempel teks yang ter-encode
URL utuh, query string, atau hanya satu nilai.
Pilih jenisnya bila perlu
Decoding standar, atau decoding formulir di mana + berarti spasi. Jika ragu, halaman ini menunjukkan saat keduanya memberi hasil berbeda.
Salin hasilnya
Decode lagi jika teksnya ter-encode dua kali — hal yang umum, dan mudah dikenali begitu Anda melihatnya.
Ambiguitas yang tidak bisa diselesaikan untuk Anda
Secara mekanis, decoding itu sederhana — cari setiap % yang diikuti dua digit heksadesimal, ubah kembali menjadi byte, lalu baca byte-byte itu sebagai UTF-8 — dan hanya ada satu ambiguitas yang sungguhan. Tanda plus bisa berarti spasi, bisa juga berarti plus. Pada formulir yang dikirim, artinya spasi, berdasarkan konvensi yang lebih tua daripada spesifikasi URL web itu sendiri. Pada segmen path, itu karakter literal. Tidak ada apa pun di dalam teks yang menyatakan mana yang berlaku, jadi halaman ini menampilkan kedua bacaan alih-alih memilih satu dan diam-diam keliru — hal yang paling penting justru pada kasus yang paling merugikan: alamat email atau nilai base64, di mana tanda plus adalah data sungguhan.
Teks non-ASCII muncul sebagai beberapa rangkaian persen per karakter, karena encoding bekerja pada byte UTF-8, bukan pada karakter: huruf beraksen menjadi dua, sebagian besar simbol tiga, emoji empat. Jika Anda men-decode rangkaian yang bukan UTF-8 valid, hasilnya karakter pengganti — biasanya tanda bahwa teks itu di-encode dari set karakter lain, atau terpotong di tengah sebuah karakter.
Decode dua kali adalah bug keamanan, bukan sekadar kekeliruan. Jika suatu nilai di-decode, diperiksa, lalu di-decode lagi, penyerang bisa menyembunyikan karakter dari pemeriksaan itu: %252e%252e%252f lolos dari filter yang mencari "../" karena setelah satu kali decode masih berupa %2e%2e%2f, dan setelah yang kedua menjadi traversal yang justru hendak dicegah filter itu. Decode tepat satu kali, lalu validasi, dan jangan pernah dengan urutan terbalik.
Teks yang tidak pernah di-encode dikembalikan apa adanya, bukan dirusak — perilaku yang berguna saat Anda tidak yakin apakah sebuah string perlu di-decode sama sekali. Tanda persen yang tidak diikuti dua digit heksadesimal dibiarkan, bukan dianggap error — itu tanda persen biasa, yang umum ada pada teks hasil tempel, bukan hasil encode.
Jika Anda butuh hal lain
Di dalam kode, decoder sebaiknya sesuai dengan encoder-nya. JavaScript punya decodeURIComponent; Python memisahkan unquote dari unquote_plus justru karena soal tanda plus ini; PHP punya rawurldecode dan urldecode dengan alasan yang sama. Lebih baik lagi, serahkan pada tipe URL atau parser query string — sebagian besar framework sudah men-decode parameter untuk Anda, dan men-decode lagi sesudahnya adalah cara bug decode ganda di atas tercipta.
Untuk memeriksa URL panjang alih-alih men-decode satu nilai, parser lebih unggul daripada decoder: python -c "import urllib.parse,sys; print(urllib.parse.urlparse(sys.argv[1]))" memecah alamat menjadi bagian-bagiannya sehingga Anda bisa melihat bagian mana yang mana sebelum men-decode apa pun — biasanya itulah pertanyaan sebenarnya saat sebuah link bermasalah.
Pertanyaan yang sering diajukan
Teks saya masih mengandung %25 setelah di-decode
Berarti teks itu ter-encode dua kali, dan ini sangat umum — terjadi setiap kali nilai yang sudah ter-encode di-encode lagi saat melewati redirect atau lapisan logging. %25 adalah hasil encode karakter % itu sendiri, jadi decode pertama mengubah %2520 menjadi %20, dan decode kedua mengubahnya menjadi spasi. Cukup decode lagi. Halaman ini memberi tahu Anda saat mendeteksi pola tersebut.
Apakah "+" harus menjadi spasi?
Tergantung dari mana string itu berasal, karena itulah ini berupa pilihan, bukan tebakan. Pada body application/x-www-form-urlencoded — formulir HTML yang dikirim — + berarti spasi. Pada segmen path, atau pada data yang sekadar lewat di URL, + adalah tanda plus literal, dan mengubahnya menjadi spasi merusak nilainya. String Base64 adalah kasus yang paling merugikan: string ini berisi karakter + sungguhan, dan decoding formulir akan menghancurkannya.
Bagaimana dengan string yang rusak?
Bagian yang bisa di-decode akan di-decode dan sisanya dibiarkan, alih-alih menolak semuanya. Tanda % nyasar yang bukan bagian dari escape valid — umum terjadi saat teks sudah sebagian di-decode, atau terpotong — membuat decoder bawaan browser melempar error dan tidak mengembalikan apa pun. Di sini, setiap escape yang valid di-decode dan karakter nyasar dibiarkan apa adanya, jauh lebih berguna saat Anda mencoba membaca baris log yang rusak.
Apakah teks saya disimpan di suatu tempat?
Tidak. Tidak ada yang disimpan dan tidak ada permintaan yang dikirim. Anda bisa memutus koneksi internet setelah halaman dimuat dan alat ini tetap berfungsi.
Bisakah saya men-decode URL utuh sekaligus?
Bisa. Tempel seluruhnya — strukturnya tetap terbaca dan hanya bagian yang ter-encode yang dikembalikan menjadi teks, sehingga URL panjang dengan beberapa parameter ter-encode menjadi sesuatu yang benar-benar bisa Anda baca.
Perlu diketahui: Tanda plus bersifat ambigu: di query string artinya spasi, sedangkan di path artinya tanda plus biasa. Halaman ini men-decode dengan kedua cara dan menunjukkan mana yang mana, bukan menebak. Teks yang memang tidak pernah di-encode dikembalikan apa adanya, bukan dirusak.
Pasang alat ini di situs Anda
Gratis untuk blog, halaman kelas, atau artikel bantuan apa pun. Tempel satu potong kode dan pengunjung Anda bisa langsung memakainya di halaman Anda.