URL encode и decode

URL encode и decode на текст онлайн, докато пишете: инструментът превръща интервалите, буквите извън ASCII (например кирилицата) и символи като & или ? в последователности с процентно кодиране като %20 и ги връща обратно в четим текст. Вторият раздел е URL парсер. Той разделя всеки адрес на протокол, хост, път и параметри на заявката, които можете да редактирате, изключвате или чистите от тагове за проследяване, и записва обратно правилно кодирания URL. Всичко се случва във вашия браузър.

Как да направите URL encode и decode на текст

1. Въведете или поставете текст в полето в раздела Кодиране / Декодиране. Резултат се обновява при всяко натискане на клавиш.
2. Изберете Посока. Кодиране прави текста безопасен за URL, а Декодиране връща caf%C3%A9%20au%20lait обратно в café au lait. Ако поставите в празното поле текст с последователности като %20, инструментът сам превключва на Декодиране (Кодиране вместо това го връща обратно). По същия начин обикновен текст, който трябва да се кодира, поставен в режим Декодиране, превключва на Кодиране, с бутона Декодиране вместо това.
3. При кодиране изберете под Кодиране като какъв е текстът (вижте следващия раздел). Стандартният режим Стойност на параметър е подходящ за една стойност в заявка.
4. Копиране поставя резултата в клипборда. Размяна премества резултата във входното поле и сменя посоката. Така лесно проверявате в двете посоки: декодирането на току-що кодирания текст трябва да върне оригинала.

Всеки символ, който инструментът е променил, е подчертан в резултата. Задръжте курсора върху него, за да видите символа, кода му в Unicode и байтовете му, например é U+00E9 %C3%A9. Под полетата виждате броя на Символи, Байтове UTF-8 и Кодирани символи (или Декодирани символи). Опитайте с пример зарежда изречението Цена: 50 % отстъпка за чай & кафе? Да!, което има 38 символа, но 61 байта UTF-8, защото всяка кирилска буква заема два байта.

При кодиране Всеки ред поотделно кодира всеки ред самостоятелно и запазва новите редове, което е удобно за списък със стойности или връзки. Без тази опция новият ред също се кодира и става %0A. Когато текстът е URL с параметри, инструментът предлага Разделяне на части, което отваря адреса в раздела на парсера.

URL encode на параметър, цял URL или данни от формуляр

Не всеки символ трябва да се кодира навсякъде. Наклонената черта разделя папките в пътя, но вътре в стойност на параметър е обикновен знак, затова верният резултат зависи от това какво кодирате. Кодиране като предлага четири режима:

• Стойност на параметър работи като encodeURIComponent в JavaScript и е подходящ за една стойност в заявка или сегмент от път. Кодира всичко освен букви, цифри и - _ . ! ~ * ' ( ), така че &, =, / или ? във стойността не могат да счупят URL адреса. Кодирането на café & crème дава caf%C3%A9%20%26%20cr%C3%A8me, готово за поставяне след q=.
• Цял URL адрес е за пълен адрес, който само трябва да се почисти. Кодира интервалите, символите извън ASCII, управляващите символи, обратния апостроф и " < > \ ^ { | }, а запазва всичко, което дава структура на URL: : / ? # [ ] @ ! $ & ' ( ) * + , ; =. Така https://example.com/search?q=café au lait&lang=fr става https://example.com/search?q=caf%C3%A9%20au%20lait&lang=fr. Вече кодираните последователности остават непроменени, а самотно % става %25. Тук е разликата с encodeURI в JavaScript, който превръща съществуващото %20 в %2520 и кодира скобите на IPv6 адрес като http://[2001:db8::1]:8080/.
• Данни от формуляр следва формата application/x-www-form-urlencoded (на английски), който създават HTML формулярите и URLSearchParams. Интервалът става +, а некодирани остават само буквите, цифрите и * - . _, така че ! ' ( ) ~ също се кодират.
• Строг RFC 3986 оставя некодирани само незарезервираните знаци по RFC 3986 (на английски): букви, цифри и - . _ ~. OAuth 1.0 (RFC 5849) и AWS Signature Version 4 изискват точно този вид, защото подписът съвпада само когато двете страни кодират ! или * по един и същ начин.

Същите символи във всеки режим:

Символ	Стойност на параметър	Цял URL адрес	Данни от формуляр	Строг RFC 3986
интервал	%20	%20	+	%20
&	%26	&	%26	%26
/	%2F	/	%2F	%2F
+	%2B	+	%2B	%2B
~	~	~	%7E	~
!	!	!	%21	%21
*	*	*	*	%2A
é	%C3%A9	%C3%A9	%C3%A9	%C3%A9

