URL CODEC

URL berjalan di atas protokol teks (HTTP) dan harus bisa ditulis dalam satu baris tanpa ambiguitas. Masalahnya: karakter yang ingin kamu kirim (spasi, kutip, simbol, huruf non-latin) bentrok dengan karakter yang punya arti struktural dalam URL itu sendiri.

Contoh konflik nyata: nilai pencarian linux & jaringan. Tanpa encoding, tanda & akan dianggap pemisah parameter - server mengira kamu mengirim dua parameter, bukan satu nilai yang mengandung &. Data rusak tanpa pesan error.

Solusinya percent-encoding yang distandarkan di RFC 3986 (URI) dan RFC 3987 (IRI): setiap karakter bermasalah diganti %XX - tanda persen diikuti dua digit heksadesimal yang mewakili byte datanya.

Aturan dasar yang harus melekat:

• Hanya karakter aman (unreserved) yang boleh muncul literal: huruf, angka, dan - _ . ~
• Segala selain itu wajib disandikan - tanpa pengecualian
• Encoding dilakukan pada VALUE, bukan pada STRUKTUR - tanda ? & = yang memisahkan parameter justru harus tetap telanjang

Karena itu ada dua varian fungsi (dibahas M04): satu untuk menyandikan potongan data, satu untuk menyandikan URL utuh sambil membiarkan strukturnya hidup. Salah pilih = URL rusak atau data bocor maknanya.

Sebelum bisa mengencode dengan benar, kamu harus tahu di bagian mana data berada. Anatomi lengkap:

Contoh utuh yang dibedah di menu ANALISIS tool ini: https://abdurrozak.my.id:443/cari?q=linux%20tkj&page=2#hasil

Aturan encoding per bagian:

• PATH - / memisahkan folder dan harus tetap telanjang; spasi dan karakter aneh dalam nama file disandikan (%20)
• QUERY - ? memulai, & memisahkan parameter, = memisahkan key dan value; ketiganya struktural, ISI key/value wajib disandikan
• FRAGMENT - diproses browser secara lokal; server tidak pernah menerimanya (mengapa penting: di M07)

Latih matamu: buka menu ANALISIS, tempel URL apa pun dari browser, dan pastikan setiap segmen terbaca benar sebelum lanjut ke modul berikutnya.

RFC 3986 membagi karakter menjadi tiga kubu:

1. UNRESERVED - bebas dipakai tanpa makna khusus: A-Z a-z 0-9 - _ . ~ plus (hanya di praktik JavaScript) ! * ' ( ). Karakter ini tidak pernah perlu disandikan.

2. RESERVED (gen-delims) - tulang punggung struktur URL:

3. RESERVED (sub-delims) - punya makna di komponen tertentu: ! $ & ' ( ) * + , ; = - yang paling penting: & (pemisah parameter) dan = (pemisah key-value).

Karakter yang selalu disandikan (tidak pernah sah literal di URL): spasi, kutip ganda, < >, kurung kurawal { }, garis |, backslash, tanda ^, backtick, dan % itu sendiri.

% adalah karakter paling spesial - ia adalah karakter escape. Karena itu, literal % dalam data harus disandikan menjadi %25. Inilah akar dari fenomena double-encoding: %2520 dibaca "persen-dua-lima-dua-nol" yang saat di-decode menjadi %20 - masih ter-encode sekali lagi.

Hex wajib hafal (muncul terus di log): %20 spasi, %3F ?, %26 &, %3D =, %25 %, %2F /, %3A :, %23 #, %2B +, %27 '. Peta interaktif lengkapnya ada di menu PETA KARAKTER.

Salah satu sumber kebingungan terbesar: "kok hasil encode-ku beda dengan punya temanku?" Jawabannya hampir selalu: kalian memakai rasa yang berbeda. Ada tiga:

