Encoder / Decoder URL
Encode teks secara persen untuk URL dan query string, atau decode URL yang sudah di-encode. Beralih antara encodeURIComponent untuk nilai tunggal dan
Lakukan percent-encode pada teks agar bisa berpindah dengan aman di dalam URL, atau decode tautan yang Anda salin dari log atau email. Nilai seperti spasi, ampersand, tanda tanya, dan karakter non-Latin harus di-escape sebelum masuk ke query string, dan alat ini menunjukkan dengan tepat bagaimana bentuk ter-encode-nya.
Ada dua mode yang penting: meng-encode satu nilai (kata kunci pencarian, alamat email, token) meng-escape setiap karakter yang dicadangkan, sedangkan meng-encode tautan lengkap membiarkan karakter strukturalnya - garis miring, tanda tanya, ampersand - tetap utuh. Memilih mode yang salah adalah penyebab klasik pengalihan (redirect) yang rusak, jadi modenya bisa dipilih.
Cara meng-encode dan men-decode URL
Tempelkan teks atau URL
Pilih mode nilai atau mode tautan lengkap
Salin hasil yang sudah di-encode atau di-decode
FAQ
Apa perbedaan kedua mode itu?
Mode nilai meng-escape karakter yang dicadangkan seperti & = ? / #, dan itulah yang Anda butuhkan di dalam parameter query. Mode tautan lengkap mempertahankan karakter tersebut agar URL utuh tetap bisa dipakai.
Mengapa spasi menjadi %20 atau +?
%20 adalah percent encoding standar. Tanda plus adalah konvensi warisan dari pengiriman formulir HTML dan hanya setara di dalam query string, bukan di dalam path.
Bisakah alat ini men-decode sekaligus meng-encode?
Bisa, proses decode bekerja dua arah dan menampilkan karakter aslinya, termasuk teks beraksen dan teks CJK.
Mengapa proses decode gagal pada string saya?
Tanda % yang tidak diikuti dua digit heksadesimal tidak valid dan tidak bisa di-decode. Periksa apakah ada nilai yang terpotong atau tanda persen yang dimaksudkan sebagai karakter biasa.
Apakah alat ini menangani karakter non-Latin?
Ya, teksnya dikodekan sebagai UTF-8 terlebih dahulu lalu di-percent-encode, dan itulah bentuk yang diharapkan browser serta server.
Apakah masukan saya diunggah?
Tidak, proses encode dan decode adalah operasi teks murni di browser Anda.
Sekilas
| Masukan | teks |
|---|---|
| Beberapa file | Tidak |
| Dijalankan di | Di browser Anda - file tidak pernah diunggah |
| Bekerja offline | Ya — setelah halaman dimuat |
| Harga | Gratis, tanpa pendaftaran, tanpa tanda air |
Memilih format data
JSON adalah pilihan default untuk apa pun yang dikembalikan sebuah API atau dibaca sebuah program: format ini secara alami menangani struktur bersarang, angka, boolean, dan null, dan setiap bahasa bisa mengurainya. CSV lebih kecil dan langsung terbuka di spreadsheet, tetapi tidak punya cara untuk menyatakan penyarangan dan tidak punya standar bersama untuk pemisah, tanda kutip, atau set karakternya - dan di situlah konversi biasanya salah. XML lebih bertele-tele, tetapi membawa atribut, konten campuran, dan skema, sehingga masih mendominasi format dokumen dan integrasi warisan. YAML paling mudah dibaca untuk konfigurasi, tetapi peka terhadap spasi dan punya pemaksaan tipe yang mengejutkan ("no" menjadi false, versi seperti 1.10 menjadi 1.1). Pilih format yang disukai alat yang akan memakainya, bukan format yang terlihat paling bagus.
Di mana konversi diam-diam rusak
Sebagian besar bug konversi bukan soal sintaksis, melainkan soal makna. Kolom kode pos pada CSV kehilangan angka nol di depannya begitu spreadsheet menduga kolom itu berisi angka; ID yang panjang melampaui presisi floating-point; tanggal berubah makna tergantung apakah formatnya tanggal-dulu atau bulan-dulu. Kunci JSON tidak berurutan, sedangkan array berurutan, dan alat yang mengurutkan kunci tidak mengubah apa pun sementara alat yang mengurutkan array mengubah datanya. Unicode adalah jebakan lain: teks bisa datang sebagai UTF-8, UTF-16, atau dengan BOM, dan dekoder yang salah menebak mengubah karakter beraksen menjadi mojibake. Sebelum memercayai konversi apa pun, periksa sekilas baris pertama dan terakhir, setiap bidang yang memiliki angka nol di depan, dan setiap bidang yang memuat tanda kutip, koma, atau baris baru.