Что такого особенного в символе Unicode "", что он нарушает логику синтаксического анализатора на основе фигурных скобок? - PullRequest
2 голосов
/ 13 июня 2019

Я пытаюсь отладить странную проблему, надеясь, что эксперт по Юникоду здесь сможет помочь.

  • У меня есть программа отправителя (на основе Perl), которая принимает некоторую структуру данных
  • это кодирует структуру данных в запатентованный сериализованный формат, который использует фигурные скобки для кодирования данных. Вот пример сериализованной строки: {{9}{{8}{{skip_association}{{0}{}}}{{data}{{9}{{1}{{exceptions}{{9}{{1}{{-472926}{{9}{{1}{{AAAAAAYQ2}
  • затем отправляет эту сериализованную строку на сервер Java
  • Сервер Java пытается десериализовать строку обратно в структуру данных.
  • Кодирование на самом деле не имеет большого значения (imho), кроме того, что оно использует длину поля как часть кодированных данных; например {{id}{{7}9{Z928D2AA2}}} означает поле с именем «id», типа «строка» (7), длина строки 9, значение Z928D2AA2.

Проблема: Когда сериализованная структура данных содержит какой-либо конкретный символ (ы) Unicode, десериализация не выполняется.

В частности, этот символ: "" (который различные онлайн-декодеры отображают как %82 или 0x82) вызывает проблему.

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

Есть ли что-то особенное в (Unixode) символе (также известном как 0x82) , которое могло бы помешать синтаксическому анализу сериализованной строки, зависящей от фигурных скобок в качестве разделителей и известных длин полей?

К сожалению, я не могу отладить библиотеку decodig, поэтому я получаю только общее сообщение об ошибке, что декодирование не удалось, даже не зная, что с ним не получилось.

P.P.S Двойной дополнительный любопытный: когда я использовал этот символ в заголовке вопроса SO, он был напечатан в превью, но был удален, когда вопрос был опубликован !!! Когда я пытался скопировать / вставить строки в редактор, их измеренная длина была правильной по сравнению с длиной закодированной строки

P.S. Насколько мне известно, код Perl, выполняющий сериализацию, полностью совместим с Юникодом:

use open      qw(:std :utf8);    # undeclared streams in UTF-8
use charnames qw(:full :short);  # unneeded in v5.16
use Encode qw(decode);

1 Ответ

3 голосов
/ 13 июня 2019

Вы можете увидеть информацию о символах в базе данных символов Unicode;текстовый дамп этого можно найти в https://www.unicode.org/Public/UCD/latest/ucd/UnicodeData.txt, где он показывает:

0082;<control>;Cc;0;BN;;;;;N;BREAK PERMITTED HERE;;;;

Значения полей могут быть найдены в http://www.unicode.org/reports/tr44/#UnicodeData.txt (хотя, кажется, пропускаетпервое поле, которое является кодовой точкой).

Таким образом, это «другой» управляющий символ класса с двунаправленной категорией «Нейтральная граница» (что является нормальным для символа класса Cc или Cf).В этом нет ничего особенного.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...