XML в текст: достаём содержимое из-под угловых скобок
Есть особый тип файлов, который всплывает, когда вы собираете текстовый корпус: XML-выгрузка чего-то по-настоящему ценного — аннотации научных журналов, стенограммы судебных заседаний, оцифрованный архив, десять лет постов из блога — где нужная вам проза похоронена под схемой, которую кто-то спроектировал в 2006 году. Слова там есть. Просто они завёрнуты в три слоя тегов с префиксами пространств имён.
Эта страница вытаскивает содержимое и отдаёт вам только текст. Ни заголовков, ни таблиц, ни разметки
вообще. Именно это нужно, когда получатель — модель эмбеддингов, поисковый индекс, NLP-скрипт или
любой конвейер, для которого разметка — это шум. Загрузите файл .xml выше — бесплатно,
без регистрации, лимит 50 МБ, ничего не сохраняется.
Что получается на выходе
Извлечение — это больше, чем удаление всего между < и >. Несколько
вещей нужно обработать правильно, иначе результат окажется незаметно испорчен:
- Ссылки на сущности декодируются. XML не может содержать «голый» амперсанд,
поэтому реальные документы полны
&,<,"и числовых форм вроде’для типографского апострофа. Оставьте их как есть — и они испортят подсчёт слов и сломают поиск по тексту. Здесь они возвращаются в виде символов, которые обозначают. - Секции CDATA разворачиваются.
<![CDATA[ ... ]]>— это способ, которым XML протаскивает содержимое с разметкой внутри: HTML в описании RSS-ленты, фрагмент SQL, блок JavaScript. Обёртка уходит, содержимое остаётся. - Текстовые узлы из одних пробелов отбрасываются. В отформатированном XML между каждой парой тегов лежит текстовый узел, состоящий только из перевода строки и отступов. Оставьте их — и 60% вашего вывода будут пустыми строками.
- Имена элементов исчезают полностью. В отличие от Markdown-версии, здесь имена тегов не сохраняются как подписи. Вы получаете значения, а не схему.
- Комментарии, XML-декларация, DTD и инструкции обработки удаляются. Ничто из этого не является содержимым.
Баг со склеиванием слов — и почему он важен
Вот сценарий отказа, на котором спотыкается большинство наивных «вырезалок» тегов, включая массу быстрых regex-решений с форумов. Возьмём смешанное содержимое — текст и дочерние элементы, перемежающиеся внутри одного родителя:
<p>См. <ref>приложение</ref> для подробностей</p>
Уберите теги небрежно — и получите «См.приложениедля подробностей», потому что удалённый тег одновременно выполнял роль границы слова. Перегните в другую сторону, вставляя перевод строки на каждом теге, — и предложение окажется разрублено на три фрагмента в трёх строках. Ни то ни другое не годится: первое ломает токенизацию, второе — сегментацию предложений, и оба тихо портят всё, что дальше по конвейеру рассчитывает читать связную прозу.
Правильная обработка оставляет строчные элементы в строке и переносит строку только на настоящих границах блоков. Если вы пытаетесь извлечь текст из XML файла другим инструментом, проверьте именно это в первую очередь — найдите абзац со строчным тегом посередине и убедитесь, что предложение уцелело.
Проблема конфигурационных файлов
Теперь честная оговорка, которая сэкономит вам пять минут недоумения. XML хранит данные в двух местах: между тегами и в атрибутах внутри них. Извлечение текста по определению достаёт первое. А в некоторых очень распространённых XML-файлах первого почти нет.
Манифесты Android, app.config из .NET, файлы сборки Ant, определения бинов Spring,
многие SVG — там почти всё лежит в атрибутах. Прогоните такой файл через извлекатель текста — и
получите горстку случайных слов или пустой файл, и будет казаться, что инструмент сломался. Он не
сломался; просто текста в элементах не было.
Для таких файлов используйте конвертер XML в Markdown — он сохраняет атрибуты привязанными к элементам, к которым они относятся. Переключатель формата в верхней части страницы переносит вас туда вместе с вашим файлом, так что это один клик, а не повторная загрузка. Практическое правило: проза живёт в элементах, настройки — в атрибутах. Извлечение текста — для первого случая.
Где плоский текст — однозначно правильный выбор
XML — родной формат огромного массива хорошо выверенных текстов, во многом потому, что учреждения стандартизировались на нём ещё до появления JSON. Это наследие — то место, где конвертер и отрабатывает своё:
- Сборка корпусов. Выгрузки научных аннотаций, литературные тексты в разметке TEI, парламентские и юридические архивы, каталоги музеев и библиотек. Всё это богатая проза, завёрнутая в тяжёлые схемы. Вам нужна проза.
- Эмбеддинги и векторный поиск. Векторизуйте сырой кусок XML — и заметная часть получившегося вектора будет описывать разметку, а не смысл: два документа на несвязанные темы могут оказаться рядом только потому, что делят одну схему. Убрав теги, вы получаете эмбеддинги о содержании.
- Разбиение на чанки. Чанкеры с фиксированным размером режут сырой XML посреди элемента и выдают фрагменты с висящими тегами. Плоский текст делится по границам предложений и абзацев — ровно то, на что чанкер и рассчитан.
- Поисковая индексация и анализ текста. Частоты терминов, оценка тональности, тематическое моделирование, извлечение сущностей — всё это перекашивают структурные токены, повторяющиеся в каждой записи.
- Экономия токенов. Многословность XML необычна даже среди структурированных форматов: каждое имя элемента записывается дважды. Снятие тегов с глубоко вложенной выгрузки убирает массу токенов, которые никогда не несли информации. Счётчик под результатом показывает, сколько именно.
Когда снимать разметку — ошибка
Модели справляются с сырым XML без труда — он многословен, но однозначен, и его полно в обучающих данных. Конвертация — это решение, которое принимают по конкретной причине, а не правило.
- Вы пишете код, работающий с этим документом. XPath-запросы, XSLT-таблица стилей, SAX- или DOM-парсер, схема. Всему этому нужны точные имена элементов, префиксы пространств имён и различие между атрибутом и элементом. Извлечение текста удаляет ровно это. Вставьте фрагмент настоящего файла.
- Ответ — в самой иерархии. Если вопрос в том, под каким родителем что-то лежит — к какому окружению относится настройка, в каком разделе находится пункт, — уплощение это уничтожает. Это работа для Markdown.
- Документы с данными в атрибутах — см. выше.
Часто задаваемые вопросы
Как конвертировать XML файл в текст?
Перетащите .xml в конвертер выше — и содержимое между тегами вернётся в виде обычной прозы: без угловых скобок, без префиксов пространств имён, без атрибутов. Скачайте как .txt. Бесплатно, без регистрации, до 50 МБ на файл, ничего не сохраняется.
Декодируются ли сущности вроде & и <?
Да, и это важнее, чем кажется. XML не может содержать «голый» амперсанд, поэтому реальные документы усеяны &, <, " и числовыми ссылками на символы. Наивный regex, вырезающий теги, оставит всё это лежать в выводе буквально. Настоящий разбор преобразует их обратно в символы, которые они обозначают.
Почему нельзя просто вырезать всё между угловыми скобками регуляркой?
Потому что и секции CDATA, и значения атрибутов содержат символы, которые выглядят как разметка, но ею не являются. Регулярное выражение с удовольствием съест содержимое блока <![CDATA[...]]> со встроенным HTML, и оно никак не отличит настоящий тег от <, стоящего внутри значения атрибута в кавычках. Парсинг делает это правильно; сопоставление по шаблону ошибается молча.
Попадают ли в вывод значения атрибутов?
Вы получаете текст элементов; атрибуты — это метаданные об элементе, а не его содержимое. Обычно это правильно — вам нужна аннотация, а не версия схемы. Кусается это на форматах, которые хранят настоящее содержимое в атрибутах, поэтому если вывод выглядит куцым, откройте исходник и проверьте, не живут ли нужные вам слова внутри <tag attr="...">.
Сработает ли это на RSS-лентах и sitemap?
Да — и то и другое XML, и то и другое конвертируется. RSS-лента даст вам заголовки, описания и даты в виде читаемого текста — быстрый способ собрать корпус из архива блога. Sitemap даст список URL, который полезнее передать дальше по конвейеру, чем читать как прозу.
Смежные инструменты
Замечание об XML, с которым вы сталкиваетесь косвенно: файлы .docx и .epub
внутри — это XML в ZIP-архиве. Можно распаковать такой файл и скормить внутреннюю разметку сюда, но
не стоит — она насыщена стилевыми прогонами и метаданными правок, в которых тонет текст. Используйте
Word в текст или
EPUB в текст — они знают,
какие части являются содержимым. Для разметки, которая на самом деле HTML, а не XML, есть
HTML в текст, а для второго
большого формата структурированных данных —
JSON в текст.
File2Txt принимает любой
поддерживаемый формат, если не хочется выбирать страницу.
А когда XML лежит в репозитории — POM-файл, дескриптор сборки, тестовые фикстуры — конвертировать его в одиночку значит лишить контекста. Конвертер GitHub в текст, конвертер GitLab и конвертер локального каталога позволяют собрать XML и читающий его код в один вывод — а это почти всегда полезнее. Руководство по подготовке файлов для LLM разбирает общий случай.
Repo2Txt создаёт и поддерживает v12hero — независимый разработчик, который делает нативные и веб-приложения с приоритетом приватности.