Decoder ng URL

Ang Decoder ng URL ay isang libreng tool na nagbabalik sa percent-encoded na teksto ng URL sa orihinal nitong anyo.

Ano ang ginagawa ng pag-decode ng URL?

Binabaligtad ng pag-decode ng URL ang escaping na ginagamit upang maipasa sa mga URL at iba pang itinakdang syntax ang mga espasyo, bantas, at iba pang byte sa pamamagitan ng percent-encoding. Sa percent-encoding, kinakatawan ang isang byte ng percent sign na sinusundan ng dalawang hexadecimal digit. Ginagamit din sa form-style URL encoding ang + bilang espasyo. Halimbawa, maaaring isulat ang espasyo bilang %20 at ang ampersand bilang %26.

Narito ang isang maikling halimbawa bago at pagkatapos i-decode:

Encoded na input: red%20%26%20blue

Na-decode na output: red & blue

Kailangan ang encoding na ito dahil may mga character na may estruktural na kahulugan sa URL. Tinutukoy ng question mark ang simula ng query ng URL, habang sa form-style query data, karaniwang naghihiwalay ng mga field ang literal na ampersand. Kapag in-encode ang mga character na iyon, maipapasa sila ng application bilang data sa halip.

Hindi encryption ang URL encoding at wala itong ibinibigay na pagiging lihim. Maaaring i-decode ng sinumang nakakabasa sa encoded na value ang laman nito. Huwag ituring na protektadong data ang mga password, access token, o personal na impormasyong naka-percent-encode.

Paano gamitin ang Decoder ng URL?

I-paste o ilagay ang encoded na teksto, iproseso ito, at basahin ang naibalik na value sa field ng resultang URL decoded. Ginagamit ng tool ang urldecode function ng PHP, kaya kino-convert nito ang mga valid na %HH sequence at itinuturing ang plus sign bilang espasyo.

1. Kopyahin ang encoded na bahagi, gaya ng value ng isang query parameter.
2. Ilagay ang URL-encoded na value nang hindi nagdaragdag ng mga panipi, maliban kung talagang bahagi ng value ang mga iyon.
3. Iproseso ang input na URL at suriin ang resultang URL decoded.
4. Kung may mga sequence pa ring gaya ng %2F o %20 sa output, alamin kung na-encode nang higit sa isang beses ang source bago ito muling i-decode.

Sa server ginagawa ang pagproseso. Ipinapadala ang input mo sa server sa pamamagitan ng HTTPS at hindi ito iniimbak, pero umaalis ito sa device mo habang pinoproseso. Iwasang mag-paste ng mga lihim sa Decoder ng URL na ito maliban kung angkop sa data ang pagproseso sa server.

Saan ginagamit ang URL encoding?

Pinakakaraniwang makikita ang URL encoding sa mga query string, pagsusumite ng form, at mga value na nakapaloob sa mga link. Ginagamit din ito sa ilang hindi gaanong halatang sitwasyon kung saan kailangang dumaan ang data sa isang limitadong textual format.

• Mga query string: maaaring lumabas bilang q=tea+%26+cake ang paghahanap sa "tea & cake".
• Mga data URI: maaaring i-percent-encode ang textual data pagkatapos ng media type, bagaman isa ring karaniwang representasyon ang Base64.
• Mga link sa email: maaaring i-encode ng isang mailto link ang mga espasyo, line break, at bantas sa mga parameter ng subject o body nito. Hiwalay na mga format ang MIME transfer encoding na ginagamit sa loob ng mensaheng email.
• Mga JSON payload: may sariling mga panuntunan sa escaping ang JSON, pero maaaring maglaman ang isang JSON string ng naka-encode nang URL o query value na kailangang i-decode nang hiwalay.
• Mga internationalised domain: karaniwang Punycode, hindi percent-encoding, ang ginagamit ng mga non-ASCII na domain label. Maaari pa ring maglaman ang mga bahagi ng path at query ng mga percent-encoded na UTF-8 byte.

Kung isang domain label na nagsisimula sa xn-- ang encoded na teksto, gamitin ang IDN Punycode konwerter. Para sa mga percent-encoded na bahagi ng URL ang Decoder ng URL, hindi para sa pag-convert ng Punycode.

Mga halimbawa ng pag-decode ng URL

Ipinapakita ng mga sumusunod na halimbawa ang mga karaniwang input at ang katumbas na na-decode na teksto.

• Ang hello%20world ay nagiging hello world.
• Ang name=Tom+Jones ay nagiging name=Tom Jones.
• Ang fish%26chips ay nagiging fish&chips.
• Ang %C2%A3 ay nagiging £ kapag kumakatawan sa UTF-8 na teksto ang mga byte.
• Ang %E6%9D%B1%E4%BA%AC ay nagiging 東京 kapag binasa bilang UTF-8.
• Ang 100%25 ay nagiging 100%.

