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

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

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

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

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

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

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

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

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

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

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

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

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

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 ...

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

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

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

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

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

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

Не уверен, что это хорошая идея, но, как уже упоминалось в других комментариях, и, как я понимаю, многие символы Юникода действительны в 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 недействительным?

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

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

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

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

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

    $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