Konwertuj XML na Markdown online bezpłatnie

Konwertuj pliki XML na Markdown online za darmo. Prześlij plik i od razu otrzymaj czysty wynik gotowy dla LLM. Bez rejestracji, do 50 MB na plik, nic nie jest zapisywane.

XML na Markdown: tagi wypadają, hierarchia zostaje

XML ma nawyk, którego nie dzieli żaden inny format: nazwę każdego elementu zapisuje dwa razy. Raz przy otwarciu, raz przy zamknięciu. Dodaj prefiksy przestrzeni nazw, dodaj atrybuty, dodaj wcięcia, które czynią go czytelnym, i regularnie kończysz z plikiem, w którym tagi ważą więcej niż treść, którą opakowują. Katalog produktów z 200 pozycjami potrafi ciągnąć się przez tysiące linii i wciąż zawierać jakieś półtorej strony faktycznej informacji.

Konwersja XML na Markdown zachowuje drzewo, a wyrzuca ceremonię. Zagnieżdżenie elementów staje się poziomami nagłówków, powtarzające się rodzeństwo staje się listami lub tabelami, a nawiasy ostre znikają. Wgraj plik .xml powyżej, a dostaniesz go z powrotem w kilka sekund — za darmo, bez rejestracji, limit 50 MB, nic nie jest zatrzymywane.

W co zamienia się drzewo elementów

Konwersja przechodzi dokument i tłumaczy każdą konstrukcję:

  • Elementy-kontenery stają się nagłówkami. Element z elementami potomnymi, ale bez własnego tekstu, to sekcja. Jego głębokość w drzewie wyznacza poziom nagłówka, więc korporacyjny schemat zagnieżdżony na pięć poziomów przyjeżdża jako porządnie skonspektowany dokument.
  • Elementy-liście stają się etykietowanymi wartościami. <author>Ursula Le Guin</author> czyta się jako author: Ursula Le Guin. Jedna nazwa zamiast dwóch, bez nawiasów.
  • Powtarzające się rodzeństwo staje się listami lub tabelami — o tym niżej, bo tam siedzi większość wartości.
  • Treść mieszana jest zachowywana w linii. To przypadek, w którym tekst i elementy potomne się przeplatają, jak w <para>See the <ref>appendix</ref> for details</para>. Naiwne konwertery tną to na fragmenty i tracisz zdanie. Powinno przejść jako jedna czytelna linia z nienaruszonym odnośnikiem.
  • Komentarze, instrukcje przetwarzania i deklaracja XML wypadają. Żadne z nich nie jest treścią.

Atrybuty: część, którą ludzie gubią, nie zauważając

XML przechowuje dane w dwóch miejscach — między tagami i wewnątrz nich. Tekst elementu jest oczywisty. Atrybuty łatwo przeoczyć i wiele naiwnych ekstrakcji po cichu je gubi. To w porządku, gdy są metadanymi jak id="4471". To katastrofa, gdy są ładunkiem właściwym.

A to częste. <price currency="GBP">49.99</price> jest bez sensu bez waluty. Formaty konfiguracyjne są gorsze — Maven, Ant, Spring, manifesty Androida i pliki app.config z .NET często upychają niemal wszystko w atrybutach, więc ekstrakcja z takiego pliku, biorąca tylko tekst elementów, zwraca dokument strukturalnie poprawny i niemal całkowicie pusty. Jeśli konwertujesz plik konfiguracyjny i wynik wygląda podejrzanie krótko, to jest powód.

W wyniku Markdown atrybuty powinny siedzieć obok elementu, do którego należą, a nie znikać — wyrenderowane jako krótki kwalifikator przy wartości albo jako dodatkowe kolumny, gdy element jest częścią powtarzającego się zestawu. Zanim powierzysz wynikowi coś ważnego, porównaj pierwszy ekran z oryginałem. Dziesięć sekund przeglądania bije późniejszą pogmatwaną rozmowę z modelem.

Powtarzające się rodzeństwo staje się tabelami

Najlepszy kształt XML-a to rodzic trzymający wiele identycznych dzieci: elementy <item> w kanale RSS, elementy <row> w eksporcie z bazy danych, rekordy <employee> w zrzucie kadrowym. Każde dziecko ma te same podelementy w tej samej kolejności.