Karaniwang nananatiling gaya ng inilagay ang mga simpleng letra, numero, at hindi naka-encode na bantas. Kapag walang laman ang input, wala ring laman ang resultang URL decoded. Pareho pa rin ang mga panuntunan sa pag-decode para sa napakahabang input, bagaman maaaring magtakda ang mga browser, server, at tumatanggap na system ng sarili nilang limitasyon sa haba ng request o URL.

Karaniwang ini-encode ang mga character na may accent at mga character na hindi Latin bilang sunod-sunod na UTF-8 byte, at hiwalay na isinusulat ang bawat byte. Kung ibang character encoding ang ginamit ng orihinal na system, maaaring lumabas ang mga na-decode na byte bilang mga pamalit na simbolo o tekstong mukhang walang kahulugan.

Bakit pumapalya ang pag-decode ng URL o naglalabas ng magulong teksto?

Maaaring hindi magbago o maging hindi inaasahan ang output kapag may hindi kumpletong percent sequence ang input, na-encode ito nang higit sa isang beses, binasa ito gamit ang maling character set, o hindi naman talaga ito URL-encoded na data. Hindi binabago ng urldecode ng PHP ang mga malformed na percent sequence, habang intermediate na resulta lang ang nalilikha pagkatapos ng isang pass sa double-encoded na input. Suriin ang orihinal na source bago paulit-ulit na mag-decode.

• Double-encoded na input: sa unang pag-decode, nagiging %20 ang %2520 at magiging espasyo lamang ito pagkatapos ng ikalawang decoding pass. Mag-decode ulit kapag alam mong may isa pang layer ng encoding.
• Hindi kumpletong percent sequence: kailangan ng bawat encoded na byte ang dalawang hexadecimal digit. Malformed ang % na nasa dulo o ang value na gaya ng %2 at hindi ito maaaring kumatawan sa isang kumpletong encoded na byte, kaya hindi ito binabago ng urldecode ng PHP.
• Maling character encoding: ibinabalik ng percent-decoding ang mga byte. Halimbawa, kapag binasa bilang UTF-8 ang mga ISO-8859-1 byte, maaaring lumabas ang magulong teksto kahit valid ang mga percent sequence.
• Binary data sa halip na teksto: maaaring kumatawan ang mga na-decode na byte sa larawan, compressed file, o iba pang binary content. Hindi inaasahang lalabas ang ganitong output bilang nababasang teksto.
• Maling uri ng encoding: kung ipapasa pagkatapos sa Base64 decoder ang resultang na-decode mula sa URL, maaaring pumalya ang decoder na iyon dahil sa standard na alphabet kumpara sa URL-safe na alphabet, nawawalang = padding, o sirang input. Walang padding ang URL percent-encoding at hindi ito gumagamit ng Base64 alphabet. Hindi rin vina-validate o inaayos ng pag-decode ng URL ang mga problemang iyon sa Base64.

Mag-ingat sa mga literal na plus sign. Sa form-style URL encoding, nangangahulugang espasyo ang +. Karaniwang dapat i-encode bilang %2B ang tunay na plus sign bago i-decode.

Mga madalas itanong

Buong URL ba ang dapat kong i-decode o isang bahagi lang?

Kung maaari, i-decode lamang ang indibidwal na path segment o ang value ng query parameter. Kapag na-decode ang buong URL, maaaring maging mga separator ang mga encoded na reserved character gaya ng %26, %3F, o %2F at mabago kung paano binabasa ang URL.

Kayang i-decode ang mga lowercase na hexadecimal code?

Oo. Hindi mahalaga ang laki ng titik sa mga hexadecimal digit sa percent sequence, kaya parehong kumakatawan ang %2f at %2F sa iisang byte. Valid din ang mga sequence na magkahalo ang uppercase at lowercase.

Paulit-ulit bang ide-decode ng tool ang parehong value?

Hindi. Isang decoding pass lang ang ginagawa ng bawat pagtawag sa urldecode. Kung maging %2F ang %252F, kailangan ng isa pang pass para maging slash ito. Pero maaaring mabago ng paulit-ulit na pag-decode ang data na sadyang naglalaman ng literal na percent sequence.

Kaya bang ayusin ng pag-decode ng URL ang sirang teksto?

Hindi. Maibabalik nito ang valid na percent-encoding, pero hindi nito mabubuo muli ang mga nawawalang hexadecimal digit o matutukoy nang may katiyakan ang orihinal na character set. Suriin ang source system, mga HTTP header, o dokumentasyon kapag hindi maayos na lumalabas ang mga na-decode na byte.

Ano ang gagawin ko sa value na nagsisimula sa xn--?

Ituring ito bilang isang Punycode domain label, hindi bilang karaniwang percent-encoded na teksto. Gamitin ang IDN Punycode konwerter, pagkatapos ay maingat na beripikahin ang resultang domain dahil maaaring magmula sa magkaibang script ang mga Unicode character na magkamukha.