Проверка XML с большим текстовым элементом на основе XML-схемы (xsd)

Question

Мне нужно обработать XML-файлы, которые содержат потенциально большой (до 2 ГБ) контент.В этих файлах «большая» часть контента распространяется не на весь файл, а содержится в одном элементе (зашифрованный файл, закодированный в шестнадцатеричном формате).
У меня нет рычагов воздействия на источник файлов, поэтомуМне нужно разобраться с этой ситуацией.

Требуется сохранить небольшой отпечаток памяти (<500 МБ).Я смог прочитать и обработать содержимое файла в потоковом режиме, используя <a href="https://docs.python.org/3/library/xml.sax.html" rel="nofollow noreferrer"> xml.sax , который отлично справляется со своей работой.

Проблема в том, что эти файлы также должны быть проверены на соответствиеопределение схемы XML (файл .xsd), которое, похоже, не поддерживается xml.sax.
Я нашел несколько современных библиотек для проверки схемы, таких как xmlschema , но ни одной для выполнения проверкив потоковом / ленивом виде.

Кто-нибудь может порекомендовать способ сделать это?

Answer 1

В ответе Майкла Кея была замечательная идея фильтра содержимого, который может сгущать длинный текст.Это помогло мне решить мою проблему.

В итоге я написал простую программу сжатия текста, которая предварительно обрабатывает XML-файл для меня, уменьшая размер текстового содержимого в именованных тегах (например: «сохраняйте только первые 64 байтатекст в элементах 'Data' и 'CipherValue', больше ничего не трогайте ").

Полученный файл достаточно мал, чтобы передать его в валидатор, такой как xmlschema .

Если кому-то нужно что-то подобное: вот код термоусадки

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

Answer 2

Многие процессоры схемы (такие как Xerces и Saxon) работают в потоковом режиме, поэтому нет необходимости хранить данные в памяти, пока они проверяются.Тем не менее, один текстовый узел объемом 2 ГБ расширяет ограничения Java по размеру строк и массивов, и даже потоковый процессор вполне может захотеть хранить в памяти весь отдельный узел.

Если нетограничения проверки содержимого этого текстового узла (например, вам не нужно проверять, является ли он действительным xs: base64Binary), тогда я бы предложил использовать средство проверки схемы (такое как Saxon), которое принимает входные данные SAX, и предоставлять входные данные черезФильтр SAX, который устраняет или сокращает значение длинного текста.Синтаксический анализатор SAX передает текст ContentHandler несколькими частями, поэтому в синтаксическом анализаторе SAX не должно быть ограничений на размер текстового узла.Saxon попытается объединить несколько кусков в одну строку (или массив символов) и на этом этапе может потерпеть неудачу либо из-за ограничений Java, либо из-за объема доступной памяти;но если ваш фильтр обрезает большой текстовый узел, этого не произойдет.