Почему при создании URI из IRI браузеры не преобразуют символы, не входящие в ASCII, в UTF-8?
Из RFC-3986, раздел 2.5:
Когда новая схема URI определяет компонент, который представляет текстовые данные, состоящие из символов из универсального набора символов [UCS], данные должны сначала быть закодированы как октеты в соответствии с кодировкой символов UTF-8 [STD63]; тогда только те октеты, которые не соответствуют символам в незарезервированном наборе, должны кодироваться в процентах. Например, символ A будет представлен как "A", символ LATIN CAPITAL LETTER A WITH GRAVE будет представлен как "%C3%80", а символ KATAKANA LETTER A будет представлен как "%E3%82%A2".
Так вот, как правильно URL кодировать символы Юникода? Люди утверждают, что не-ASCII-символы в IRI должны быть преобразованы в UTF-8, прежде чем их кодировать в процентах.
Но я нашел одну учебную веб-форму с Content / Type для приложения / x-www-form-urlencoded и попытался заполнить ее не-ASCII-символами, используя четыре браузера (Firefox, Chrome Opera, IE) и посмотрел, что такое POST-запросы Я получаю в Wireshark. Оказалось, что кодировка символов%H1H2%H3H4...%HkHk+1 соответствует кодировке страницы формы при отправке формы.
Поэтому для буквы "Ж", если кодировка страницы формы установлена в UTF-8, я получаю%0D96, но если я переключаюсь на 8-битную Windows-1251, я получаю%C6, и если я переключаюсь на CP-1252, я get %26%231046, где% 26 - это &, %23 - это #, и, таким образом, я получаю XML-код Unicode 'Ж': & # 1046, поскольку в CP-1252 такой буквы нет.
Поэтому мой вопрос заключается в том, почему браузеры сначала не конвертируют IRI в UTF-8, хотя кажется, что этого требует URL RFC?
Может быть, это потому, что http:// старая URI-схема? С https://en.wikipedia.org/wiki/Percent-encoding:
Общий синтаксис URI требует, чтобы новые схемы URI, которые обеспечивают представление символьных данных в URI, фактически представляли символы из незарезервированного набора без преобразования и преобразовывали все другие символы в байты в соответствии с UTF-8, а затем процентное кодирование этих значений. Это требование было введено в январе 2005 года с публикацией RFC 3986. Схемы URI, введенные до этой даты, не затрагиваются.
Итак, сказано: схемы URI, введенные до этой даты, не затрагиваются. Но это похоже на слабое объяснение.
Кроме того, здесь https://unspecified.wordpress.com/2008/07/08/browser-uri-encoding-the-best-we-can-do/ один человек обнаружил ту же проблему, что и моя, и человек пытается объяснить ее способ, которым это все о расплывчатой спецификации HTML. Но я до сих пор не могу понять, как здесь появился стандарт HTML. В любом случае запрос выполняется браузером, и браузер должен генерировать надлежащие URI.
Спасибо за внимание.