Игнорирование содержимого не допускается в завершающем разделе SAXException

Я использую Java DocumentBuilder.parse(InputStream) для анализа XML-документа. Иногда я получаю искаженные XML-документы, в которых есть лишний мусор после последнего >, который вызывает SAXException: Content is not allowed in trailing section. (В случаях, которые я видел, мусор — это просто один или несколько нулевых байтов.)

Мне все равно, что будет после финального >. Есть ли простой способ проанализировать весь XML-документ в Java и игнорировать любой конечный мусор?

Обратите внимание, что под «игнорировать» я не подразумеваю просто перехват и игнорирование исключения: я имею в виду игнорировать конечный мусор, не выдавать исключение и возвращать объект Document, поскольку XML до включения окончательного > действителен.


java exception xml sax
person Paul J. Lucas    schedule 11.05.2010    source источник

Ответы (2)


arrow_upward
8
arrow_downward

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

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

Если проблема сложнее, чем просто нулевые символы, вам, конечно, понадобится более сложный фильтр, что может быть сложно.

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

person Don Roby    schedule 12.05.2010

arrow_upward
-5
arrow_downward

Нет. Документ, содержащий завершающие символы, не является XML-документом. Исправьте отправителя.

person Brett Kail    schedule 11.05.2010
comment
Я не могу контролировать отправителя. И ваш ответ не в духе Будьте либеральны в том, что вы принимаете, и строги в том, что вы излучаете. - person Paul J. Lucas; 12.05.2010
comment
Вы спросили, есть ли простой способ проанализировать весь XML-документ в Java и игнорировать весь мусор в конце? Ответ нет, не существует, и я назвал причину. Возможно, вы ищете home.ccil.org/~cowan/XML/tagsoup ? Может быть, вы знаете, что ваш XML не имеет CDATA, и вы можете реализовать примитивную оболочку inputStream? Я не уверен, какой ответ вы ищете. - person Brett Kail; 12.05.2010
comment
Каждый анализатор XML отслеживает каждый элемент и знает, когда указанный элемент был закрыт, анализируя › его закрывающего тега. Это означает, что каждый синтаксический анализатор XML также знает последний элемент ›, когда он его видит, потому что первый элемент был уравновешен его закрывающим тегом. В этот момент я хочу, чтобы синтаксический анализатор просто остановился. Вы делаете это более сложным, чем есть на самом деле. - person Paul J. Lucas; 12.05.2010
comment
Я не пытаюсь сделать это сложным. Я понимаю, что то, что вы хотите, концептуально просто, но этого не существует. Вам доступны только следующие варианты: использовать несовместимый (или не-XML) синтаксический анализатор, изменить существующий синтаксический анализатор XML, чтобы он делал то, что вы хотите, или выполнить предварительную обработку ввода. - person Brett Kail; 12.05.2010
comment
Надеюсь, отрицательный голос можно будет удалить теперь, когда кто-то другой дал тот же ответ. - person Brett Kail; 12.05.2010
comment
Возможно, они дали один и тот же базовый ответ, но, по крайней мере, они предложили способы фактического решения проблемы, тогда как ваш первоначальный ответ не что иное, как краткое и бесполезное исправление отправителя. - person Paul J. Lucas; 12.05.2010
comment
Другой ответ предлагает вам либо: (1) предварительно обработать ввод, либо (2) исключить исключения. Вы прямо заявили, что № 2 не вариант. Вы отклонили № 1, когда я предложил это в комментарии, поэтому я не стал обновлять свой ответ. Ну что ж. - person Brett Kail; 12.05.2010