Текстът винаги се кодира като UTF-8, а шестнадесетичните цифри винаги са главни. Ако входът вече съдържа последователности като %20, бележка го съобщава и предлага Декодиране вместо това, за да не кодирате текста два пъти по погрешка.

За да подадете JSON в параметър на заявка, свийте го във JSON форматиращия инструмент и го кодирайте като Стойност на параметър: {"id":7,"tags":["a","b"]} става %7B%22id%22%3A7%2C%22tags%22%3A%5B%22a%22%2C%22b%22%5D%7D. Работи и в обратната посока: декодирайте параметъра тук, после го форматирайте там.

URL decode проблеми: плюсове, %2520 и повредени последователности

Декодирането обикновено просто работи, но четири ситуации затрудняват хората. Инструментът се справя с всяка от тях, вместо да спира с грешка:

• Знакът плюс означава интервал в данните от формуляри и в повечето низове на заявки. Опцията Декодиране на + като интервал е включена по подразбиране, така че caf%C3%A9+au+lait се декодира до café au lait. В цял URL като интервали се броят само плюсовете след ?, защото в пътя плюсът е обикновен знак. Изключете опцията, когато плюсът е истински. Плюс, кодиран като %2B, винаги си остава плюс.
• Двойно кодиране възниква, когато два слоя код кодират една и съща стойност, срещу което RFC 3986 изрично предупреждава. Всяко % става %25, така че интервалът от %20 се превръща в %2520. Ако декодираният резултат още съдържа последователности като %20, инструментът съобщава, че текстът вероятно е кодиран два пъти, и предлага Декодиране отново.
• Невалидна последователност, тоест %, след което няма две шестнадесетични цифри, като в 100% или %G1, кара decodeURIComponent в JavaScript да хвърли URIError. Тук такива последователности се оставят непроменени, маркират се в червено, броят се, а останалата част от текста се декодира.
• Старите връзки в Latin-1 идват от времето преди UTF-8, когато някои сайтове кодираха é като единичния байт %E9. caf%E9 не е валиден UTF-8, затова decodeURIComponent се проваля, а unquote в Python връща caf, следвано от заместващия символ U+FFFD. Инструментът чете такива байтове като Windows-1252, декодира caf%E9 до café и добавя бележка за това.

Управляващите символи в декодирания текст, като табулация или нулев байт, се показват като видими символи като ␉ и ␀, но Копиране копира истинския текст.

URL парсер: разделяне на URL и редакция на параметрите му

Поставете адрес в полето URL в раздела Разбор и редакция на URL и той се разделя на Протокол, Хост, Порт, Път и Фрагмент, плюс Потребител и Парола, когато URL адресът ги съдържа. Стойностите се показват декодирани, така че разделът е и най-бързият начин да декодирате URL параметри: четете мъжки обувки вместо %D0%BC%D1%8A%D0%B6%D0%BA%D0%B8+%D0%BE%D0%B1%D1%83%D0%B2%D0%BA%D0%B8. Редакцията работи в двете посоки, като адресната лента и таблицата с параметри в Postman. Променяте поле и URL адресът се пренаписва веднага, правилно кодиран; променяте URL адреса и всички части се прочитат отново. Частите, които не пипате, остават точно каквито са били, символ по символ.

Таблицата Параметри на заявката изброява всеки параметър с неговото Име и Стойност. Махнете отметката Включване в URL, за да изключите параметър, без да го изтривате, което помага, когато търсите параметъра, който чупи заявката. Добавяне на параметър, Премахване на параметъра и Подредба от А до Я правят точно това, което пише. Повтарящите се имена като tag=a&tag=b и имената без стойност като ?debug се запазват. Интервали в параметрите определя дали интервалите се записват като %20 или като +; по подразбиране следва поставения URL.

Връзките за вход и плащане често носят втори URL вътре в параметър, кодиран така, че собствените му ? и & да не се смесват с външните:

https://auth.example.com/authorize?client_id=abc&redirect_uri=https%3A%2F%2Fapp.example.com%2Fcallback%3Ftab%3D2

Стойност, която сама е URL, обикновено в redirect_uri, return, url или next, получава бутон Редакция на вложения URL. Вътрешният адрес https://app.example.com/callback?tab=2 се отваря като отделно ниво със собствени части и параметри, навигационна пътека (Основен URL › redirect_uri) води обратно, а всяка промяна се кодира обратно във външния URL. Копиране на основния URL копира резултата. Това работи на няколко нива дълбочина.