Kapan component, kapan URI: mengencode https://x.com/cari dengan encodeURIComponent menghasilkan https%3A%2F%2Fx.com%2Fcari - struktur hancur. Itu BENAR jika string itu adalah VALUE dari parameter redirect, dan SALAH jika ingin menautkan langsung. Maka: component untuk isi, URI untuk sampul.

Rasa form: spasi menjadi + alih-alih %20, dan aturan karakter yang disandikan sedikit berbeda (mis. ! dan * ikut disandikan di beberapa implementasi). Format inilah yang dipakai tag <form> HTML default dan banyak framework lama. Karena itu tool ini menyediakan sakelar "FORMAT FORM" di sisi encode dan "+ SEBAGAI SPASI" di sisi decode.

Kesalahan klasik yang wajib dikenali: meng-encode URL utuh dengan encodeURIComponent lalu heran hasilnya penuh %3A %2F. Sekarang kamu tahu: itu bukan bug - itu salah rasa.

Uji pemahamanmu di menu TOOL: masukkan URL lengkap, bandingkan hasil kedua mode encode berdampingan.

Percent-encoding bekerja pada byte, bukan huruf. Untuk karakter ASCII (0-127) satu byte = satu huruf, sederhana. Tapi dunia tidak berbahasa ASCII - dan standar modern menetapkan UTF-8 sebagai encoding karakternya.

UTF-8 memakai 1-4 byte per karakter:

Contoh yang bisa langsung dicoba di menu TOOL (tombol contoh UNICODE): suhu=30 derajat dengan karakter derajat menghasilkan suhu%3D30%C2%B0. Satu huruf kecil = dua sequence. Inilah kenapa teks bahasa Indonesia dengan sedikit simbol asing bisa membengkak 2-3x panjangnya.

Implikasi praktis untuk teknisi jaringan:

• URL maksimal server (biasanya sekitar 2-8 KB) terkuras cepat oleh teks non-latin - perencanaan query panjang harus menghitung byte, bukan huruf
• Log akses yang penuh %E2%89%A0 bukan kerusakan - itu karakter 3-byte yang sah
• Menampilkan hasil decode butuh renderer UTF-8 (browser modern otomatis; terminal lama perlu set locale)

Catatan IDN: domain beraksara non-latin (contoh domain .id berbahasa daerah) memakai mekanisme terpisah bernama punycode - tampil sebagai xn--... di kawat. Itu bukan percent-encoding; jangan dicampur.

Di HTTP, URL encoding muncul di tiga tempat yang wajib kamu kenali sebagai teknisi jaringan:

1. Query string GET - data menempel di URL: GET /cari?q=linux%20tkj&page=2 HTTP/1.1. Terlihat di address bar, tersimpan di history, cache, dan log server.

2. Body form POST - Content-Type: application/x-www-form-urlencoded. Formatnya saudara kembar query string (key=value&key=value) tapi dikirim di body, tidak tercatat di URL.

3. Log akses server - format combined log yang akan kamu temui tiap hari:

192.168.1.5 - - [10/Jan/2025:10:00:00] "GET /cari?q=linux%20tkj%26p%3D2 HTTP/1.1" 200 512 "-" "Mozilla/5.0"

Bedah nilai query-nya dengan mata teknisi: q=linux%20tkj%26p%3D2 di-decode menjadi q=linux tkj&p=2. Perhatikan: TANPA encoding, & di tengah nilai akan memecah parameter - server akan mengira ada parameter kedua p=2. Klien yang rajin mengencode menyelamatkan integritas datanya. Coba baris log itu sendiri di menu TOOL mode DECODE - hasilnya URL yang sudah terbaca manusia.

Alur analisis log yang disarankan: salin bagian request -> decode -> bedah query di menu ANALISIS -> identifikasi parameter dan nilai aslinya. Tiga langkah, nol tools berbayar.

