Что означает "без учета регистра" в RFC 3986 по отношению к неанглийским символам?

Question

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., что определяет, какие символы считаются заглавными, а какие - строчными (а какие символы не имеют регистра)?

Answer 1

Имена хостов, разрешенные 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

В разделе 3.1.3 rfc5894 указано, что символы не могут быть разрешены, если:

• Символ представляет собой заглавную форму или какую-либо другую форму, которая сопоставляется с другим символом путем свертывания регистра в Юникоде.