Когато частта след # прилича на параметри, както в #access_token=...&state=... при OAuth implicit flow или в #/search?q=shoes в маршрутите на едностранични приложения, втора таблица, Параметри във фрагмента, ги изброява също.

Парсерът сочи и проблеми: URL без протокол, който браузърите третират като относителна връзка; порт извън диапазона от 0 до 65535; и символи, които трябва да се кодират, като интервали, букви извън ASCII, " или <, което Кодиране на знаците поправя с една стъпка. Текст без адрес, като a=1&b=2, се чете като низ на заявка. За интернационализиран домейн (на английски) инструментът показва формата Punycode, която използват DNS и браузърите, така че münchen.de става xn--mnchen-3ya.de, а домейн, започващ с xn--, получава четимия си вид.

Копиране на URL копира готовия адрес, Отваряне го отваря в нов раздел (само http и https връзки), а Копиране като JSON ви дава параметрите като JSON обект, като повтарящите се имена се събират в масив.

Премахване на UTM и други параметри за проследяване от URL

Връзките от бюлетини, реклами и социални мрежи носят параметри, които само казват на сайта откъде е дошъл посетителят. UTM параметрите (на английски) utm_source, utm_medium, utm_campaign, utm_term и utm_content водят началото си от Urchin, предшественика на Google Analytics. Идентификаторите на кликове като fbclid (Facebook), gclid (Google Ads) и msclkid (Microsoft Advertising) се добавят от самите платформи.

Парсерът маркира тези параметри с таг проследяване, а Премахване на проследяването (n) ги изтрива всички наведнъж. Освен всеки параметър utm_* разпознава още над 20 други, като ttclid (TikTok), mc_cid (Mailchimp) и _hsenc (HubSpot). Параметрите, от които страницата има нужда, остават на мястото си: в адреса на магазина от Опитайте с пример Премахване на проследяването (4) премахва utm_source, utm_medium, utm_campaign и fbclid и запазва q, size, return и фрагмента #reviews.

Връзка, която ще влезе в QR код, си струва първо да се почисти тук. Без параметри за проследяване тя е по-кратка, а по-кратката връзка дава по-малко плътен код, който се сканира по-лесно.

Какво е процентно кодиране и как символите стават %XX

Процентното кодиране (на английски), наричано още URL encoding, записва символ като %, следвано от две шестнадесетични цифри. URL адресът може да съдържа само ограничен набор ASCII символи и някои от тях имат роля: ? започва заявката, & разделя параметрите, # започва фрагмента. RFC 3986 нарича тези символи резервирани (: / ? # [ ] @ и ! $ & ' ( ) * + , ; =). Буквите, цифрите и - . _ ~ са незарезервирани и никога не се нуждаят от кодиране. Всичко останало, и всеки резервиран символ, използван като обикновени данни, се кодира.

Символите извън ASCII първо се превръщат в байтове UTF-8 и всеки байт получава собствено %XX:

• é е U+00E9, което UTF-8 съхранява като двата байта C3 A9, така че става %C3%A9.
• € е U+20AC, три байта: %E2%82%AC.
• Емоджи като U+1F600 (усмихнато лице) заема четири байта: %F0%9F%98%80.

%c3%a9 и %C3%A9 означават едно и също, но RFC 3986 препоръчва главни букви и инструментът пише точно така. Таблица с процентно кодиране на символите, които срещате най-често:

Символ	Кодиран	Символ	Кодиран
интервал	%20	+	%2B
!	%21	,	%2C
"	%22	/	%2F
#	%23	:	%3A
$	%24	;	%3B
%	%25	=	%3D
&	%26	?	%3F
'	%27	@	%40
(	%28	[	%5B
)	%29	]	%5D
*	%2A	нов ред	%0A

URL кодиране в JavaScript, Python и PHP

Всеки език има функции за това и те се различават най-вече в третирането на интервалите, наклонените черти и ! ' ( ) * ~.

JavaScript има encodeURIComponent (на английски) за стойност, encodeURI за цял адрес и URLSearchParams за кодиране на формуляри:

encodeURIComponent("café & crème")                     // "caf%C3%A9%20%26%20cr%C3%A8me"
encodeURI("https://example.com/a b?q=café")            // "https://example.com/a%20b?q=caf%C3%A9"
new URLSearchParams({ q: "café & crème" }).toString()  // "q=caf%C3%A9+%26+cr%C3%A8me"
decodeURIComponent("caf%C3%A9")                        // "café"

decodeURIComponent не превръща + в интервал и хвърля URIError при невалидна последователност като 100%.

