URL encoder

Ang URL encoder ay isang libreng tool na nagko-convert ng string sa form-encoded na anyong ginagamit sa mga query parameter ng URL at iba pang text-based na data sa web.

Ano ang URL encoding at bakit ito ginagamit?

Pinapalitan ng URL encoding ang mga character na may espesyal na kahulugan sa URL ng percent sign na sinusundan ng mga hexadecimal digit. Dahil dito, maaaring maipasa ang text sa mga system na tumatanggap lamang ng limitadong hanay ng mga character.

Halimbawa, pinaghihiwalay ng ampersand ang mga query parameter. Kaya kung bahagi ng value ang ampersand, dapat itong i-encode bilang %26. Kailangan ding espesyal na pangasiwaan ang mga espasyo. Ginagamit ng tool na ito ang urlencode function ng PHP, na nagko-convert ng espasyo sa plus sign.

Bago: tea and cake

Pagkatapos: tea+and+cake

Karaniwang makikita ang URL-encoded na text sa:

• mga query string na isinusumite ng mga web form;
• mga data URI na naglalaman ng text na hindi maaaring direktang ilagay;
• mga link na kasama sa mga mensaheng email;
• mga URL value na naka-store sa mga JSON payload;
• mga redirect at callback parameter na ginagamit ng mga web application;
• mga URL na nauugnay sa mga internationalised domain, bagaman maaaring Punycode at hindi percent encoding ang kailangan para sa mismong domain name.

Hindi encryption ang URL encoding at wala itong ibinibigay na pagiging lihim. Maaaring i-decode ng sinumang nakakakita sa isang percent-encoded na URL value ang nilalaman nito.

Paano gamitin ang URL encoder?

Ilagay ang string na kailangang i-encode, patakbuhin ang tool, at tingnan ang na-convert na value sa result field na URL encoded. Ang mismong value lang ang i-encode, hindi ang mga quotation mark sa paligid nito o ang paliwanag na text.

Sa server isinasagawa ang proseso. Ipinapadala sa server ang input mo sa pamamagitan ng HTTPS at hindi ito sini-store. Gayunman, huwag maglagay ng mga password, session token, o pribadong personal na data sa mga URL dahil maaaring lumabas ang mga web address sa browser history, analytics system, at server log.

Para baligtarin ang proseso, gamitin ang Decoder ng URL. Dapat tumugma ang wastong na-decode na value sa orihinal na text, basta pareho ang character encoding at mga panuntunan sa form encoding na ginamit sa pag-encode at pag-decode.

Buong URL ba o parameter value lang ang dapat i-encode?

Karaniwan, bawat parameter value lang ang dapat i-encode, hindi ang buong URL. Kapag buong address ang in-encode, mapapalitan din ang mga structural character gaya ng colon, forward slash, question mark, at equals sign.

Halimbawa, ang search value ay green tea & coffee. Ang encoded na anyo nito ay green+tea+%26+coffee, na maaaring ilagay pagkatapos ng pangalan ng parameter. Kung buong address ang i-encode, hindi na madaling makikilala ng browser ang mga separator para sa scheme, host, path, at query string nito.

Ang paggamit ng tool na ito sa urlencode ay angkop para sa mga query parameter na sumusunod sa estilo ng HTML form. Sa halip, sinusunod ng ilang API at path segment ang mga convention ng RFC 3986, kung saan isinusulat ang espasyo bilang %20 sa halip na +. Alamin kung inaasahan ng tatanggap na system ang form encoding na gumagamit ng + o ang estilong RFC 3986 na gumagamit ng %20.

Mga halimbawa ng URL encoding

Nananatiling nababasa ang mga ASCII letter at digit. Nagiging plus sign ang mga espasyo, habang ang reserved punctuation at non-ASCII na text ay kinakatawan ng mga encoded byte.

• Ang hello world ay nagiging hello+world.
• Ang tea & cake ay nagiging tea+%26+cake.
• Ang email=test@example.com ay nagiging email%3Dtest%40example.com.
• Ang 100% ready ay nagiging 100%25+ready.
• Ang café ay nagiging caf%C3%A9 kapag UTF-8 ang gamit ng source text.

