Юникод символы в URL


135

В 2010 году вы бы обслуживали URL-адреса, содержащие символы UTF-8, на большом веб-портале?

Символы Юникода запрещены согласно RFC на URL (см. Здесь ). Они должны быть закодированы в процентах, чтобы соответствовать стандартам.

Тем не менее, моя главная мысль - это обслуживание некодированных символов с единственной целью иметь красивые URL-адреса, так что кодирование процентов отсутствует.

Все основные браузеры, кажется, анализируют эти URL-адреса нормально, независимо от того, что говорит RFC. Мое общее впечатление, однако, состоит в том, что это становится очень шатким, оставляя домен веб-браузеров:

  • Копирование + вставка URL-адресов в текстовые файлы, электронные письма и даже веб-сайты с другой кодировкой
  • Клиентские библиотеки HTTP
  • Экзотические браузеры, RSS-ридеры

Верно ли мое мнение, что здесь следует ожидать неприятностей, и, таким образом, это не практичное решение (пока), если вы обслуживаете нетехническую аудиторию, и важно, чтобы все ваши ссылки работали должным образом, даже если они цитируются и передаются?

Есть ли какой-то волшебный способ показывать красивые URL в HTML

http://www.example.com/düsseldorf?neighbourhood=Lörick

что может быть скопировано + вставлено с неповрежденными специальными символами, но работает правильно при повторном использовании в старых клиентах?


16
Firefox, со своей стороны, отображает символы Unicode в своей строке URL-адреса, но отправляет их на кодированный процент сервера. Кроме того, когда пользователь копирует URL-адрес из панели URL-адресов, Firefox гарантирует, что кодированный в процентах URL-адрес будет скопирован в буфер обмена.
Сиддхартха Редди

Ответы:


126

Используйте процентное кодирование. Современные браузеры позаботятся о проблемах отображения и вставки и сделают их удобочитаемыми. Например http://ko.wikipedia.org/wiki/ 위키 백과: 대문

Редактировать: когда вы копируете такой URL в Firefox, буфер обмена будет содержать закодированную в процентах форму (что, как правило, хорошо), но если вы скопируете только ее часть, она останется незакодированной.


Вау, на самом деле ты прав! Если вы вырезаете и вставляете URL-код в%, Firefox превратит его в правильную вещь для отображения.
Дин Хардинг

Вау, я не знал об этом. Скорее всего, это лучшее решение!
Пекка

33
@ Значит, это довольно недавнее изменение - в 2005 году все международные википедии выглядели как настоящие% 6D% 65% 73% 73.
Роман Старков

2
Вы можете использовать незашифрованные URL UTF-8, а именно IRI , в документах HTML5 . Если вы сделаете это, все основные браузеры поймут это и правильно отобразят в своей адресной строке.
Оливер

Какие байты отправляют современные браузеры на серверы в строке запроса GET /images/logo.png HTTP/1.1? Всегда ли они кодируют URL в процентах?
Flimm

87

Что сказал Тгр. Задний план:

http://www.example.com/düsseldorf?neighbourhood=Lörick

Это не URI. Но это IRI .

Вы не можете включить IRI в документ HTML4; тип атрибутов, подобных как href, определяется как URI, а не IRI. В любом случае некоторые браузеры будут обрабатывать IRI, но это не очень хорошая идея.

Чтобы закодировать IRI в URI, взять части пути и запроса, кодировать их в UTF-8, а затем кодировать в процентах байты не-ASCII:

http://www.example.com/d%C3%BCsseldorf?neighbourhood=L%C3%B6rick

Если в части имени хоста IRI есть не-ASCII символы, например. вместо этого http://例え.テスト/они были закодированы с использованием Punycode .

Теперь у вас есть URI. Это ужасный URI. Но большинство браузеров скрывают это для вас: скопируйте и вставьте его в адресную строку или перейдите по ссылке, и вы увидите, что оно отображается с оригинальными символами Юникода. Википедия использует это годами, например:

http://en.wikipedia.org/wiki/ɸ

Единственный браузер, поведение которого непредсказуемо и не всегда отображает симпатичную версию IRI ...

