Чем заполняется пробел в url адресе
URL, кодирующий пробел: + или% 20?
Из Википедии (выделение и ссылка добавлены):
Когда данные, введенные в формы HTML, передаются, имена и значения полей формы кодируются и отправляются на сервер в сообщении HTTP-запроса с использованием метода GET или POST или, исторически, по электронной почте. Кодировка, используемая по умолчанию, основана на очень ранней версии общих правил процентного кодирования URI с рядом модификаций, таких как нормализация новой строки и замена пробелов на «+» вместо «% 20». Данные MIME-типа, закодированные таким образом, имеют вид application / x-www-form-urlencoded, и в настоящее время они определены (все еще очень устаревшим образом) в спецификациях HTML и XForms.
Эта путаница объясняется тем, что URL до сих пор «не работают».
Мы можем извлечь подробную информацию об URL-адресе » http://www.google.com «:
Если мы посмотрим на более сложный URL, такой как:
мы можем извлечь следующую информацию:
Зарезервированные символы различны для каждой части.
Для HTTP-URL пробел в части фрагмента пути должен быть закодирован как «% 20» (не совсем, не «+»), в то время как символ «+» в части фрагмента пути может быть оставлен незакодированным.
Теперь в части запроса пробелы могут быть закодированы либо в «+» (для обратной совместимости: не пытайтесь искать его в стандарте URI), либо в «% 20», пока символ «+» (из-за этой неоднозначности ) должен быть экранирован до «% 2B».
Это означает, что строка «синий + голубой» должна кодироваться по-разному в частях пути и запроса:
Отсюда вы можете сделать вывод, что кодирование полностью сконструированного URL невозможно без синтаксической осведомленности о структуре URL.
Вы жестко их кодируете?
Пробел может быть закодирован только в «+» в части запроса «пары ключ-значение контента» типа application / x-www-form-urlencoded запроса URL-адреса. На мой взгляд, это МОЖЕТ, а НЕ ДОЛЖЕН. В остальных URL он закодирован как% 20.
По моему мнению, лучше всегда кодировать пробелы как% 20, а не как «+», даже в части запроса URL, потому что это спецификация HTML (RFC-1866), которая указывает, что символы пробела должны кодироваться как « + «in» application / x-www-form-urlencoded »пары ключ-значение типа содержимого (см. пункт 8.2.1. подпункт 1)
Этот способ кодирования данных формы также приведен в более поздних спецификациях HTML. Например, посмотрите соответствующие параграфы о application / x-www-form-urlencoded в спецификации HTML 4.01 и т. Д.
Я бы порекомендовал кодировать в процентах все символы, кроме «незарезервированных», определенных в RFC-3986, п.2.3.
Реализация зависит от языка программирования, который вы выбрали.
Если ваш URL содержит национальные символы, сначала закодируйте их в UTF-8, а затем закодируйте в процентах результат.
URL-адреса могут содержать пробел?
разрешено ли URI (в частности, URL HTTP) содержать один или несколько символов пробела? Если URL-адрес должны закодироваться, is + просто обычно соблюдаемая конвенция или законная альтернатива?
в частности, может ли кто-то указать на RFC, который указывает, что URL-адрес с пробелом должны быть закодирован?
мотивация на вопрос: во время бета-тестирования веб-сайта я отметил, что некоторые URL-адреса были построены с пробелами в их. Firefox, казалось, сделал правильную вещь, что меня удивило! Но я хотел иметь возможность указать разработчикам на RFC, чтобы они почувствовали необходимость исправить эти URL-адреса.
11 ответов
все небезопасные символы всегда должны быть закодированы в URL. Для например, символ «#» должен быть закодирован в URL-адресах даже в системы, которые обычно не имеют дело с фрагментом или якорем идентификаторы, так что если URL копируется в другую систему, которая использует ли их, изменять кодировку URL не потребуется.
почему он должен быть закодирован? Запрос выглядит так:
есть 3 поля, разделенные пробелом. Если вы поместите пробел в свой url:
вы знаете, есть 4 поля, HTTP-сервер скажет вам, что это недопустимый запрос.
URL-адреса определяются в RFC 3986, хотя другие RFCs также актуальны, но RFC 1738 устарела.
Они могут не иметь пробелов в них, наряду со многими другими символами. Поскольку эти запрещенные символы часто должны быть каким-то образом представлены, существует схема кодирования их в URL-адрес путем перевода их в шестнадцатеричный эквивалент ASCII с префиксом»%».
большинств языки программирования / платформы обеспечивают функции для кодирование и декодирование URL-адресов, хотя они могут неправильно соответствовать стандартам RFC. Например, Я знаю, что PHP этого не делает.
да, пространство обычно кодируется как «%20». Любые параметры, которые передают в URL должны быть закодированы, просто по соображениям безопасности.
может ли кто-нибудь указать на RFC, указывающий, что URL с пробелом должен быть закодирован?
URIs и, следовательно, URL-адреса определены в RFC 3986.
Если вы посмотрите на грамматику, определенную там, вы в конечном итоге заметите, что символ пробела никогда не может быть частью синтаксически законного URL-адреса, поэтому термин «URL с пробелом» является противоречием сам по себе.
URL может иметь символ пробела в них, и они будут отображаться как %20 в большинстве браузеров, но правила кодирования браузера меняются довольно часто, и мы не можем зависеть от того, как браузер будет отображать URL.
есть Счастливый вопрос.
чтобы ответить на ваш вопрос. Я бы сказал, что приложения довольно часто заменяют пробелы в значениях, которые будут использоваться в URL-адресах. Причина этого обычно заключается в том, чтобы избежать более сложной для чтения процентной (URI) кодировки.
проверьте эту статью Википедии о процент-кодирование.
Urls должны не есть пробелы в них. Если вам нужно обратиться к тому, кто это делает, используйте его закодированное значение %20
Firefox 3 отобразит %20 S в URL-адресах в виде пробелов в адресной строке.
не видел. Возможно, вы можете настроить веб-сервер, чтобы принять это.
URL, кодирующий пробел: + или% 20?
4 ответа
Из Wikipedia (выделено и добавлена ссылка):
При отправке данных, которые были введены в формы HTML, имена и значения полей формы кодируются и отправляются на сервер в сообщении HTTP-запроса с использованием метода GET или POST, или, как правило, по электронной почте. Кодировка, используемая по умолчанию, основана на очень ранней версии общих правил процентного кодирования URI с количество модификаций, таких как нормализация новой строки и замена пробелов на» + «вместо»% 20 «. Тип данных MIME, закодированных таким образом является application / x-www-form-urlencoded, и в настоящее время он определен (все еще очень устаревшим) в спецификациях HTML и XForms.
Пробел может быть закодирован только как «+» в части запроса пар ключ-значение типа содержимого «application / x-www-form-urlencoded» URL. На мой взгляд, это МОЖНО, а не ОБЯЗАТЕЛЬНО. В остальных URL-адресах он кодируется как% 20.
На мой взгляд, лучше всегда кодировать пробелы как% 20, а не как «+», даже в части запроса URL-адреса, потому что это спецификация HTML (RFC-1866), которая указывает, что символы пробелов должны быть закодированы как » + «in» application / x-www-form-urlencoded «пары ключ-значение типа содержимого (см. параграф 8.2.1. подпункт 1.)
Этот способ кодирования данных формы также указан в более поздних спецификациях HTML. Например, поищите соответствующие абзацы о application / x-www-form-urlencoded в спецификации HTML 4.01 и т. Д.
Я бы рекомендовал кодировать в процентах все символы, кроме «незарезервированных», определенных в RFC-3986, п. 2.3.
Реализация зависит от выбранного вами языка программирования.
Если ваш URL-адрес содержит национальные символы, сначала закодируйте их в UTF-8, а затем закодируйте результат в процентах.
Вы их жестко кодируете?
Фактически, вы можете следить за этой интересной дискуссией в собственном трекере проблем Python о том, что использовать для кодирования пробелов: http: // bugs.python.org/issue13866.
Эта путаница возникает из-за того, что URL-адреса по сей день «не работают».
Мы можем извлечь подробную информацию об URL «http://www.google.com»:
Если мы посмотрим на более сложный URL-адрес, например:
мы можем извлечь следующую информацию:
Зарезервированные символы различны для каждой части.
Для URL-адресов HTTP пробел в части фрагмента пути должен быть закодирован как «% 20» (нет, абсолютно не «+»), в то время как символ «+» в части фрагмента пути можно оставить незакодированным.
Теперь в части запроса пробелы могут быть закодированы либо как «+» (для обратной совместимости: не пытайтесь искать его в стандарте URI), либо как «% 20», в то время как символ «+» (в результате этой неоднозначности ) необходимо преобразовать в «% 2B».
Это означает, что строка «синий + голубой» должна кодироваться по-разному в частях пути и запроса:
Отсюда вы можете сделать вывод, что кодирование полностью сконструированного URL-адреса невозможно без синтаксической осведомленности о структуре URL-адреса.
Это сводится к следующему:
Мой URL — это не ваш URL
Когда давным-давно в 1996 году я приступил к работе над программой httpget, предшественницей проекта Curl, я написал свой первый синтаксический анализатор URL. Как раз тогда этот универсальный адрес получил название URL: Uniform Resource Locator (единый указатель ресурсов). Его спецификация была опубликована IETF в 1994 году. Аббревиатура «URL» была затем использована как источник вдохновения для названия инструмента и проекта Curl.
Термин «URL» был позднее изменён; его стали называть URI (Uniform Resource Identifier — единый идентификатор ресурсов), согласно спецификации, опубликованной в 2005 году, однако основное сохранилось: синтаксис для строки, задающей онлайн-ресурс и указывающей протокол для получения этого ресурса. Мы требуем, чтобы curl принимал указатели URL, как определено данной спецификацией RFC 3986. Ниже я расскажу, почему на самом деле это не совсем так.
Был ещё родственный RFC, описывающий IRI: Internationalized Resource Identifier (международный идентификатор ресурсов). IRI, по существу, то же самое, что URI, но IRI позволяют использовать символы, не входящие в ASCII.
Консорциум WHATWG позднее создал свою собственную спецификацию URL, в основном, сведя вместе форматы и идеи от URI и IRI с сильным упором на браузеры (что неудивительно). Одна из объявленных ими целей — «Модернизировать RFC 3986 и RFC 3987 в соответствии с современными реализациями и постепенно вывести их из употребления». Они хотят вернуться к использованию термина «URL», справедливо заявляя, что термины URI и IRI просто запутывают ситуацию и что люди так и не поняли их (или часто даже не знают, что эти термины существуют).
Спецификация WHATWG написана в духе старой доброй мантры браузеров: быть как можно более либеральными с пользователями, всегда пытаться угадать, что они имеют в виду, и выворачиваться наизнанку, пытаясь сделать это. Хотя при этом мы все знаем сейчас, что закон Постеля — не самый лучший подход к делу. На деле это значит, что спецификация позволяет использовать в URL слишком много слэшей, пробелы и символы, не входящие в ASCII.
С моей точки зрения, такую спецификацию также очень трудно читать и соблюдать, поскольку она не очень подробно описывает синтаксис или формат, но при этом навязывает обязательный алгоритм парсинга. Чтобы проверить моё утверждение: посмотрите, что это спецификация говорит о концевой точке после имени хоста в URL.
Вдобавок ко всем этим стандартам и спецификациям, в интерфейсе всех браузеров есть адресная строка (которую часто называют и по-другому), которая позволяет пользователям вводить какие угодно забавные строки и преобразовывает их в URL. Если ввести » http://localhost/%41 » в адресную строку, то участок с процентом будет преобразован в «A» (поскольку 41 в шестнадцатеричном исчислении является заглавной буквой A в ASCII), но если ввести » http://localhost/A A «, то фактически в исходящий HTTP-запрос GET будет отправлено » /A%20A » (с пробелом в URL-кодировке). Я говорю об этом, так как люди часто думают, что всё, что можно ввести в эту строку — и есть URL.
Указанное выше — в основном моё (искаженное) представление, с какими спецификациями и стандартами нам пока приходится работать. Теперь давайте добавим реальности и посмотрим, какие проблемы мы получаем, когда мой URL — это не ваш URL.
Так что же такое URL?
Или более конкретно — как мы пишем их? Какой синтаксис используем?
Думаю, одна из самых больших ошибок в спецификации WHATWG (и в ней причина, почему я выступаю против этой спецификации в её текущей форме с твёрдым убеждением, что они неправы) состоит в том, что они полагают, будто только им позволено работать с URL и давать им определение; они ограничивают свое представление об URL исключительно браузерами, HTML и адресными строками. Конечно, WHATWG создан большими компаниями, представляющими браузеры, которые использует почти каждый, а в этих браузерах широко работают указатели URL, но сами URL — явление значительно большее.
Представление об URL, существующее у WHATWG, не слишком широко принимается за пределами браузеров.
Двоеточие-слэш-слэш
Если спросить пользователей — обычных людей без какого-либо особого знания протоколов или сети — о том, что такое URL, то что они ответят? Последовательность «://» (двоеточие-слэш-слэш) была бы в начале списка ответов; несколько лет назад, когда браузеры показывали URL более полно, это было бы еще заметнее. Увидев эту последовательность, мы сразу понимаем, что перед нами именно URL.
Однако давайте отойдём от пользователей и оглядимся — в мире существуют почтовые клиенты, эмуляторы терминалов, текстовые редакторы, Perl-скрипты и многое-многое другое, что способно распознавать URL и работать с ними. Например, открыть URL в браузере, превратить в активную ссылку в сгенерированном HTML и так далее. Огромное количество названных скриптов и программ будет использовать именно последовательность «двоеточие-слэш-слэш» как главный признак.
Спецификация WHATWG говорит, что должен быть как минимум один слэш и что парсер при этом обязан принимать какое угодно количество слэшей. Это значит, что » http:/example.com » и » http:///////////////example.com » — полностью подходящие варианты. RFC 3986 и многие другие с этим не согласны. Ну, действительно, большинство из людей, с которыми я спорил последние несколько дней, даже те, кто работает в вебе, говорит, думает и убеждено, что URL имеет два слэша. Просто посмотрите внимательнее на скриншот результата поиска картинок в Гугл по запросу «URL» выше в этой статье.
Мы просто знаем, что у URL есть два слэша (хотя, да, URL типа file: обычно имеют три слэша, но давайте пока проигнорируем это). Не один. Не три. Два. Но WHATWG с этим не согласен.
«Есть хоть одна настоящая причина принимать более двух слэшей для не-файловых URL?» (спрашиваю я раздраженно у членов WHATWG)
Спецификация говорит это, потому что браузеры реализовали её именно так.
Никакое лучшее объяснение не было дано даже после того, как я указал, что это утверждение неправильное и далеко не все браузеры делают так. Возможно, эта ветка обсуждения покажется вам весьма познавательной.
В проекте Curl мы как раз недавно начали обсуждать, как обращаться с указателями URL, имеющими число слэшей, отличное от двух, потому что, оказывается, уже есть серверы, передающие обратно такие URL в заголовке “Location:”, и некоторые браузеры без возражений принимают их. Curl — нет, так же как и большинство из множества других библиотек и инструментов командной строки. Кого нам поддержать?
Пробелы
Символ пробела (код 32 в ASCII, шестнадцатеричный код 0x20) не может быть частью URL. Если требуется отправить его, то следует использовать URL-кодировку, как это делают с любым другим недопустимым символом, который надо сделать частью URL. URL-кодировка — это байтовое значение в шестнадцатеричном исчислении со знаком процента перед ним. Таким образом, «%20» означает пробел. Это также означает, что синтаксический анализатор, например, сканирующий текст на предмет указателей URL, узнаёт, что достиг конца URL, когда он обнаруживает недопустимый символ. Например, пробел.
Браузеры обычно преобразовывают все %20 в своих адресных строках в символ пробела, чтобы ссылки выглядели прилично. При копировании адреса в буфер и вставке его в текстовый редактор мы видим пробелы как %20, что и требуется.
Я не уверен, в этом ли причина, но браузеры также принимают пробелы как часть URL, получая, например, переадресацию в HTTP-ответе. Такие URL передаются от сервера к клиенту в заголовке «Location:». Браузеры без проблем допускают пробелы в них URL, кодируя их в виде %20 и отправляя следующий запрос. Это заставляет curl принимать пробелы в перенаправляемых «URL».
Не-ASCII
Поддержка в URL языков, включающих символы, не входящие в ASCII, конечно, важно, особенно для незападных сообществ, и я согласен, что спецификация IRI никогда не была достаточно хороша. Я лично далёко не эксперт в интернационализации, поэтому я руководствуюсь тем, что слышал от других. Но, конечно, пользователи нелатинских алфавитов и систем печати должны иметь возможность записывать свои «интернет-адреса» в ресурсы и использовать их как ссылки.
В идеальном случае у нас была бы интернационализированная версия для показа пользователю, и версия в кодировке ASCII для внутреннего использования в сетевых запросах.
Для международных доменных имён имя преобразуется в кодировку punycode так, чтобы оно могло быть прочитано обычными серверами DNS, которые ничего не знают об именах в кодировке, отличной от ASCII. Идентификаторы URI не имеют IDN-имён; IRI и URL по версии WHATWG — имеют. Сurl поддерживает IDN-имена хостов.
WHATWG заявляет, что URL могут использовать UTF-8, тогда как URI — только ASCII. Curl не воспринимает не-ASCII-символы в части адреса, задающей путь, но кодирует их процентом в исходящих запросах; это порождает “интересные» побочные эффекты, когда не-ASCII-символы представлены в коде, отличном от UTF-8, что является, например, стандартным для Windows.
Подобно тому, что я написал выше, это приводит к серверам, отправляющим назад не-ASCII-коды в HTTP-заголовках, которые браузеры охотно принимают, и не-браузерам тоже приходится работать с ними.
Стандарта URL не существует
Я не пытался представить полный список проблем или несоответствий — здесь просто некоторая подборка трудностей, с которыми я недавно столкнулся. «URL», выданный в одном месте, конечно, совсем необязательно будет принят или понят в другом месте как «URL».
В наши дни даже curl уже не следует строго ни одной опубликованной спецификации — мы медленно деградируем в угоду “веб-совместимости”.
Единый стандарт URL отсутствует, и какая-либо работа в этом направлении не ведётся. Я не могу считать, что WHATWG прилагает настоящие усилия к этому, поскольку она пишет спецификацию закрытой группой без серьёзных попыток привлечь более широкое сообщество.
Содержание
Что такое URL и как его настроить
Стандартный URL сайта состоит из нескольких элементов:
Протокол передает браузеру информацию о том, как взаимодействовать с сервером. Именно благодаря ему ссылки могут работать.
Адрес с установленным сетевым протоколом HTTPS выглядит следующим образом: https://ru.wikipedia.org/wiki/Википедия.
Эта часть URL важна при оптимизации, но главную роль играет следующий элемент.
Поисковые системы отлично воспринимают даже сложные URL. Но для выдачи и пользователей важно, чтобы адрес был лаконичным и максимально простым. Гораздо приятнее в адресной строке видеть оптимизированный URL https://ru.wikipedia.org/wiki/Википедия, чем http://www.example.com/index.php?id_145f3.
Влияние URL на SEO
ЧПУ: Что это?
Из примеров становится понятно, что на правильно составленный URL указывает именно путь страницы.
Для настройки ЧПУ получится использовать буквы как латинского алфавита, так и кириллицы.
Преимущества и недостатки ЧПУ
Сайт, где выполнена генерация SEO URL, получает массу преимуществ:
Говоря о том, как прописать URL адрес, стоит сказать и о недостатках ЧПУ:
Как правильно прописывать URL страницы: 15 простых советов
1. Что лучше: подраздел или поддомен?
Лучше при настройке ЧПУ использовать подразделы. Тогда поисковая система автоматически определит их как элементы сайта. Это дает преимущества в SEO. Подразделы в отличие от поддоменов не конкурируют с основным сайтом за ранжирование в выдаче. Кроме того, их лучше использовать, если на источник ссылаются сторонние ресурсы. В системе подразделов ссылки на разделы сайта повышают авторитет вновь созданных страниц.
Динамические ссылки с метками UTM имеют ряд недостатков:
Лучше выбирать статические ссылки. Они сохраняют вид, пока владелец ресурса сам не внесет изменения.
3. Создание логической структуры страниц
Если не позаботиться о логичной структуре сайта заранее, через некоторое время он наполнится множеством конкурирующих адресов. Это мешает пользователям и поисковым системам.
4. Уменьшаем глубину вложенности страниц
Независимо от того, насколько далеко раздел находится от главной страницы сайта, вложенность не должна быть слишком большой. Лучше убирать из адреса упоминания о категориях.
Если ЧПУ уменьшить не получается, стоит скрыть его часть.
5. Важна ли длина URL?
Короткие ссылки выглядят привлекательнее. Длинные имена неудобны при копировании, их невозможно набрать вручную.
6. Как добавить ключевые слова
Наличие ключевых слов положительно влияет на продвижение ресурса. Не стоит добавлять слишком много фраз из семантического ядра. Чтобы ссылка выглядела привлекательно как для поисковиков, так и для пользователей, нужно включать по 1-2 ключевика в адрес. Лучше добавлять запросы из meta-тегов (Title, Description).
Ключевая фраза в адресе полезна при Email-рассылке. По ней получатель сразу видит, стоит ли переходить по ссылке.
7. Лучше не использовать заглавные буквы
На учет заглавных букв в URL влияет система хостинга и CMS. Зачастую они воспринимают страницы Example.html и example.html как разные. Поэтому при вводе адреса с неправильным регистром выдается ошибка 404.
8. Дефис, нижнее подчеркивание и пробел: что выбрать для URL?
При указании в адресе более 1 слова стоит для разделения брать дефисы. Google нижние подчеркивания воспринимает нормально, для выдачи в Яндекс их брать не стоит.
Пробелы не воспринимаются поисковыми системами и заменяются на «%20».
9. Какой алфавит подходит: кириллица или латиница?
Поисковые системы научились распознавать кириллицу. Проблемы возникают при копировании доменов, состоящих из русских букв. Тогда слова заменяются на набор символов.
10. Предлоги и специальные символы при настройке ЧПУ
При использовании в meta-тегах предлогов и других стоп-слов не стоит бояться употреблять их в ЧПУ. Но нужно придерживаться правила: эти элементы лучше не использовать, если они не помогают облегчить читабельность адресов.
11. Минусы хэшей и хэштегов в URL
Поисковики пропускают часть адреса, идущую после символа «#». Хэштеги стоит добавлять только для облегчения навигации и в пунктах меню на landing page. В остальных случаях «#» в URL включать не нужно.
12. Канонические ссылки
Так называют приоритетные адреса страниц, предотвращающий их дублирование. При появлении копии раздела на сайте понижается рейтинг у канонической и повторной ссылки. Справиться с проблемой получится при добавлении атрибута. Он укажет поисковикам, какой элемент основной.
13. Настраиваем 301 редирект
Это нужно сделать при:
Переадресация указывает на то, что страница окончательно перемещена на другой адрес.
14. Даты в адресе страницы
15. Карты Sitemap.xml
Как правильно написать URL сайта в Яндекс и Google
Для ранжирования в поисковых системах владельцам сайтов стоит учитывать советы от Яндекс и Google:
Резюме
Грамотный URL не сможет полностью решить проблему. Важно комплексно подходить к поисковой оптимизации.