Chuyển XML sang Markdown online miễn phí

Chuyển tệp XML sang Markdown online miễn phí. Tải tệp lên và nhận ngay kết quả sạch, sẵn sàng cho LLM. Không cần đăng ký, tối đa 50 MB, không lưu tệp.

Chuyển XML sang Markdown: bỏ thẻ, giữ cấu trúc

XML có một thói quen không định dạng nào khác chia sẻ: nó viết tên mỗi phần tử hai lần. Một lần để mở, một lần để đóng. Thêm tiền tố namespace, thêm attribute, thêm phần thụt đầu dòng cho dễ đọc, và bạn thường xuyên nhận được một file mà phần thẻ nặng hơn cả phần nội dung chúng bọc. Một catalogue sản phẩm với 200 mục có thể dài hàng nghìn dòng mà thông tin thực chỉ chừng một trang rưỡi.

Chuyển XML sang Markdown giữ lại cái cây và vứt bỏ phần nghi thức. Cấu trúc lồng nhau của phần tử trở thành các cấp heading, các phần tử anh em lặp lại trở thành danh sách hoặc bảng, và ngoặc nhọn biến mất. Tải file .xml lên ở phía trên và bạn nhận lại kết quả trong vài giây — miễn phí, không cần đăng ký, tối đa 50 MB, không lưu lại gì.

Cây phần tử biến thành gì

Quá trình chuyển đổi duyệt qua tài liệu và dịch từng cấu trúc:

  • Phần tử chứa trở thành heading. Một phần tử có phần tử con nhưng không có text riêng chính là một section. Độ sâu của nó trong cây quyết định cấp heading, nên một schema doanh nghiệp lồng năm tầng sẽ ra thành một tài liệu có dàn ý đàng hoàng.
  • Phần tử lá trở thành giá trị có nhãn. <author>Ursula Le Guin</author> đọc thành author: Ursula Le Guin. Một tên thay vì hai, không còn ngoặc.
  • Phần tử anh em lặp lại trở thành danh sách hoặc bảng — nói kỹ bên dưới, vì đó là chỗ mang lại nhiều giá trị nhất.
  • Mixed content được giữ nguyên trong dòng. Đây là trường hợp text và phần tử con xen kẽ nhau, như <para>See the <ref>appendix</ref> for details</para>. Các trình chuyển đổi ngây thơ băm nó thành mảnh vụn và bạn mất câu văn. Đúng ra nó phải đi qua thành một dòng đọc được với phần tham chiếu còn nguyên.
  • Comment, processing instruction và khai báo XML bị bỏ. Chúng không phải nội dung.

Attribute: phần người ta đánh mất mà không hay biết

XML cất dữ liệu ở hai chỗ — giữa các thẻ, và bên trong thẻ. Element text thì hiển nhiên. Attribute thì dễ bị bỏ sót, và rất nhiều cách trích xuất ngây thơ âm thầm vứt chúng đi. Điều đó không sao khi chúng là metadata kiểu id="4471". Nhưng là thảm họa khi chúng chính là dữ liệu.

Mà chuyện đó lại phổ biến. <price currency="GBP">49.99</price> vô nghĩa nếu thiếu đơn vị tiền tệ. Các định dạng cấu hình còn tệ hơn — Maven, Ant, Spring, manifest Android và file app.config của .NET thường nhét gần hết mọi thứ vào attribute, nên trích xuất chỉ lấy element text từ một file như vậy sẽ trả về một tài liệu đúng cấu trúc nhưng gần như rỗng tuếch. Nếu bạn chuyển một file cấu hình mà đầu ra ngắn đến đáng ngờ, lý do là đây.

Trong đầu ra Markdown, attribute cần nằm cạnh phần tử mà chúng thuộc về chứ không được biến mất — hiển thị như một chú thích ngắn bên cạnh giá trị, hoặc thành cột bổ sung khi phần tử nằm trong một tập lặp lại. Hãy đối chiếu màn hình đầu tiên của đầu ra với file nguồn trước khi tin tưởng giao nó việc gì quan trọng. Mười giây lướt qua đáng giá hơn một cuộc trò chuyện lộn xộn với model sau này.

Phần tử anh em lặp lại trở thành bảng

Hình dạng đẹp nhất của XML là một phần tử cha chứa nhiều con giống hệt nhau: các phần tử <item> trong RSS feed, các phần tử <row> trong bản export database, các bản ghi <employee> trong một bản dump nhân sự. Con nào cũng có cùng các phần tử con theo cùng thứ tự.