To zapada się do jednej tabeli Markdown. Nazwy podelementów stają się nagłówkami kolumn, każdy rekord wierszem, a powtarzanie tagów — które w surowym pliku oznaczało zapisywanie każdej nazwy pola dwa razy na rekord — zdarza się dokładnie raz, w nagłówku. To największa pojedyncza redukcja, jaką zobaczysz przy jakiejkolwiek konwersji XML-a, i to jest powód, by dla wszystkiego o kształcie rekordów wybrać Markdown zamiast płaskiego tekstu.

Degraduje się to, gdy rekordy są nierówne — elementy opcjonalne obecne u części dzieci, albo jedno dziecko z zagnieżdżonym blokiem, którego inne nie mają. Dostaniesz dziury albo zagnieżdżoną część wypchniętą pod tabelę. Jeśli dane są naprawdę prostokątne, eksport do CSV i konwerter CSV na Markdown dają czystsze tabele. A jeśli źródło ma kształt JSON-a, a nie tagów, konwerter JSON na Markdown rozwiązuje ten sam problem z drugiej strony.

Przestrzenie nazw, koperty i korporacyjny szum

XML z prawdziwego świata rzadko bywa czysty. Trzy rzeczy nadmuchują go ponad zawartość informacyjną:

  • Przestrzenie nazw. Deklaracje xmlns i prefiksy typu soap:, xsi:, atom: czy dc: istnieją, żeby zapobiegać kolizjom nazw między słownikami. Dla czytelnika nie znaczą nic. Prefiksy są przy konwersji zdejmowane, więc <dc:creator> czyta się jako creator. Jedyny moment, kiedy warto się tym przejąć, to gdy dwie przestrzenie nazw faktycznie używają tej samej nazwy lokalnej do różnych rzeczy — rzadkie, ale sprawdź, jeśli łączysz słowniki.
  • Koperty SOAP. Odpowiedź web service'u opakowuje część, o którą ci chodzi, w Envelope i Body, często plus nagłówki pełne tokenów bezpieczeństwa i danych routingu. Konwersja daje dokument, w którym ładunek jest wreszcie widoczny, zamiast zakopany cztery poziomy w głąb w boilerplate, który trzeba w głowie przeskakiwać.
  • Odwołania do schematów. xsi:schemaLocation, deklaracje DTD i atrybuty walidacji opisują, jak plik powinien być sprawdzany, a nie co mówi. Tutaj to szum w każdym zastosowaniu.

Kanały RSS i Atom siedzą na przyjaznym końcu tej skali. Są jednolite, płytkie i konwertują się do czystej listy datowanych wpisów — rozsądny sposób, żeby podać modelowi miesiąc postów z bloga. Zauważ, że opisy w kanałach zwykle zawierają HTML zescape'owany wewnątrz XML-a, który ląduje w wyniku jako znaczniki; przepuść go przez konwerter HTML na Markdown, jeśli chcesz go czystego, albo użyj Web2Txt, żeby porządnie pobrać same strony.

Kiedy trzymać się surowego XML-a

Prosto z mostu, bo wiele stron sprzedających konwertery ci tego nie powie: modele czytają XML bez problemu. Jest rozwlekły, ale jednoznaczny i wyjątkowo dobrze reprezentowany w danych treningowych. Konwersja to wybór, nie wymóg.

Zostaw surowy, gdy prosisz o wyrażenia XPath, arkusz XSLT, parser albo schemat — o cokolwiek, gdzie model musi odtworzyć dokładne nazwy elementów, prefiksy przestrzeni nazw i rozróżnienie atrybut kontra element. Markdown celowo wygładza dokładnie te szczegóły. Zamiast tego wklej reprezentatywny fragment prawdziwego pliku.

Konwertuj, gdy ma to czytać człowiek, gdy próbujesz szybko zrozumieć nieznany schemat, albo gdy surowy plik to głównie tagi, a tobie brakuje kontekstu. To są realne zyski. Cała reszta to kwestia preferencji.

XML, o którym nie wiedziałeś, że jest XML-em

Spora liczba formatów, które uważasz za binarne, to pod spodem spakowany XML. Zmień .docx na .zip, rozpakuj, a znajdziesz document.xml plus stertę plików relacji. EPUB to ta sama historia: dokumenty treści XHTML i manifest pakietu XML w zipie. Podobnie .pptx i podobnie .xlsx.

