Как в JsonSerializer.Deserialize игнорировать ошибки десериализации битого json?
Есть битый json с информацией, которую надо десериализировать хотя бы частично. Как обойти ошибки?
Например, может быть не закрыта фигурная скобка в конце или внутри текстового значения кавычки заэкранированы не \", а "\.
Из таких мутантских файлах на входе надо как-то вытащить хотя бы часть информации...
Вроде у Newtonsoft.Json в опциях было свойство Error, которое позволяло настроить обработчик ошибок и там их обходить, а как такое можно сделать для System.Text.Json?
При этом сами VS и VSC такие файлы разбирают, с ругательствами, конечно, но все же...
rPman. Это файлы описаний пакетов от внешних разрабов. И они, к сожалению, бывают криворукими. Пока из около 1000 файлов было выявлено две ошибки: с неправильным экранированием кавычек внутри строки и с незакрытой скобкой в конце документа, но там может быть все, что угодно.
точно обработка сломаных файлов не нативна
p.s. уже вижу как я бы 1000 файлов с глюками разбирал бы с помощью llm модели, просить ее проанализировать файл, найти ошибку, описать ее, разработать код для исправления этой ошибки, выполнить его, и так для каждого
Роман Кофф, исправление json в общем случае абсолютно нереально и не имеет однозначного решения. Более того, повреждённый json может остаться валидным. Например, вот такой json:
{"name1":"value1", "name2": "value2"}
Он может быть результатом искажения через потерянные слеши вот такого json:
{"name1\":\"value1\", \"name2": "value2"}
Наблюдая первый json, мы не можем не быть уверены, что на самом деле изначально это был не второй. И оба при этом валидны!
Если у нас в качестве значения внутри json выступает другой json (как строка), особенно сложный то при опускании слешей может начаться какой угодно хаос. В том числе новый json может оказаться валидным или "почти валидным", исправимым каким-то другим способом, к которому может прийти и алгоритм.
Поэтому для реального исправления нужно хорошо разобраться в том, как именно произошло искажение. Плюс понимание особенностей данных: валидные имена ключей, валидация значений и их типов (можно написать json-схему и на разные попытки исправления её прогонять).
Вообще, с подобной задачей народ сталкивался на кривых csv. Там реально всё ещё хуже, потому что формат очень нестрогий, а запятые в неэкранированном значении делают абсолютно неоднозначным способ разделения строки на поля. В том числе крайне тяжёлым. Например, пусть в файле рядом адрес регистрации и адрес фактического проживания и значения не закавычены. Определить запятую, которая разделяет значения с семантикой "адрес", довольно сложно, учитывая, что адреса часто пишут довольно неформальным способом. И это ещё можно как-то угадать, понимая семантику значения - что это адрес. А если там просто перечисления и идентификация невозможна? Если рядом любимые блюда и нелюбимые блюда, то как понять, что уже закончился список любимых и начался список нелюбимых?
shurshur, csv строгий, просто его неофиты делают через тупой print без простейшего replace, а еще там \n внутри строг разрешено, вот где жесть.
по поводу неоднозначности распознования json с ошибками, да конечно с академической точки зрения распознать нельзя, но на практике по самим данным много что можно понять, т.е. человек глазами, взглянув на реальных json (а не созданный специалистом 'для прикола') вполне может понять где ошибка, не говоря о том что если такие файлы создавались автоматически, ошибка будет не в одном месте.
поэтому я и сказал, было бы очень интересно натравить на такие испорченные json ИИ, по указанному выше пайплайну.
rPman, "строгий csv" реализуют как попало и в том же модуле csv в python есть даже специальное понятие "диалекта". Из вопиющего, что встречал - Oracle SQL Developer не может импортировать собственный экспорт csv, если в значении поля встречается перенос строки.
Да и генерят csv часто без каких-то решений, просто тупой записью значений через запятую (или другой разделитель). Да чего уж там - я сам так делаю, когда надо быстро и просто и я уверен, что это не вызовет проблем.
Это файлы описаний пакетов от внешних разрабов. И они, к сожалению, бывают криворукими.
Может тогда автоматизировать процесс и когда принимаете эти описания пакетов - валидировать их и выдавать этому внешнему разрабу список ошибок, которые нужно исправить?
Легче изначально не допустить брака, чем потом его исправлять костылями.
А пока руками их поправить. Их много?
По изначальному описанию подумал, что у вас там жёсткий диск в ядерном реакторе побывал
Василий Банников, да нет))) Файлы вообще ко мне отношения не имеют. Я их никак контролировать не могу. Только скачивать.
Это метафайлы описаний пакетов расширений для игры-песочницы. Их публикует кто угодно и как угодно. Но если эти пакеты нормально съедает игровой движок, то и я должен иметь возможность их нормально забирать.
(когда посмотрел, что там разрабы фигачат, если честно, волосы дыбом встали...)
Роман Кофф, если такие файлы не просто генерятся, но и кем-то систематически читаются, то логично, что надо не просто файлики исправить, а найти/написать нормальный их читатель. Вероятно даже, там не надо json-читалку привлекать, потому что превращать "это" в json слишком накладно и сложно, а сами файлы, вероятно, не требуют реализации всей логики json.
Вообще, если бы был показан пример такого файла, советы могли бы быть более целенаправленными.