...Ну ты знаешь.


31
Я знаю. Однажды кто-то должен взять большой клуб и ударить тех разработчиков Lynx по голове. Спасибо за отличную справочную информацию.
Пекка

2
@bobince Единственный бот (перенесенный в 2013), который также не может обрабатывать URI без IRI, это ... ... ну, вы знаете: bingbot! Пойди разберись.
Том Харрисон

1
HTML5 наконец-то поддерживает IRI. Более подробную информацию о предмете можно найти в этом ответе на связанный вопрос .
Оливер

5
Re: IE не всегда отображает симпатичные IRI - они защищают пользователей от фишинговых атак на основе гомографий. Посетите w3.org/International/articles/idn-and-iri (в частности, раздел «Доменные имена и фишинг») и blogs.msdn.com/b/ie/archive/2006/07/31/684337.aspx
codingoutloud

2
Доменные имена не имеют к этому никакого отношения. Все браузеры запрещают широкий спектр символов для предотвращения фишинга. Отображение не-ASCII символов в части пути или строки запроса не создает подобную уязвимость. IE просто не удосужился реализовать это. (И Firefox - единственный, кто реализовал его и для фрагмента).
Tgr

16

В зависимости от вашей схемы URL, вы можете сделать кодированную часть UTF-8 "не важной". Например, если вы посмотрите на URL переполнения стека, они имеют следующую форму:

http://stackoverflow.com/questions/2742852/unicode-characters-in-urls

Однако серверу на самом деле все равно, если вы получите деталь после неправильного идентификатора, так что это также работает:

http://stackoverflow.com/questions/2742852/ こ れ は, こ れ を 日本語 の テ キ ス ト で す

Так что если бы у вас был такой макет, то вы могли бы потенциально использовать UTF-8 в части после идентификатора, и это не имело бы никакого значения, если бы оно было искажено. Конечно, это, вероятно, работает только в определенных условиях ...


Хм, очень умное мышление! Он по- прежнему может быть , что некоторые клиенты не подавиться персонажами , независимо от того , где они расположены в строке, но это было бы устранить все проблемы , связанные с обычной подтасовкой , когда копирование + вставка URL, который я думаю , это самое важная часть. Еще не посмотрел URL-адрес SO. Спасибо!
Пекка

ну, это все еще оставляет слово «вопросы» непереведенным, плюс есть вещи после хэша #, который следует за целым URL, хотя очень хороший трюк !!
Евгений

4
の 翻 訳 機 を 使 っ て そ の の の の の 作 っ た ね
G

6

Не уверен, что это хорошая идея, но, как уже упоминалось в других комментариях, и, как я понимаю, многие символы Юникода действительны в HTML5-URL .

Например, в hrefдокументах говорится http://www.w3.org/TR/html5/links.html#attr-hyperlink-href :

Атрибут href в элементах a и area должен иметь значение, которое является допустимым URL-адресом, потенциально окруженным пробелами.

Тогда определение «действительного URL» указывает на http://url.spec.whatwg.org/ , который определяет кодовые точки URL как:

ASCII буквенно-цифровой, "!", "$", "&", "'", "(", ")", "*", "+", ",", "-", ".", "/" , ":", ";", "=", "?", "@", "_", "~" и кодовые точки в диапазонах U + 00A0 до U + D7FF, U + E000 до U + FDCF , U + FDF0 до U + FFFD, U + 10000 до U + 1FFFD, U + 20000 до U + 2FFFD, U + 30000 до U + 3FFFD, U + 40000 до U + 4FFFD, U + 50000 до U + 5FFFD, U +60000 до U + 6FFFD, U + 70000 до U + 7FFFD, U + 80000 до U + 8FFFD, U + 90000 до U + 9FFFD, U + A0000 до U + AFFFD, U + B0000 до U + BFFFD, U + C0000 до U + CFFFD, от U + D0000 до U + DFFFD, от U + E1000 до U + EFFFD, от U + F0000 до U + FFFFD, от U + 100000 до U + 10FFFD.

Затем термин «кодовые точки URL» используется в нескольких частях алгоритма синтаксического анализа, например, для относительного состояния пути :

