Я работаю с некоторым существующим кодом, который использует обычный картограф Джексона и читает строку из файла JSON следующим образом:

mapper.readValue(line, new TypeReference<Map<String, Object>>(){});

Сам json довольно большой и технически плохо отформатирован, потому что файл содержит такой json (без запятых между массивными json-объектами):

{...}

{...}

{...}

Я вставил некоторые окончания строки «возвращает» в первый объект, чтобы лучше было его читать, поэтому теперь он выглядит так: {..., ...,

...., ...}

{...}

{...}

Вы знаете, просто сделайте небольшой отступ, чтобы хоть что-то прочесть.

В тот момент, когда я это сделал, мой модульный тест начал давать сбой:

Unexpected end-of-input within/between Object entries

Прошло много времени с тех пор, как мне приходилось иметь дело с Джексоном на таком низком уровне. Я предполагаю, что обычно он игнорирует символ EOL, если встречается что-то вроде:

{"ключ": "значение",

"ключ": "значение" ...

}

Так имеет ли это отношение к используемой настройке TypeReference?

0
Justin 19 Июн 2018 в 22:28

1 ответ

Лучший ответ

Этот TypeReference хочет создать карту, которая обычно поступает из одного объекта Json с именованными свойствами, а не из списка независимых объектов, разделенных \ n.

И, конечно же, файл, содержащий объекты json, разделенные \ n, не является допустимым json.

Если у вас есть код, который читает каждую строку ... до следующего \ n, затем передает этот единственный объект Джексону для анализа, а затем добавление \ n внутри объекта приведет к тому, что ваш код начнет отправлять частичные объекты Джексону, создавая такие ошибки, как вы видите.

Не могу сказать, происходит ли это с вами, но это первая идея, которая приходит в голову.

1
joshp 19 Июн 2018 в 19:38