Что такое правильный URL-адрес для кодирования символов Unicode?

Question

Я знаю о нестандартной схеме% uxxxx, но это не кажется мудрым выбором, поскольку схема была отвергнута W3C.

Некоторые интересные примеры:

Сердце характер. Если я печатаю это в моем браузере:

http://www.google.com/search?q=♥ 

Затем скопируйте и вставьте его, я вижу этот URL

http://www.google.com/search?q=%E2%99%A5 

, что делает его, кажется, как Firefox (или Safari) делает это.

urllib.quote_plus(x.encode("latin-1")) 
'%E2%99%A5' 

который имеет смысл, за исключением вещей, которые не могут быть закодированы на латинице-1, как символ тройной точки.

… 

Если я введите адрес

http://www.google.com/search?q=… 

в браузере затем скопировать и вставить, я получаю

http://www.google.com/search?q=%E2%80%A6 

назад. Который, как представляется, является результатом

urllib.quote_plus(x.encode("utf-8")) 

, который имеет смысл, поскольку ... не может быть закодирован латинским-1.

Но тогда неясно, как браузер знает, следует ли декодировать UTF-8 или Latin-1.

Так как это кажется неоднозначным:

In [67]: u"…".encode('utf-8').decode('latin-1') 
Out[67]: u'\xc3\xa2\xc2\x80\xc2\xa6' 

работы, так что я не знаю, как браузер выясняет, нужно ли декодировать, что с UTF-8 или Latin-1.

Что нужно делать с особыми символами, с которыми мне нужно иметь дело?

Answer 1

Я бы всегда кодировал в UTF-8. Из Wikipedia page on percent encoding:

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

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

Answer 2

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

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

Answer 3

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

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

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

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

Answer 4

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

Answer 5

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

Вместо этого вы указываете IRI и преобразуетесь в URI при выходе на провод.