Możesz taki rozpakować i przekonwertować XML ręcznie. Nie rób tego — wewnętrzne znaczniki są pełne serii stylowania, śledzenia zmian i instrukcji układu, które zatapiają tekst. Użyj Word na Markdown albo EPUB na Markdown, które wiedzą, które części tego XML-a są treścią, a które instrukcjami formatowania. Ta strona jest dla XML-a, którego dostałeś jako XML: kanały, eksporty, odpowiedzi API, konfiguracja, wymiana danych.

Najczęściej zadawane pytania

Jak przekonwertować XML na Markdown?

Wgraj .xml powyżej, a struktura dokumentu odwzoruje się na Markdown — hierarchia elementów staje się poziomami nagłówków, powtórzone elementy-rodzeństwo stają się listami lub tabelami. Za darmo, 50 MB na plik, bez rejestracji. Zachowuje kształt dokumentu i to jest różnica względem spłaszczenia go do tekstu.

Czy hierarchia elementów staje się poziomami nagłówków?

Tak, dokładnie takie jest odwzorowanie — element zagnieżdżony staje się głębszym nagłówkiem. Działa to dobrze dla XML-a o kształcie dokumentu, jak DocBook, TEI czy eksport artykułu, gdzie zagnieżdżenie faktycznie odzwierciedla sekcje w sekcjach. Działa słabo dla XML-a o kształcie danych, gdzie zagnieżdżenie odzwierciedla schemat bazy danych — i dostajesz dwanaście poziomów nagłówków opisujących jeden rekord.

Co się dzieje z prefiksami przestrzeni nazw?

Wypadają z wyniku. Nagłówek brzmiący dc:title albo tei:head człowiekowi nie mówi nic, a modelowi jeszcze mniej, więc prefiksy są zdejmowane i używana jest lokalna nazwa elementu. Jeśli dwie przestrzenie nazw w tym samym dokumencie definiują tę samą nazwę lokalną, zleją się w jedno — rzadkie, ale warte rzutu oka, jeśli nagłówki wyglądają na zdublowane.

Czy to się przydaje do konwersji DocBooka lub DITA?

Na pierwsze podejście — tak. Proza, sekcje, listy i wyróżnienia inline przenoszą się dobrze, bo te formaty oznaczają je wprost. Profilowanie warunkowe, referencje treści, include'y encji i rozwiązywanie odsyłaczy nie przeżywają — a to były te części, dla których ten format był wart używania, i żaden generyczny konwerter ich nie rozwiąże.

Co wybrać dla dużego korpusu XML?

W większości przypadków tekst. Jeśli budujesz embeddingi na tysiącach rekordów, składnia nagłówków to narzut powtarzany na każdym kawałku bez żadnego zysku przy wyszukiwaniu. Markdown zarabia na siebie, gdy człowiek albo model ma przeczytać jeden dokument i musi wiedzieć, gdzie są sekcje.

Zamiast tego czysty tekst — i reszta zestawu

Jeśli nie chcesz żadnej struktury — tekst pod embeddingi, indeks wyszukiwania albo najniższą możliwą liczbę tokenów — użyj XML na czysty tekst, który wyciąga treść spomiędzy tagów i nie zostawia niczego więcej. Przełącznik formatu u góry tej strony przełącza między oboma i trzyma twój plik załadowany, więc porównanie obu wyników to jedno kliknięcie. Licznik tokenów pod wynikiem mówi, ile kosztuje każdy z nich.

Jeśli XML to jeden plik w projekcie — konfiguracja, deskryptor builda, fixtura — konwertowanie go w pojedynkę daje modelowi dane bez kodu wokół nich. Konwerter repozytorium GitHub na tekst i konwerter katalogu lokalnego pozwalają zabrać XML razem z jego konsumentami, co zwykle jest bardziej użyteczną jednostką. File2Txt obsługuje każdy wspierany format w jednym miejscu, a przewodnik po przygotowywaniu plików dla LLM-ów omawia zasady ogólne.

Repo2Txt tworzy i utrzymuje v12hero, niezależny deweloper budujący natywne i webowe aplikacje stawiające prywatność na pierwszym miejscu.