Unicode URL декодирование

Question

Обычный метод URL-кодирования Unicode-символа - разделить его на 2% HH-кода. ( \ u4161 => % 41% 61 )

Но как распознается юникод при декодировании? Откуда вы знаете, что % 41% 61 равно \ u4161 против \ x41 \ x61 ("Aa")?

Являются ли 8-разрядные символы, для которых требуется кодировка, с предшествующим % 00 ?

Или смысл в том, что символы Юникода должны быть потеряны / разделены?

Answer 1

Согласно Википедии :

Текущий стандарт

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

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

Нестандартные реализации

Существует нестандартная кодировка для символов Юникода:% uxxxx, где xxxx - это значение Unicode, представленное в виде четыре шестнадцатеричные цифры. Это поведение не указан ни одним RFC и имеет был отклонен W3C. Третий издание ECMA-262 до сих пор включает в себя escape (строка) функция, которая использует это синтаксис, но также кодировщик (URI) функция, которая преобразует в UTF-8 и процентов кодирует каждый октет.

Так что, похоже, что все зависит от того, кто пишет метод unencode ... Разве стандарты не интересны?

Answer 2

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

С другой стороны, чтобы декодировать, вы должны удалить текст и получить строку UTF-8. Если кто-то, использующий более старую систему, попытается отправить ваши данные в ASCII / ANSI, никакого вреда не будет, это уже (почти) кодировка UTF-8.

Answer 3

Я всегда делал, что сначала UTF-8 кодирует строку Unicode, чтобы сделать ее серией 8-битных символов, прежде чем экранировать любой из этих с% HH.

P.S. - Я могу только надеяться, что нестандартные реализации (% uxxxx) немногочисленны.