Chuyển XML sang text: lấy nội dung ra khỏi rừng thẻ ngoặc nhọn
Khi xây dựng một kho ngữ liệu văn bản, bạn sẽ gặp một kiểu file rất đặc trưng: một bản export XML chứa nội dung thực sự đáng giá — tóm tắt bài báo khoa học, biên bản phiên tòa, một kho lưu trữ đã số hóa, cả chục năm bài blog — nhưng phần văn xuôi bạn cần lại bị chôn dưới một schema ai đó thiết kế từ năm 2006. Chữ vẫn nằm trong đó, chỉ có điều bị bọc trong ba lớp thẻ kèm tiền tố namespace.
Trang này lấy phần nội dung đó ra và trả về đúng phần chữ, không hơn. Không heading, không bảng,
không còn bất kỳ loại markup nào. Đây là thứ bạn cần khi đích đến là một model embedding, một chỉ mục
tìm kiếm, một script NLP, hay bất kỳ pipeline nào coi ký tự đánh dấu là nhiễu. Tải file
.xml lên ở phía trên — miễn phí, không cần đăng ký, giới hạn 50 MB, không lưu lại gì.
Đầu ra trông như thế nào
Trích xuất không đơn giản là xóa mọi thứ nằm giữa < và >. Có mấy
chuyện phải xử lý cho đúng, nếu không đầu ra sẽ sai một cách âm thầm:
- Các entity reference được giải mã. XML không cho phép dấu & đứng trần, nên
tài liệu thực tế đầy rẫy
&,<,"và các dạng số như’cho dấu nháy cong. Nếu không giải mã, chúng làm sai lệch số đếm từ và khiến tìm kiếm không khớp. Ở đây chúng được trả về đúng ký tự mà chúng đại diện. - Các khối CDATA được bóc vỏ.
<![CDATA[ ... ]]>là cách XML "tuồn" nội dung chứa markup — HTML bên trong description của RSS, một đoạn SQL, một khối JavaScript. Lớp vỏ bị bỏ, phần ruột được giữ. - Các text node chỉ chứa khoảng trắng bị loại. XML được pretty-print có một text node giữa mỗi cặp thẻ, bên trong chỉ là một ký tự xuống dòng và vài dấu cách. Giữ chúng lại thì 60% đầu ra của bạn là dòng trống.
- Tên phần tử biến mất hoàn toàn. Khác với bản Markdown, tên thẻ ở đây không được giữ lại làm nhãn. Bạn nhận về giá trị, không phải schema.
- Comment, khai báo XML, DTD và processing instruction đều bị bỏ. Chúng không phải là nội dung.
Lỗi dính chữ, và vì sao nó quan trọng
Đây là kiểu lỗi mà hầu hết cách bóc thẻ ngây thơ đều mắc phải, kể cả rất nhiều đoạn regex chữa cháy người ta copy từ diễn đàn. Xét mixed content — văn bản và phần tử con xen kẽ trong cùng một phần tử cha:
<p>See the <ref>appendix</ref> for details</p>
Bóc thẻ cẩu thả và bạn có thể nhận về "See theappendixfor details", vì cái thẻ bạn vừa xóa đang đóng vai trò ranh giới giữa hai từ. Làm ngược lại — chèn xuống dòng ở mọi vị trí có thẻ — thì câu văn bị băm thành ba mảnh trên ba dòng. Cả hai đều không dùng được: kiểu thứ nhất phá tokenization, kiểu thứ hai phá việc tách câu, và cả hai đều âm thầm làm hỏng mọi thứ phía sau vốn mặc định mình đang đọc văn xuôi.
Xử lý đúng là giữ phần tử inline nằm nguyên trong dòng và chỉ xuống dòng ở ranh giới block thật sự. Nếu bạn đang dùng công cụ khác để trích xuất nội dung văn bản từ file XML, đây là thứ đầu tiên cần kiểm tra — tìm một đoạn văn có thẻ inline nằm giữa và xem câu văn có còn nguyên vẹn không.
Vấn đề với file cấu hình
Giờ đến lời cảnh báo thẳng thắn, vì nó sẽ giúp bạn đỡ mất năm phút hoang mang. XML chứa dữ liệu ở hai chỗ: giữa các thẻ, và trong attribute bên trong thẻ. Trích xuất văn bản, theo đúng định nghĩa, chỉ lấy loại thứ nhất. Có những loại XML rất phổ biến gần như không có gì ở đó cả.
Manifest của Android, app.config của .NET, file build Ant, định nghĩa bean của Spring,
rất nhiều file SVG — tất cả nhét gần hết mọi thứ vào attribute. Cho một file như vậy qua trình trích
xuất văn bản, bạn nhận lại vài từ rời rạc, hoặc một file rỗng, và trông cứ như công cụ bị lỗi. Không
phải — chỉ là không có element text nào để tìm.
Với những file đó, hãy dùng trình chuyển XML sang Markdown thay thế — nó giữ attribute gắn liền với phần tử mà chúng mô tả. Nút chuyển định dạng ở đầu trang sẽ chuyển bạn sang và mang theo cả file, nên chỉ mất một cú click thay vì phải upload lại. Quy tắc nhanh: văn xuôi nằm trong phần tử, thiết lập nằm trong attribute. Trích xuất văn bản dành cho loại thứ nhất.
Khi nào text phẳng rõ ràng là lựa chọn đúng
XML là định dạng gốc của một lượng khổng lồ văn bản được biên tập kỹ, phần lớn vì các tổ chức đã chuẩn hóa trên nó từ trước khi JSON ra đời. Chính di sản đó là nơi trình chuyển đổi này phát huy tác dụng:
- Xây dựng kho ngữ liệu. Các bản dump tóm tắt học thuật, văn bản văn học mã hóa theo TEI, hồ sơ nghị viện và pháp lý, danh mục bảo tàng và thư viện. Toàn văn xuôi chất lượng, toàn bị bọc trong schema nặng nề. Thứ bạn cần là văn xuôi.
- Embedding và tìm kiếm vector. Embed một đoạn XML thô và một phần đáng kể của vector thu được mô tả markup chứ không phải ý nghĩa — hai tài liệu về hai chủ đề chẳng liên quan có thể nằm cạnh nhau chỉ vì dùng chung schema. Bóc thẻ đi thì embedding mới nói về nội dung.
- Chunking. Bộ chia chunk theo kích thước cố định sẽ cắt XML thô ngay giữa phần tử và tạo ra các mảnh với thẻ mồ côi. Text phẳng tách theo ranh giới câu và đoạn — đúng thứ bộ chia chunk được thiết kế cho.
- Đánh chỉ mục tìm kiếm và phân tích văn bản. Tần suất từ, chấm điểm cảm xúc, topic modelling, trích xuất thực thể — tất cả đều bị lệch bởi các token cấu trúc lặp lại trên mọi bản ghi.
- Tiết kiệm token. XML rườm rà bất thường ngay cả so với các định dạng có cấu trúc khác, vì mỗi tên phần tử được viết hai lần. Bóc thẻ khỏi một bản export lồng sâu loại bỏ được rất nhiều token vốn chẳng mang thông tin gì. Bộ đếm dưới phần đầu ra cho bạn thấy chính xác là bao nhiêu.
Khi nào bóc thẻ là sai lầm
Các model xử lý XML thô không mấy khó khăn — nó dài dòng nhưng không mơ hồ, và trong dữ liệu huấn luyện có rất nhiều. Chuyển đổi là một quyết định có lý do, không phải một quy tắc.
- Viết code làm việc trực tiếp với tài liệu. Truy vấn XPath, một stylesheet XSLT, parser SAX hoặc DOM, một schema. Tất cả đều cần tên phần tử chính xác, tiền tố namespace và sự phân biệt attribute/element được giữ nguyên. Trích xuất văn bản xóa đúng những thứ đó. Hãy dán một đoạn của file thật.
- Khi câu trả lời nằm ở cấu trúc phân cấp. Nếu câu hỏi là thứ gì nằm dưới phần tử cha nào — một thiết lập thuộc môi trường nào, một điều khoản nằm trong mục nào — thì làm phẳng sẽ phá hủy nó. Đó là việc cho Markdown.
- Tài liệu nặng về attribute, như đã nói ở trên.
Câu hỏi thường gặp
Làm sao để chuyển file XML sang text?
Thả file .xml vào trình chuyển đổi phía trên và phần nội dung giữa các thẻ được trả về dưới dạng văn xuôi thuần — không ngoặc nhọn, không tiền tố namespace, không attribute. Tải xuống dưới dạng .txt. Miễn phí, không cần đăng ký, 50 MB mỗi file, không lưu lại gì.
Nó có giải mã các entity như & và < không?
Có, và chuyện này quan trọng hơn vẻ ngoài của nó. XML không thể chứa dấu & đứng trần, nên tài liệu thực tế dày đặc &, <, " và các tham chiếu ký tự dạng số. Một đoạn regex bóc thẻ ngây thơ sẽ để nguyên tất cả chúng nằm chình ình trong đầu ra. Parse tử tế sẽ trả chúng về đúng ký tự mà chúng đại diện.
Sao không dùng regex xóa hết mọi thứ giữa hai ngoặc nhọn cho nhanh?
Vì cả khối CDATA lẫn giá trị attribute đều chứa những ký tự trông giống markup mà không phải markup. Regex sẽ vô tư nuốt luôn phần ruột của một khối <![CDATA[...]]> chứa HTML nhúng, và nó không có cách nào phân biệt một thẻ thật với một dấu < xuất hiện bên trong attribute có dấu nháy. Parse xử lý đúng những trường hợp đó; so khớp mẫu thì sai một cách lặng lẽ.
Giá trị attribute có được lấy ra không?
Bạn nhận được element text; attribute là metadata về phần tử chứ không phải nội dung của nó. Thường thì thế là đúng — bạn muốn phần tóm tắt, không phải số phiên bản schema. Chỗ nó gây phiền là các định dạng cất nội dung thật trong attribute, nên nếu đầu ra trông lèo tèo, hãy mở file nguồn và kiểm tra xem phần chữ bạn cần có nằm trong <tag attr="..."> không.
Có dùng được với RSS feed và sitemap không?
Được — cả hai đều là XML và đều chuyển được. Một RSS feed cho bạn tiêu đề, mô tả và ngày tháng dưới dạng text đọc được, một cách nhanh gọn để dựng kho ngữ liệu từ một kho lưu blog. Một sitemap cho bạn danh sách URL — thứ hữu ích hơn khi được đẩy sang chỗ khác xử lý tiếp, chứ không phải để đọc như văn xuôi.
Công cụ liên quan
Một lưu ý về thứ XML bạn gặp gián tiếp: file .docx và .epub bên dưới đều
là XML nén zip. Bạn có thể giải nén rồi ném phần markup bên trong vào đây, nhưng đừng — nó bão hòa
các run định dạng và metadata revision, đủ để nhấn chìm phần chữ. Hãy dùng
Word sang text hoặc
EPUB sang text — chúng biết
phần nào là nội dung. Với markup là HTML chứ không phải XML, đã có
HTML sang text, và với định
dạng dữ liệu có cấu trúc lớn còn lại,
JSON sang text.
File2Txt nhận mọi định dạng
được hỗ trợ nếu bạn không muốn chọn trang.
Còn khi file XML nằm trong một repository — file POM, descriptor build, fixture test — chuyển riêng nó là tước mất ngữ cảnh của nó. Trình chuyển GitHub sang text, trình chuyển GitLab và trình chuyển thư mục cục bộ cho phép bạn gom cả file XML lẫn phần code đọc nó vào một đầu ra duy nhất — gần như lúc nào cũng hữu ích hơn. Bài hướng dẫn chuẩn bị file cho LLM bàn về trường hợp tổng quát.
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.