Если c не является точкой кода URL и не "%", ошибка синтаксического анализа.

Также валидатор http://validator.w3.org/ проходит для URL, например "你好", и не проходит для URL с символами, такими как пробелы."a b"

Связанный: Какие символы делают URL недействительным?


Но оба URL ( "你好"и "a b") должны быть закодированы в процентах при выполнении HTTP-запроса, верно?
Утку

@Utku для "a b"я уверен , что да , так как пространство не в списке разрешенных выше. Ибо "你好", определенно, это лучшая идея для процентного кодирования, но я не знаю, является ли это просто вопросом «реализации не достаточно хороши» или «стандарт так говорит». Стандарт HTML, кажется, разрешает эти символы. Но я думаю, что это определяется стандартом HTTP, а не HTML. См. Также: stackoverflow.com/questions/912811/…
Сиро Сантилли 郝海东 冠状 病 六四 事件

Да, я думал о стандарте HTTP, а не HTML.
Утку

5

Поскольку все эти комментарии верны, следует отметить, что поскольку ICANN одобрила арабские (персидские) и китайские символы для регистрации в качестве доменного имени, все компании-производители браузеров (Microsoft, Mozilla, Apple и т. Д.) Должны поддержка Unicode в URL без какой-либо кодировки, и они должны быть доступны для поиска в Google и т. д.

Таким образом, эта проблема будет решена как можно скорее.


2
@Nasser: True - у нас теперь есть и специальные символы в немецких доменах, но они кодируются в символы ASCII с использованием Punycode . Хотя они наверняка будут работать в основных браузерах, пройдет много времени, прежде чем каждая клиентская библиотека HTTP и экзотическое приложение смогут работать с не кодированными символами Unicode.
Пекка

@Pekka, я не уверен, но, как я слышал, все браузеры должны поддерживать Unicode URL в 4-м квартале 2010 года. (Я не уверен)
Nasser Hadjloo

Проблема осложняется тем, что не каждый пользовательский агент является веб-браузером. Самый крупный пример - сам Google: он не использует обычные веб-браузеры для сканирования. То же самое можно сказать и о многих библиотеках для взаимодействия с API и т. Д. Возможно, даже в вашей файловой системе прямо сейчас.
Корнелиус

1

Используйте процентную форму . Некоторые (в основном старые) компьютеры, работающие под управлением Windows XP, например, не поддерживают Unicode, а скорее кодировки ISO. Вот почему были изобретены процентные URL-адреса. Кроме того, если вы дадите пользователю напечатанный на бумаге URL-адрес, содержащий символы, которые нелегко набрать, этому пользователю может быть сложно набрать его (или просто проигнорировать). Процентно-закодированная форма может даже использоваться на многих из самых старых машин, которые когда-либо существовали (хотя они, конечно, не поддерживают Интернет).

Однако есть и обратная сторона: символы в процентном кодировании длиннее оригинальных, что может привести к очень длинным URL-адресам. Но просто попробуйте проигнорировать это или используйте сокращение URL ( в этом случае я бы порекомендовал goo.gl , который создает URL длиной 13 символов). Кроме того, если вы не хотите регистрировать учетную запись Google, попробуйте bit.ly (bit.ly делает несколько длинных URL-адресов длиной 14 символов).


Почему я хочу поддерживать устаревшие компьютеры, которые все еще используют Windows XP?
Матеус Фелипе

0

Для меня это правильный путь, это просто сработало:

    $linker = rawurldecode("$link");
    <a href="<?php echo $link;?>"   target="_blank"><?php echo $linker ;?></a>

Это сработало, и теперь ссылки отображаются правильно:

http://newspaper.annahar.com/article/121638 -معرض - جوزف-حرب-في-غاليري-جانين-ربيز-لوحاته-الجدية-تبحث-وتكتشف-وتفرض-الاحترام

Ссылка найдена на:

http://www.galeriejaninerubeiz.com/newsite/news


2
«ссылки отображаются правильно» - за исключением того, что анализатор разметки StackOverflow не интерпретирует URL-адреса как задумано!
MrWhite
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.