Іноді пробіли кодують URL до +знаку, а інший раз до %20. У чому різниця і чому це має відбуватися?
Відповіді:
+означає пробіл лише у application/x-www-form-urlencodedвмісті, наприклад частина запиту URL-адреси:
http://www.example.com/path/foo+bar/path?query+name=query+value
У цій URL-адресі ім'я параметра знаходиться query nameз пробілом, а значення - query valueз пробілом, але назва папки на шляху буквально foo+bar, ні foo bar .
%20є коректним способом кодування простору в будь-якому з цих контекстів. Отже, якщо вам потрібно кодувати URL-адресу рядка для включення до частини URL-адреси, замінити пробіли на %20і плюси завжди можна безпечно %2B. Це те, що, наприклад. encodeURIComponent()робить у JavaScript. На жаль, це не те, що робить urlencode у PHP ( rawurlencode - безпечніший).
Дивіться також HTML 4.01 Застосування специфікації / x-www-form-urlencoded
query+name=query+valueпараметр із форми з <input name="query name" value="query value">. Він не створюватиметься query%20nameз форми, але цілком безпечно використовувати це, наприклад, наприклад. якщо ви збираєте подання форми разом для себе XMLHttpRequest. Якщо у вас є URL-адреса з пробілом, наприклад <a href="http://www.example.com/foo bar/">, браузер буде кодувати це %20для вас, щоб виправити свою помилку, але на це, мабуть, найкраще не покладатися.
foo barв foo+bar?
encodeURIComponent(s).replace(/%20/g, '+')якщо вам справді потрібно+
http://www.example.com/some/path/to/resource?param1=value1
Частина перед знаком питання повинна використовувати% кодування (так %20для простору), після знака питання ви можете використовувати %20або +пробіл, або пробіл. Якщо вам потрібен актуальний +після використання знака питання %2B.
decodeURIComponentне розшифровує його.
+ є зарезервованим, браузер його збереже.
+за замовчуванням ( { foo: 'bar bar'}.to_query=> foo=bar+bar)
Отже, відповіді тут трохи неповні. Використання '% 20' для кодування простору в URL-адресах чітко визначено в RFC3986 , який визначає, як будується URI. У цій специфікації немає жодної згадки про використання позначення "+" для кодування просторів - якщо ви переходите виключно за цією специфікацією, пробіл повинен бути закодований як "% 20".
Згадка про використання "+" для кодування просторів походить від різних втілень специфікації HTML - конкретно в розділі, що описує тип вмісту "application / x-www-form-urlencoded". Це використовується для розміщення даних форми.
Тепер у розділі 8.2.2 в специфікації HTML 2.0 (RFC1866) чітко сказано, що частина Запиту в рядку URL-адреси запиту GET повинна кодуватися як "application / x-www-form-urlencoded". Це, теоретично, говорить про те, що в URL-адресі в рядку запиту (після '?') Законно використовувати "+" у URL-адресі.
Але ... чи справді це? Пам'ятайте, що HTML - це специфікація вмісту, і URL-адреси з рядками запиту можуть використовуватися з вмістом, відмінним від HTML. Далі, хоча пізніші версії специфікації HTML продовжують визначати "+" як правовий у вмісті "application / x-www-form-urlencoded", вони повністю опускають частину, що говорить про те, що рядки запитів GET визначаються як цей тип. Насправді нічого не згадується про кодування рядка запиту ні в чому після специфікації HTML 2.0.
Що залишає перед нами питання - чи справедливо це? Звичайно, є багато застарілого коду, який підтримує '+' у рядках запитів, і багато коду, який також генерує його. Тож шанси хороші, що ви не зірвете, якщо будете використовувати "+". (І насправді я нещодавно провів усі дослідження з цього приводу, тому що виявив великий сайт, який не зміг прийняти "% 20" в GET-запиті як простір. Вони насправді не змогли розшифрувати БУДЬ-який відсоток закодованого символу. Тож послуга вам використання також може бути доречним.)
Але з чистого читання специфікацій, без мови специфікації HTML 2.0, перенесеної на більш пізні версії, URL-адреси повністю охоплені RFC3986, що означає пробіли, які слід перетворити на '% 20'. І, безумовно, так має бути, якщо ви вимагаєте нічого іншого, крім документа HTML.
%20( <a href="?q=a b">), але коли ви надсилаєте форму, він використовує +знак. Ви можете змінити це шляхом явного використання +знака ( <a href="?q=a+b">) або надсилаючи форму за допомогою XMLHTTPRequest.
Краще завжди кодувати пробіли як% 20, а не як "+".
Саме RFC-1866 (специфікація HTML 2.0) вказав, що символи простору повинні бути закодовані як "+" в "парах" ключ-значення "типу вмісту типу" x "www-form-urlencoded. (див. пункт 8.2.1. підпункт 1.). Цей спосіб кодування даних форми також наведений у пізніших специфікаціях HTML, шукайте відповідні параграфи про програму / x-www-form-urlencoded.
Ось приклад такої рядка в URL-адресі, де RFC-1866 дозволяє кодувати пробіли як плюси: "http://example.com/over/there?name=foo+bar". Отже, лише після "?" Пробіли можна замінити плюсами, згідно з RFC-1866. В інших випадках пробіли повинні бути закодовані до% 20. Але оскільки важко визначити контекст, найкраща практика ніколи не кодує пробіли як "+".
Я рекомендую відсотково кодувати всі символи, за винятком "незарезервованих", визначених у RFC-3986, p.2.3
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
Яка різниця: дивіться інші відповіді.
Коли використовувати +замість %20? Використовуйте, +якщо з якоїсь причини ви хочете зробити рядок запиту URL-адреси ( ?.....) або хеш-фрагмент ( #....) більш читабельним. Приклад: Ви можете насправді прочитати це:
https://www.google.se/#q=google+doesn%27t+encode+:+and+uses+%2B+instead+of+spaces
( %2B= +)
Але читати набагато складніше: (принаймні, для мене)
Я думаю +, що навряд чи щось порушить, оскільки Google використовує +(див. Перше посилання вище), і вони, напевно, думали про це. Я буду використовувати +себе лише тому, що читається + Google вважає, що це нормально.