XML na tekst: jak wydobyć treść spomiędzy nawiasów ostrych
Jest taki rodzaj pliku, na który trafiasz przy budowaniu korpusu tekstowego: eksport XML czegoś naprawdę ciekawego — abstrakty z czasopism naukowych, protokoły sądowe, zdigitalizowane archiwum, dekada wpisów blogowych — gdzie proza, o którą ci chodzi, jest zakopana pod schematem, który ktoś zaprojektował w 2006 roku. Słowa tam są. Tyle że owinięte w trzy warstwy tagów z prefiksami przestrzeni nazw.
Ta strona wyciąga tę treść i oddaje sam tekst. Bez nagłówków, bez tabel, bez żadnego znacznikowania.
Dokładnie to, czego potrzebujesz, gdy celem jest model embeddingów, indeks wyszukiwania, skrypt NLP
albo dowolny pipeline, który traktuje interpunkcję jako szum. Wgraj plik .xml powyżej —
za darmo, bez rejestracji, limit 50 MB, nic nie jest przechowywane.
Co wychodzi z drugiej strony
Ekstrakcja to więcej niż wykasowanie wszystkiego między < a >. Kilka
rzeczy trzeba obsłużyć porządnie, inaczej wynik jest subtelnie zepsuty:
- Referencje encji są dekodowane. XML nie może zawierać gołego ampersandu, więc
prawdziwe dokumenty są pełne
&,<,"i form numerycznych jak’dla apostrofu typograficznego. Pozostawione bez dekodowania psują liczenie słów i sprawiają, że wyszukiwanie nic nie znajduje. Wracają jako znaki, które reprezentują. - Sekcje CDATA są rozpakowywane.
<![CDATA[ ... ]]>to sposób, w jaki XML przemyca treść zawierającą znaczniki — HTML w opisie kanału RSS, fragment SQL-a, blok JavaScriptu. Opakowanie znika, zawartość zostaje. - Węzły tekstowe złożone z samych białych znaków są odrzucane. Sformatowany („pretty-printed") XML ma między każdą parą tagów węzeł tekstowy zawierający tylko znak nowej linii i kilka spacji. Zostaw je, a wynik będzie w 60% pustymi liniami.
- Nazwy elementów znikają całkowicie. W odróżnieniu od wersji Markdown, nazwy tagów nie są tu zachowywane jako etykiety. Dostajesz wartości, nie schemat.
- Komentarze, deklaracja XML, DTD i instrukcje przetwarzania wypadają. Żadne z nich nie jest treścią.
Błąd sklejania słów — i dlaczego to ważne
Oto scenariusz awarii, na którym wykłada się większość naiwnego zdejmowania tagów, w tym sporo szybkich regeksów kopiowanych z forów. Weź treść mieszaną — tekst i elementy potomne przeplecione w tym samym rodzicu:
<p>Zobacz <ref>aneks</ref> po szczegóły</p>
Zdejmij tagi niedbale, a skończysz z „Zobaczanekspo szczegóły", bo usunięty tag pełnił rolę granicy słowa. Pójdź w drugą stronę i wstaw znak nowej linii przy każdym tagu, a zdanie zostanie pocięte na trzy fragmenty w trzech liniach. Żadne z tych wyjść nie nadaje się do użytku: pierwsze psuje tokenizację, drugie psuje segmentację zdań, a oba po cichu korumpują wszystko dalej w potoku, co zakłada, że czyta prozę.
Poprawna obsługa zostawia elementy inline w linii, a łamie ją tylko na prawdziwych granicach bloków. Jeśli używasz czegoś innego, żeby wyciągnąć tekst z pliku XML, to jest pierwsza rzecz do przetestowania — znajdź akapit z tagiem inline w środku i sprawdź, czy zdanie przeżyło.
Problem plików konfiguracyjnych
Teraz uczciwe zastrzeżenie, bo oszczędzi ci pięciu minut konsternacji. XML trzyma dane w dwóch miejscach: między tagami i w atrybutach wewnątrz nich. Ekstrakcja tekstu z definicji bierze ten pierwszy rodzaj. Bardzo popularne odmiany XML-a nie mają go prawie wcale.
Manifesty Androida, app.config z .NET, pliki builda Anta, definicje beanów Springa,
wiele SVG — te formaty upychają niemal wszystko w atrybutach. Przepuść taki plik przez ekstraktor
tekstu, a dostaniesz garść luźnych słów albo pusty plik i wygląda to, jakby narzędzie zawiodło. Nie
zawiodło; nie było tekstu w elementach do znalezienia.
Do takich plików użyj zamiast tego konwertera XML na Markdown, który zachowuje atrybuty przypięte do elementów, których dotyczą. Przełącznik formatu u góry tej strony przełącza konwerter i zabiera twój plik ze sobą, więc to jedno kliknięcie, a nie kolejny upload. Zasada kciuka: proza mieszka w elementach, ustawienia w atrybutach. Ekstrakcja tekstu jest dla tego pierwszego rodzaju.
Gdzie płaski tekst jest ewidentnie dobrym wyborem
XML to natywny format ogromnej ilości starannie skatalogowanego tekstu, głównie dlatego, że instytucje ustandaryzowały się na nim, zanim JSON w ogóle istniał. To dziedzictwo jest miejscem, w którym ten konwerter zarabia na siebie:
- Budowanie korpusów. Zrzuty abstraktów naukowych, teksty literackie w kodowaniu TEI, akta parlamentarne i prawne, katalogi muzeów i bibliotek. Sama bogata proza, cała owinięta w ciężkie schematy. Tobie chodzi o prozę.
- Embeddingi i wyszukiwanie wektorowe. Osadź surowy fragment XML-a, a realna część powstałego wektora opisuje znaczniki zamiast znaczenia — dwa dokumenty o zupełnie różnych tematach mogą wylądować blisko siebie tylko dlatego, że dzielą schemat. Zdjęcie tagów daje embeddingi o treści.
- Chunking. Dzielenie na kawałki o stałym rozmiarze tnie surowy XML w środku elementu i produkuje fragmenty z osieroconymi tagami. Płaski tekst dzieli się na granicach zdań i akapitów, czyli tak, jak chunker został zaprojektowany.
- Indeksowanie wyszukiwania i analiza tekstu. Częstości termów, analiza sentymentu, modelowanie tematów, ekstrakcja encji — wszystko zakłamane przez strukturalne tokeny powtarzane w każdym rekordzie.
- Ekonomia tokenów. Rozwlekłość XML-a jest nietypowa nawet wśród formatów strukturalnych, bo każda nazwa elementu jest pisana dwa razy. Zdjęcie tagów z mocno zagnieżdżonego eksportu usuwa masę tokenów, które nigdy nie niosły informacji. Licznik pod wynikiem pokazuje dokładnie ile.
Kiedy zdejmowanie tagów to zły ruch
Modele radzą sobie z surowym XML-em bez trudu — jest rozwlekły, ale jednoznaczny, i w danych treningowych jest go bardzo dużo. Konwersja to decyzja, którą podejmujesz z konkretnego powodu, a nie reguła.
- Piszesz kod pod ten dokument. Zapytania XPath, arkusz XSLT, parser SAX lub DOM, schemat. Wszystkie wymagają dokładnych nazw elementów, prefiksów przestrzeni nazw i zachowanego rozróżnienia atrybut/element. Ekstrakcja tekstu usuwa dokładnie to. Wklej fragment prawdziwego pliku.
- Odpowiedzią jest hierarchia. Jeśli pytanie brzmi, pod jakim rodzicem coś siedzi — do którego środowiska należy ustawienie, w której sekcji jest klauzula — spłaszczenie to niszczy. To robota dla Markdowna.
- Dokumenty oparte na atrybutach, jak wyżej.
Najczęściej zadawane pytania
Jak przekonwertować plik XML na tekst?
Upuść plik .xml w konwerterze powyżej, a treść spomiędzy tagów wraca jako czysta proza — bez nawiasów ostrych, bez prefiksów przestrzeni nazw, bez atrybutów. Pobierz jako .txt. Za darmo, bez rejestracji, 50 MB na plik, nic nie jest zatrzymywane.
Czy dekodowane są encje takie jak & i <?
Tak, i ma to większe znaczenie, niż brzmi. XML nie może zawierać gołego ampersandu, więc dokumenty z prawdziwego świata są gęste od &, <, " i numerycznych referencji znaków. Naiwny regeks zdejmujący tagi zostawia je wszystkie dosłownie w wyniku. Porządne parsowanie zamienia je z powrotem na znaki, które reprezentują.
Czemu nie wyciąć po prostu regeksem wszystkiego między nawiasami ostrymi?
Bo i sekcje CDATA, i wartości atrybutów zawierają znaki, które wyglądają jak znaczniki, a nimi nie są. Regeks z radością pożre zawartość bloku <![CDATA[...]]> z osadzonym HTML-em i nie ma jak odróżnić prawdziwego tagu od <, który pojawia się w cytowanym tekście atrybutu. Parsowanie ogarnia to poprawnie; dopasowywanie wzorców psuje to po cichu.
Czy wartości atrybutów przechodzą do wyniku?
Dostajesz tekst elementów; atrybuty to metadane o elemencie, a nie jego treść. Zwykle to właściwe zachowanie — chcesz abstraktu, nie wersji schematu. Boli to przy formatach, które trzymają prawdziwą treść w atrybutach, więc jeśli wynik wygląda chudo, otwórz źródło i sprawdź, czy słowa, o które ci chodziło, nie mieszkają w <tag attr="...">.
Czy to zadziała na kanałach RSS i sitemapach?
Tak — oba to XML i oba się konwertują. Kanał RSS daje tytuły, opisy i daty jako czytelny tekst, co jest szybkim sposobem na zbudowanie korpusu z archiwum bloga. Sitemapa daje listę URL-i, którą pożyteczniej przekierować gdzieś dalej, niż czytać jak prozę.
Powiązane narzędzia
Uwaga o XML-u, który spotykasz pośrednio: pliki .docx i .epub to pod spodem
spakowany XML. Możesz taki rozpakować i wrzucić tu wewnętrzne znaczniki, ale nie rób tego — są
nasycone seriami stylowania i metadanymi rewizji, które zatapiają tekst. Użyj
Word na tekst albo
EPUB na tekst, które wiedzą,
które części są treścią. Dla znaczników, które są HTML-em, a nie XML-em, jest
HTML na tekst, a dla drugiego
wielkiego formatu danych strukturalnych —
JSON na tekst.
File2Txt przyjmuje wszystko,
co obsługiwane, jeśli wolisz nie wybierać strony.
A kiedy XML siedzi w repozytorium — plik POM, deskryptor builda, fixtury testowe — konwertowanie go w pojedynkę odziera go z kontekstu. Konwerter GitHub na tekst, konwerter GitLab i konwerter katalogu lokalnego pozwalają wciągnąć XML i kod, który go czyta, do jednego wyniku, co prawie zawsze jest bardziej przydatne. Przewodnik po przygotowywaniu plików dla LLM-ów omawia przypadek ogólny.
Repo2Txt tworzy i utrzymuje v12hero, niezależny deweloper budujący natywne i webowe aplikacje stawiające prywatność na pierwszym miejscu.