Просмотр восьмеричной кодировки для строки Unicode (в браузере или в инструменте OSX) - PullRequest
2 голосов
/ 17 августа 2011

В моем синтаксическом анализаторе XML есть невидимый символ.

c&

XML утверждает, что это UTF-8, но когда я пытаюсь использовать <c:import . . . charEncoding="UTF-8">

Я получаю это дружеское сообщение:

ОШИБКА: javax.servlet.jsp.JspException: java.io.CharConversionException: недопустимая кодировка utf8 в (187)

Iудалось найти источник проблемы.Это невидимый символ, расположенный между 'c' и '&'.

Я хотел бы узнать больше об этом персонаже, но, похоже, IntelliJ не может показать мне скрытые символы.,,

Мне кажется, я видел онлайн-инструмент, который конвертировал бы символы Unicode в их восьмеричные значения, но я не могу найти его снова.Если есть инструмент, который мне нужно скачать, это было бы хорошо.

Есть предложения?


ОК, друг рассказал мне о od, поэтому я попробовал:

$ echo -n "c&" | od -c
0000000    c 357 273 277 357 273 277   &                                
0000010

Так что, похоже, проблема в причинепо последовательности байтов 357 273 277

Знаем ли мы, что это за последовательность?

Ответы [ 2 ]

6 голосов
/ 18 августа 2011

В таблице ниже точки представляют разрывы между восьмеричными цифрами, а штрихи представляют разрывы между шестнадцатеричными цифрами.

Octal:      3    5   7   |  2    7   3  |  2    7   7
Binary:    11.10-1.111   | 10.11-1.011  | 10.11-1.111
Hex:         E     F     |   B     B    |   B     F

Это имеет правильную форму для действующего UTF-8.Первый фрагмент показывает два байта продолжения, а следующие два байта действительно являются байтами продолжения.Второй фрагмент первого байта и последние 6 битов каждого из следующих двух байтов образуют данные для символа Unicode.

Unicode Binary:  1111 1110 11.11 1111
Unicode Hex:      F     E    F    F

Следовательно, символом является U + FEFF, который является спецификацией(метка порядка байтов) или ZWNBSP (неразрывный пробел нулевой ширины).Обычно кодируют спецификацию в UTF-8 (в этом нет необходимости);вдвойне условно кодировать два из них подряд;и это обычно трижды, когда спецификация не является первым символом в потоке кода UTF-8.

См. FAQ по Юникоду в спецификации для получения дополнительной информации.

1 голос
/ 18 августа 2011

Нашел ответ: это был знак порядка байтов

Octal:   357       273       277
Binary: 011101111 010111011 010111111
Hex:    0xEF      0xBB      0xBF

Метка порядка следования байтов действительна в формате UTF-16, поэтому я попытался импортировать ленту как UTF-16, и она работала как чудо.

...