Как правильно кодировать символы Unicode в URL?

Я всегда кодировал в UTF-8. На странице Википедии о процентном кодировании:

Общий синтаксис URI требует, чтобы новые схемы URI, обеспечивающие представление символьных данных в URI, по сути, представляли символы из незарезервированного набора без перевода и должны преобразовывать все другие символы в байты в соответствии с UTF-8, а затем процентное кодирование этих значений. Это требование было введено в январе 2005 г. с публикацией RFC 3986. Схемы URI, представленные до этой даты, не затрагиваются.

Похоже, что из-за того, что в прошлом были другие общепринятые способы кодирования URL-адресов, браузеры пытаются использовать несколько методов декодирования URI, но если вы тот, кто выполняет кодирование, вам следует использовать UTF-8.

Общее правило, по-видимому, заключается в том, что браузеры кодируют ответы формы в соответствии с типом содержимого страницы, с которой была отправлена ​​форма. Это предположение, что если сервер отправляет нам «text / xml; charset = iso-8859-1», то они ожидают ответов в том же формате.

Если вы просто вводите URL-адрес в строке URL-адреса, тогда у браузера нет базовой страницы для работы, и поэтому ему просто нужно угадывать. Итак, в этом случае кажется, что он все время выполняет utf-8 (поскольку оба ваших ввода производят трехоктетные значения формы).

Печальная правда заключается в том, что AFAIK не существует стандарта для набора символов, значения в строке запроса или действительно любые символы в URL-адресе должны интерпретироваться как. По крайней мере, в случае значений в строке запроса нет оснований предполагать, что они обязательно действительно соответствуют символам.

Известная проблема заключается в том, что вы должны указать своей серверной платформе, какой набор символов вы ожидаете, что строка запроса будет закодирована как --- например, в Tomcat вам нужно вызвать request.setEncoding () (или другой аналогичный метод) перед вызовом любого из методов request.getParameter (). Нехватка документации по этому вопросу, вероятно, отражает недостаточную осведомленность о проблеме среди многих разработчиков. (Я регулярно спрашиваю собеседников Java, в чем разница между Reader и InputStream, и регулярно получаю пустые взгляды)

IRI (RFC 3987) - это последний стандарт, заменяющий URI / URL (RFC 3986 и старше) стандартов. URI / URL изначально не поддерживают Unicode (ну, RFC 3986 добавляет положения для будущих URI / Протоколы на основе URL-адресов для его поддержки, но не обновляют предыдущие RFC). Схема «% uXXXX» является нестандартным расширением, позволяющим использовать Unicode в некоторых ситуациях, но не всеми реализована повсеместно. IRI, с другой стороны, полностью поддерживает Unicode и требует, чтобы текст был закодирован как UTF-8, прежде чем он будет закодирован в процентах.

IRI не заменяют URI, потому что только URI (фактически, ASCII) допустимы в некоторых контекстах, включая HTTP.

Вместо этого вы указываете IRI, и он преобразуется в URI при подключении к сети.

Первый вопрос: что вам нужно? Кодировка UTF-8 - это довольно хороший компромисс между взятием текста, созданного с помощью дешевого редактора, и поддержкой большого количества языков. Что касается браузера, определяющего кодировку, ответ (от веб-сервера) должен сообщить браузеру кодировку. Тем не менее, большинство браузеров будут пытаться угадать, потому что во многих случаях это либо отсутствует, либо неверно. Они предполагают, читая некоторый объем потока результатов, чтобы увидеть, есть ли символ, не вписывающийся в кодировку по умолчанию. В настоящее время все браузеры (? Я не проверял это, но это довольно близко к истине) по умолчанию использует utf-8.

Поэтому используйте utf-8, если у вас нет веских причин использовать одну из многих других схем кодирования.