Toàn bộ chỗ đó gộp lại thành một bảng pipe Markdown duy nhất. Tên phần tử con trở thành tiêu đề cột, mỗi bản ghi thành một hàng, và việc lặp thẻ — vốn trong file thô nghĩa là viết mỗi tên trường hai lần cho mỗi bản ghi — giờ chỉ xảy ra đúng một lần, ở hàng tiêu đề. Đó là mức giảm lớn nhất bạn có thể thấy ở bất kỳ phép chuyển XML nào, và là lý do chọn Markdown thay vì text phẳng cho mọi thứ có dạng bản ghi.

Nó xuống cấp khi các bản ghi lởm chởm — phần tử tùy chọn có ở con này mà không có ở con kia, hay một con chứa khối lồng mà những con khác không có. Bạn sẽ thấy ô trống, hoặc phần lồng bị đẩy xuống dưới bảng. Nếu dữ liệu của bạn thật sự vuông vắn, export sang CSV rồi dùng trình chuyển CSV sang Markdown sẽ ra bảng sạch hơn. Còn nếu nguồn có dạng JSON chứ không phải dạng thẻ, trình chuyển JSON sang Markdown giải cùng bài toán từ hướng ngược lại.

Namespace, envelope và tạp âm doanh nghiệp

XML ngoài đời hiếm khi sạch sẽ. Có ba thứ làm nó phình to vượt xa lượng thông tin nó chứa:

  • Namespace. Các khai báo xmlns và tiền tố như soap:, xsi:, atom: hay dc: tồn tại để tránh đụng tên giữa các bộ từ vựng. Với người đọc chúng vô nghĩa. Tiền tố bị lược trong quá trình chuyển đổi nên <dc:creator> đọc thành creator. Lúc duy nhất cần để ý là khi hai namespace thật sự dùng cùng một tên cục bộ cho hai thứ khác nhau — hiếm, nhưng đáng kiểm tra nếu bạn đang trộn từ vựng.
  • SOAP envelope. Phản hồi web service bọc phần bạn cần trong Envelope và Body, thường kèm thêm các header đầy security token và dữ liệu định tuyến. Chuyển đổi cho bạn một tài liệu mà payload cuối cùng cũng lộ ra, thay vì bị chôn bốn tầng dưới đống boilerplate bạn phải nhẩm bỏ qua.
  • Tham chiếu schema. xsi:schemaLocation, khai báo DTD và các attribute validation mô tả cách kiểm tra file, chứ không phải nội dung của nó. Với mọi mục đích ở đây, chúng là nhiễu.

RSS và Atom feed nằm ở đầu dễ chịu của phổ này. Chúng đồng đều, nông, và chuyển thành một danh sách gọn gàng các mục có ngày tháng — một cách hợp lý để đưa cho model cả tháng bài viết từ một blog. Lưu ý rằng phần description của feed thường chứa HTML được escape bên trong XML, thứ sẽ xuất hiện thành markup trong đầu ra của bạn; cho nó qua trình chuyển HTML sang Markdown nếu muốn sạch, hoặc dùng Web2Txt để lấy hẳn các trang gốc cho tử tế.

Khi nào nên giữ nguyên XML thô

Nói thẳng, vì khối trang bán công cụ chuyển đổi sẽ không nói với bạn: model đọc XML tốt. Nó dài dòng, nhưng không mơ hồ và xuất hiện cực kỳ nhiều trong dữ liệu huấn luyện. Chuyển đổi là một lựa chọn, không phải yêu cầu bắt buộc.

Giữ nguyên thô khi bạn đang nhờ viết biểu thức XPath, một stylesheet XSLT, một parser hay một schema — bất cứ việc gì mà model phải tái tạo chính xác tên phần tử, tiền tố namespace và sự phân biệt giữa attribute và element. Markdown cố tình làm mượt đúng những chi tiết đó. Thay vào đó, hãy dán một đoạn tiêu biểu của file thật.

Chuyển đổi khi cần cho người đọc, khi bạn muốn hiểu nhanh một schema lạ, hay khi file thô toàn thẻ là thẻ mà bạn lại thiếu chỗ trong context. Đó là những cái lợi thật. Ngoài ra là chuyện sở thích.

Những file XML mà bạn không biết là XML