Ang mga letrang may accent at mga character mula sa non-Latin na script ay kinakatawan muna bilang mga byte gamit ang character encoding, na karaniwang UTF-8 sa web. Pagkatapos, bawat byte na wala sa pinapayagang hanay ay binibigyan ng sarili nitong percent escape. Dahil dito, maaaring makabuo ang isang nakikitang character ng ilang pangkat na nagsisimula sa %.

Hindi kailangan ng espesyal na pagproseso ang mga numero. Walang lalabas na encoded na content kapag walang laman ang input. Maaaring lumaki nang malaki ang napakahabang input dahil tatlong character ang ginagamit ng bawat encoded byte.

Bakit pumapalya o nagiging magulong text ang URL decoding?

Karaniwang pumapalya ang decoding dahil ibang mga panuntunan ang ginamit sa pag-encode ng input, mahigit isang beses itong na-encode, o hindi nito kinakatawan ang text sa inaasahang character set.

• Magkaibang pagproseso sa espasyo. Itinuturing ng form decoder na espasyo ang +, samantalang maaaring iwan ito ng mahigpit na percent decoder bilang plus sign.
• Dobleng encoding. Maaari ring maging %25 ang percent sign sa %26, kaya nagiging %2526 ang resulta. Sa isang beses na pag-decode, %26 ang ibabalik sa halip na ang orihinal na ampersand.
• Maling character encoding. Kapag ang mga UTF-8 byte ay na-decode bilang ibang character set, maaaring lumabas ang mga replacement symbol o magulong letra.
• Binary data sa halip na text. Maaaring image, archive, o ibang file ang mga na-decode na byte, kaya magulong text ang lalabas kapag ipinakita ang mga ito bilang text.
• Maling format o alphabet. Magkakaibang format ang URL-safe Base64, karaniwang Base64, at percent encoding. Hindi maibabalik ang inaasahang value kung gagamitan ng URL decoder ang Base64 na text.

Walang padding character ang URL encoding. Kung nag-ulat ang decoder na kulang ang padding, malamang na Base64 o ibang format na gumagamit ng padding ang input, hindi percent-encoded na text.

Mga madalas itanong

Magkapareho ba ang upper-case at lower-case na percent escape?

Oo. Hindi sensitibo sa laki ng titik ang mga hexadecimal letter sa percent escape, kaya parehong kumakatawan sa forward slash ang %2F at %2f. Inirerekomenda ang mga upper-case na hexadecimal digit para maging pare-pareho ang representasyon.

Kayang i-convert ng URL encoding ang international domain name?

Hindi. Ang mga domain label, gaya ng pangalang naglalaman ng é, ay karaniwang nangangailangan ng pagproseso bilang Internationalised Domain Name at ng ASCII Punycode na anyong nagsisimula sa xn--. Ginagamit ang percent encoding para sa iba pang bahagi ng URL at hindi ito dapat ituring na pamalit sa naturang conversion.

Ano ang nangyayari sa mga line break at tab?

Percent-encoded ang mga byte ng tab at line break dahil hindi maaaring direktang lumitaw ang mga ito sa karaniwang URL value. Karaniwang kinakatawan ang tab bilang %09, habang nakadepende ang mga line ending sa kung LF o CRLF character ang ginagamit ng source.

Bakit ayaw pa ring gumana ng encoded na URL kapag ipinaste sa application?

Maaaring raw value ang inaasahan ng application at sarili nitong encoding ang inilalapat nito, na nagdudulot ng dobleng encoding. Maaari din nitong tanggihan ang URL dahil sa limitasyon sa kabuuang haba o dahil na-encode ang isang reserved character sa structural na bahagi ng address. Bago mag-encode, alamin kung aling partikular na bahagi ang hinihingi ng application.

Ligtas bang ibahagi ang encoded na query-string data?

Hindi. Binabago lang ng URL percent-encoding ang representasyon, at maaaring ipakita ng mga browser at developer tool ang orihinal na value. Bago magbahagi ng link, suriin ang mga query parameter nito kung may mga email address, account reference, access token, at iba pang data na hindi dapat ibunyag.