Unicode URL декодирование
Обычный метод URL-кодирования Unicode-символа - разделить его на 2 %HH-кода. (\ u4161 => % 41% 61)
Но как Unicode распознается при декодировании? Откуда вы знаете, что % 41% 61 - это \ u4161 против \ x41 \ x61 ("Aa")?
Перед 8-битными символами, требующими кодирования, стоит % 00?
Или смысл в том, что символы Юникода должны быть потеряны / разделены?
3 ответа
Согласно Википедии:
Текущий стандарт
Общий синтаксис URI требует, чтобы новые схемы URI, которые обеспечивают представление символьных данных в URI, фактически представляли символы из незарезервированного набора без преобразования и преобразовывали все другие символы в байты в соответствии с UTF-8, а затем процентное кодирование этих значений. Это требование было введено в январе 2005 года с публикацией RFC 3986. Схемы URI, введенные до этой даты, не затрагиваются.
В текущей спецификации не рассматривается, что делать с закодированными символьными данными. Например, в компьютерах символьные данные проявляются в закодированной форме на некотором уровне и, таким образом, могут быть обработаны как двоичные данные или как символьные данные при сопоставлении с символами URI. Предположительно, это зависит от спецификаций схемы URI, чтобы учесть эту возможность и требовать того или другого, но на практике лишь немногие, если таковые вообще имеются, действительно делают.
Нестандартные реализации
Существует нестандартная кодировка символов Unicode: %uxxxx, где xxxx - это значение Unicode, представленное в виде четырех шестнадцатеричных цифр. Это поведение не определено никаким RFC и было отклонено W3C. Третье издание ECMA-262 по-прежнему включает функцию escape(строка), которая использует этот синтаксис, а также функцию encodeURI(uri), которая преобразует в UTF-8 и кодирует каждый октет в процентах.
Таким образом, похоже, что все зависит от человека, пишущего метод unencode... Разве стандарты не интересны?
Поскольку URI были введены до появления юникода или, по крайней мере, в его широком использовании, я думаю, что это очень специфический вопрос для реализации. UTF-8 кодирует ваш текст, а затем экранирование от обычного звучит как лучшая идея, поскольку это полностью обратно совместимо с любыми имеющимися системами ASCII/ANSI, хотя вы можете получить странный странный символ или два.
С другой стороны, чтобы декодировать, вы должны удалить текст и получить строку UTF-8. Если кто-то, использующий более старую систему, попытается отправить ваши данные в ASCII/ANSI, никакого вреда не будет, это уже (почти) кодировка UTF-8.
То, что я всегда делал, это сначала UTF-8 кодирует строку Unicode, чтобы сделать ее серией 8-битных символов перед экранированием любого из символов с% HH.
PS - Я могу только надеяться, что нестандартные реализации (%uxxxx) немногочисленны.