Что означает «без учета регистра» в RFC 3986 не английские символы? - PullRequest
5 голосов
/ 16 октября 2011

RFC 3986 указывает, что хост-компонент URI «нечувствителен к регистру».Однако в нем не указано, что означает «без учета регистра» в терминах символов UCS или UTF-8.

Примеры, приведенные в RFC (например, «<HTTP://www.EXAMPLE.com/> эквивалентно <http://www.example.com/>»)позвольте нам сделать вывод, что «без учета регистра» означает, по крайней мере, что символы AZ считаются эквивалентными символам 32 перед ними в наборе символов UTF-8, то есть az.Однако не упоминается о том, как следует обрабатывать символы за пределами этого диапазона.Итак, учитывая незашифрованное ненормализованное зарегистрированное имя www.OLÉ.com, я вижу три возможных формы нормализации, допустимых RFC:

  1. Строчные буквы на www.olé.com затемпроцентное кодирование на www.ol% E9.com
  2. Только строчные буквы AZ на www.olÉ.com, а затем процентное кодирование на www.ol% C9.com
  3. процентное кодирование на www.OL% C9.com, а затем строчные буквы, не закодированные в процентах, на сайт www.ol% C9.com, что дает тот же результат, что и 2.

Итак, вопрос: что правильно?Если это случай 1. Что определяет, какие символы считаются заглавными, а какие строчными (а какие не имеют регистра)?

1 Ответ

1 голос
/ 30 октября 2015

Имена хостов разрешены DNS всегда в нижнем регистре.

невозможно иметь символы UTF-8 в именах узлов DNS (RFC 1123), однако был найден обходной путь с "интернационализированными доменными именами". Этот обходной путь обычно известен как punycode .

Punycode позволяет символам, не являющимся ASCII, представляться символами ASCII.

не-ASCII символы представлены символами ASCII, которые разрешены в метках имени хоста (буквы, цифры и дефисы).

- https://www.ietf.org/rfc/rfc3492.txt

Что касается примера, который вы предоставили в своем вопросе (www.olé.com), доменное имя, которое будет разрешено , равно , а не www.ol% E9.com.

Если вы получаете процентные знаки в имени вашего домена, это означает, что вы указали URL-адрес имени хоста, и это неверно, по крайней мере, не для разрешения.

Например, будет правильно работать с тегом a, который выглядит следующим образом:

<a href="//www.ol%C3%A9.com">Click Here</a>

Тем не менее, DNS-сервер не будет разрешать www.ol%C3%A9.com, а преобразованное имя домена в виде punycode:

Пример * * одна тысяча тридцать шесть www.ol%C3%A9.com становится www.olé.com который в punycode переводится как: www.xn--ol-cja.com Веб-браузеры обычно преобразуют заглавные буквы в строчную версию. Например, и www.olé.com, и www.olÉ.com преобразуются в одно и то же имя хоста DNS (www.xn--ol-cja.com), поскольку www.olÉ.com в нижнем регистре составляет www.olé.com. Я рекомендую два инструмента для проверки доменных имен IDN, чтобы увидеть, как выглядит доменное имя после прохождения перевода с помощью punycode: Инструмент преобразования IDN Verisign (http://mct.verisign -grs.com / ) Punycoder Punycode to Text / Unicode https://www.punycoder.com/ Инструмент IDN в Verisign намного строже. Попробуйте оба инструмента с www.olÉ.com в качестве ввода, чтобы понять, что я имею в виду. Правила для IDNA (интернационализированных доменных имен для приложений) сложны, но есть два основных RFC, на которые стоит обратить внимание: Интернационализированные доменные имена для приложений (IDNA): предыстория, объяснение и обоснование
https://tools.ietf.org/html/rfc5894 Кодовые точки Unicode и интернационализированные доменные имена для приложений
https://tools.ietf.org/html/rfc5892 rfc5894 раздел 3.1.3 указывает, что символы могут не допускаются, если: Символ является заглавной или какой-либо другой формой, которая сопоставляется с другим символом путем свертывания регистра Unicode.

...