Kenapa spasi di log kadang tampak + dan kadang %20? Tergantung klien: form klasik mengirim +, browser modern dan library RFC-3986 mengirim %20. Keduanya bermakna spasi - dan tool ini menangani keduanya lewat sakelar decode.

URL encoding adalah pedang bermata dua: kebutuhan teknis yang sah, sekaligus selubung favorit penyerang. Seorang teknisi TKJ harus mengenali keduanya.

Pola yang wajib dikenali di log:

Double encoding - teknik menyembunyikan payload: penyerang mengencode dua kali, misal ' menjadi %27 lalu %2527. Filter keamanan naif yang hanya mendecode satu kali akan melihat %2527 sebagai teks tak berbahaya; aplikasi yang mendecode lagi akan mengeksekusi '. Karena itu WAF dan IDS profesional mendecode berulang sebelum mencocokkan aturan.

Sisi bertahan - apa yang kamu lakukan:

• Gunakan menu TOOL ini sebagai decoder forensik: baris log mencurigakan -> decode -> bedah query -> evaluasi
• Waspadai frekuensi: satu %27 bisa jadi kecelakaan; seratus per jam dari satu IP adalah kampanye
• Pahami bahwa fragment (#...) TIDAK sampai ke server - payload di fragment hanya terlihat di sisi browser, tapi tetap berbahaya bagi pengguna

Sisi membangun - kebiasaan yang benar: encode di titik KELUAR (saat menempelkan data ke URL), jangan menyimpan data dalam bentuk ter-encode; jangan pernah menaruh password/token di query string (mengapa: M08 dan FAQ); dan saat menampilkan hasil decode ke halaman web, lakukan HTML-escape - decode URL lalu menampah tanpa escape adalah resep XSS pada aplikasimu sendiri.

Empat alur kerja nyata yang memakai tool ini dari awal sampai akhir - latih sampai hafal:

ALUR 1 - MEMBACA LOG AKSES

• Salin request dari access.log (atau dari materi M06)
• Mode DECODE -> hasil terbaca manusia
• Salin query-nya ke menu ANALISIS -> parameter terurai jadi tabel

ALUR 2 - MEMBANGUN URL API / WEBHOOK

• Tulis parameter di mode ENCODE COMPONENT (value satu per satu)
• Rakit manual: key=%3Dencoded&... - jangan pernah menempel data mentah berisi & atau spasi
• Verifikasi: tempel URL jadi di menu ANALISIS - jumlah parameter harus sesuai rencana

ALUR 3 - DEBUG FORM YANG "KACAU"

• Gejala: nilai parameter terpotong di server
• Periksa: adakah & atau = di dalam value yang tidak di-encode? (pemicu klasik)
• Enkode value dengan COMPONENT, kirim ulang, bandingkan

ALUR 4 - AUDIT DOUBLE ENCODING

• Decode satu kali -> jika hasil masih memuat %XX yang sah -> peringatan double muncul di tool
• Tukar (tombol TUKAR) -> decode lagi -> bandingkan
• Di aplikasi nyata: ini sinyal ada dua lapis encode di pipeline (klien dan framework sama-sama mengencode)

Pola mentalnya: DECODE UNTUK MEMBACA, ENCODE UNTUK MENGIRIM, ANALISIS UNTUK MEMBUTIKAN. Tiga kata itu sudah mencakup 90% pekerjaan nyata seputar URL.

Karena ada dua standar yang hidup berdampingan. RFC 3986 (URL murni) menyatakan spasi = %20. Standar form HTML (application/x-www-form-urlencoded) menyatakan spasi = +. Browser memakai + saat mengirim form klasik, dan %20 saat URL diketik/dibangun manual. Keduanya sah di konteksnya masing-masing - tool ini punya sakelar untuk keduanya agar kamu bisa membandingkan langsung.

decodeURIComponent standar langsung menyerah jika menemukan % yang tidak diikuti tepat dua digit hex (contoh: teks "disk 100% penuh" - % p-nya bukan sequence sah). Tool ini memakai mode lenient: sequence sah didekode, yang rusak dibiarkan apa adanya, dan kamu diberi peringatan berapa yang bermasalah. Itu sebabnya hasil tool ini tetap muncul ketika decoder online lain menampilkan error.

Double encoding = teks di-encode dua kali: spasi menjadi %20 lalu %20-nya menjadi %2520. Gejalanya: setelah sekali decode hasil masih memuat sequence %XX yang sah (%2520 -> %20). Penyebab umum: dua lapis kode sama-sama meng-encode (klien dan framework), atau data pernah disimpan dalam bentuk ter-encode lalu di-encode lagi. Tool ini mendeteksinya otomatis dan menyarankan decode lanjutan lewat tombol TUKAR.

Tidak. Fragment (bagian setelah #) hanya diproses browser untuk melompat ke bagian halaman atau untuk kebutuhan aplikasi single-page. Server tidak pernah menerimanya - tidak masuk log akses. Konsekuensi praktis: jangan mengandalkan fragment untuk data yang perlu dicatat server; sebaliknya, payload di fragment luput dari log - penting dipahami saat audit.

Standar HTTP tidak menetapkan batas keras, tapi realitanya berlapis: browser umumnya sekitar 2 KB - 64 KB (Chrome ~2 MB untuk address bar, namun kompatibilitas tetap masalah), server web umumnya 8 KB default header. Untuk aman: jaga URL di bawah sekitar 2000 karakter, dan hitung dengan BYTE bukan huruf - teks beraksara non-latin mengembang 2-4x (lihat M05). Data besar? Pindah ke POST.

Dua kemungkinan: 1) double encoding - decode sekali lagi (jawaban Q3); 2) memang itu datanya - contoh: artikel yang membahas URL encoding sengaja memuat tulisan "%20" sebagai teks, yang tersimpan sebagai %2520. Tool ini membantu membedakan: sequence yang sah diberi peringatan double-encoding; yang tidak sah diberi peringatan malformed.