В Python функциите са в urllib.parse. quote запазва / по подразбиране (safe='/') и иначе кодира всичко освен незарезервираните символи по RFC 3986. quote_plus записва интервалите като + и кодира и /:

from urllib.parse import quote, quote_plus, urlencode, unquote_plus

quote("café & crème/brûlée")       # 'caf%C3%A9%20%26%20cr%C3%A8me/br%C3%BBl%C3%A9e'
quote("a b/c", safe="")            # 'a%20b%2Fc'
quote_plus("café & crème/brûlée")  # 'caf%C3%A9+%26+cr%C3%A8me%2Fbr%C3%BBl%C3%A9e'
urlencode({"q": "café & crème", "page": 2})  # 'q=caf%C3%A9+%26+cr%C3%A8me&page=2'
unquote_plus("caf%C3%A9+au+lait")  # 'café au lait'

В PHP urlencode кодира като HTML формуляр и записва интервала като +, докато rawurlencode следва RFC 3986 и записва %20:

urlencode("café & crème");     // "caf%C3%A9+%26+cr%C3%A8me"
rawurlencode("café & crème");  // "caf%C3%A9%20%26%20cr%C3%A8me"

rawurlencode дава същия резултат като Строг RFC 3986. urlencode съвпада с Данни от формуляр, освен за *, което кодира като %2A.

Често задавани въпроси

Интервалът трябва ли да се кодира като %20 или като +?

%20 работи навсякъде в URL. + означава интервал само в низа на заявката и в данните от формуляри, формата, който изпращат HTML формулярите. В пътя + е обикновен знак плюс, така че /a+b си остава /a+b. Когато стойност в заявка има нужда от истински плюс, го запишете като %2B. В инструмента Данни от формуляр записва интервалите като +, а другите три режима като %20.

Какво означават %20, %2F и %3D в URL?

Това са кодирани символи: %20 е интервал, %2F наклонена черта, а %3D знак за равно. Други, които често виждате, са %26 (&), %3F (?), %3A (:), %2C (запетая) и %27 (апостроф). Двете цифри са кодът на символа в шестнадесетична система. Буквите извън ASCII заемат от две до четири такива двойки, като %C3%A9 за é. Поставете целия низ в декодера, за да го прочетете.

Каква е разликата между encodeURI и encodeURIComponent?

encodeURI е предназначен за цял адрес и оставя непроменени символите, които му дават структура, като : / ? # & =. encodeURIComponent е предназначен за една част, стойност на параметър или сегмент от път, и кодира и тези символи, така че https://example.com/?a=1&b=2 става https%3A%2F%2Fexample.com%2F%3Fa%3D1%26b%3D2. В този инструмент Стойност на параметър съответства на encodeURIComponent, а Цял URL адрес е като encodeURI, но запазва съществуващите последователности като %20, вместо да ги превръща в %2520.

Как да премахна UTM параметрите от URL?

Поставете връзката в раздела Разбор и редакция на URL и натиснете Премахване на проследяването (n). Бутонът изтрива всеки таг utm_* и идентификатори на кликове като fbclid и gclid наведнъж. После натиснете Копиране на URL. За да махнете само някои от тях, използвайте Премахване на параметъра на редовете, които не искате.

URL кодирането същото ли е като криптиране или Base64?

Не. URL кодирането не скрива нищо: всеки може да декодира caf%C3%A9 обратно в café, така че то никога не пази парола или токен. То само прави символите безопасни за употреба в адрес. Base64 е друго кодиране, което превръща всякакви данни, включително двоични файлове, в низ от 64 знака. Низ Base64 в URL пак има нужда от кодиране на +, / и =, освен ако не използвате URL-безопасния вариант, който Base64 енкодерът и декодерът може да създаде.

URL адресите, които поставям, качват ли се или съхраняват ли се?

Не. Кодирането, декодирането и разбирането на адреса се изпълняват във вашия браузър и нищо от поставеното не се изпраща към сървър. Това е важно, защото URL адресите често носят токени за достъп, ID на сесии или кодове за смяна на парола. Браузърът помни само избрания от вас раздел и опции, никога текстовете. Единственото, което зарежда адреса, е Отваряне, който го отваря в нов раздел точно като щракване върху връзката.

Още инструменти за програмисти има в категория Разработчици, а инструментите, които превръщат един формат в друг, са събрани в Конвертори. За да откриете какво се различава между два дълги URL адреса, например работеща и неработеща API заявка, поставете ги в инструмента за сравняване на текстове и сравнявайте по символи.