Kha khá định dạng bạn tưởng là nhị phân thực chất bên dưới là XML nén zip. Đổi tên một file .docx thành .zip, giải nén, và bạn sẽ thấy document.xml cùng một đống file relationship. EPUB cũng cùng câu chuyện: các tài liệu nội dung XHTML và một manifest gói XML trong file zip. .pptx cũng vậy, .xlsx cũng vậy.

Bạn có thể giải nén rồi tự tay chuyển phần XML bên trong. Đừng — markup nội bộ đầy các run định dạng, theo dõi revision và chỉ dẫn bố cục đủ để nhấn chìm phần chữ. Hãy dùng Word sang Markdown hoặc EPUB sang Markdown — chúng biết phần nào của đống XML đó là nội dung, phần nào là chỉ dẫn định dạng. Trang này dành cho XML mà bạn được giao đúng dưới dạng XML: feed, bản export, phản hồi API, cấu hình, trao đổi dữ liệu.

Câu hỏi thường gặp

Làm sao để chuyển XML sang Markdown?

Tải file .xml lên ở phía trên và cấu trúc tài liệu được ánh xạ sang Markdown — phân cấp phần tử thành các cấp heading, các phần tử anh em lặp lại thành danh sách hoặc bảng. Miễn phí, 50 MB mỗi file, không cần đăng ký. Nó giữ lại hình dạng của tài liệu — đó là điểm khác so với làm phẳng thành text.

Phân cấp phần tử có trở thành cấp heading không?

Đúng là ánh xạ như vậy — phần tử lồng sâu hơn thành heading sâu hơn. Cách này hợp với XML dạng tài liệu như DocBook, TEI hay bản export bài viết, nơi việc lồng nhau thật sự phản ánh section trong section. Nó dở với XML dạng dữ liệu, nơi việc lồng nhau phản ánh schema database, và bạn nhận về mười hai cấp heading để mô tả một bản ghi.

Tiền tố namespace sẽ ra sao?

Chúng bị loại khỏi đầu ra. Một heading ghi dc:title hay tei:head chẳng nói gì với người đọc và với model còn ít hơn, nên tiền tố bị lược và tên phần tử cục bộ được dùng. Nếu hai namespace trong cùng tài liệu định nghĩa cùng một tên cục bộ, chúng sẽ bị gộp làm một — hiếm, nhưng đáng xem lại nếu heading có vẻ trùng lặp.

Có hữu ích để chuyển DocBook hay DITA không?

Cho một lượt đầu tiên thì có. Văn xuôi, section, danh sách và nhấn mạnh inline chuyển qua tốt vì các định dạng đó đánh dấu chúng tường minh. Conditional profiling, content reference, entity include và phân giải tham chiếu chéo thì không sống sót — đó chính là những phần khiến định dạng này đáng dùng, và không trình chuyển đổi tổng quát nào phân giải được chúng.

Với một kho XML lớn thì nên chọn cái nào?

Text, trong đa số trường hợp. Nếu bạn đang xây embedding trên hàng nghìn bản ghi, cú pháp heading là chi phí thừa lặp lại trên mọi chunk mà chẳng lợi gì cho retrieval. Markdown xứng đáng chỗ đứng khi một người hay một model sẽ đọc một tài liệu và cần biết các section nằm ở đâu.

Hoặc chọn text thuần, và phần còn lại của bộ công cụ

Nếu bạn không muốn giữ chút cấu trúc nào — text cho embedding, chỉ mục tìm kiếm, hay số token thấp nhất có thể — hãy dùng XML sang text thuần, công cụ kéo nội dung ra khỏi các thẻ và không để lại gì khác. Nút chuyển định dạng ở đầu trang chuyển qua lại giữa hai bên và giữ nguyên file bạn đã tải, nên so sánh hai đầu ra chỉ mất một cú click. Bộ đếm token dưới phần đầu ra cho bạn biết mỗi bên tốn bao nhiêu.

Nếu file XML là một file trong cả dự án — cấu hình, descriptor build, fixture — chuyển riêng nó là đưa cho model dữ liệu mà thiếu phần code xung quanh. Trình chuyển repository GitHub sang text và trình chuyển thư mục cục bộ cho phép bạn gom file XML cùng những nơi dùng nó — thường là đơn vị hữu ích hơn. File2Txt xử lý mọi định dạng được hỗ trợ tại một chỗ, và bài hướng dẫn chuẩn bị file cho LLM bàn về các nguyên tắc chung.

Repo2Txt được xây dựng và duy trì bởi v12hero, một lập trình viên độc lập chuyên làm ứng dụng native và web đặt quyền riêng tư lên hàng đầu.