Itu punycode - representasi ASCII untuk Internationalized Domain Name (domain beraksara non-latin, misal aksara daerah Indonesia). Browser mengubahnya bolak-balik secara otomatis. Penting: punycode BUKAN percent-encoding - mekanisme, standar, dan tempat penerapannya (hostname, bukan path/query) berbeda. Jangan mencoba meng-decode xn-- dengan tool percent-encoding.

Dua dunia yang sering tertukar. URL encoding (%XX) melindungi STRUKTUR URL - dipakai saat membangun/mengirim URL. HTML escape (&amp; &lt; &gt; &quot;) melindungi STRUKTUR DOKUMEN HTML - dipakai saat MENAMPILKAN teks di halaman web. Kesalahan berbahaya: menampilkan hasil decode URL ke halaman tanpa HTML escape = lubang XSS. Urutan benar: decode URL untuk membaca, lalu HTML-escape saat menampilkan.

Karena query string bocor ke banyak tempat sekaligus: log akses server dan proxy, riwayat browser, cache, header Referer yang dikirim ke situs pihak ketiga, dan tangkapan layar orang lain. POST menyimpan data di body yang tidak tercatat di jalur-jalur itu. Aturan praktis: query string untuk data yang tidak sensitif dan boleh dibagikan (halaman, filter, kata kunci); kredensial via POST + HTTPS, atau header khusus.

Lima situasi harian: 1) membaca request aneh di access.log; 2) merakit URL API/webhook tanpa merusak parameter; 3) debugging form yang nilainya terpotong (cek & dan = yang lolos); 4) audit keamanan permintaan mencurigakan (pola di M07); 5) menjelaskan ke user/krsayaan kenapa tautan yang mereka buat rusak - dengan bukti sebelum-sesudah dari tool ini. Semuanya offline: data sensitif tidak pernah meninggalkan browser.