Bộ chuyển đổi XML sang JSON Miễn phí
Chuyển đổi XML sang JSON ngay lập tức. Xử lý thuộc tính, phần tử lồng nhau và nút văn bản. Chạy hoàn toàn trong trình duyệt của bạn.
XML là gì?
XML (Ngôn ngữ Đánh dấu Mở rộng) là một định dạng để lưu trữ và truyền dữ liệu. Nó sử dụng các thẻ tùy chỉnh để mô tả cấu trúc dữ liệu, làm cho nó dễ đọc và được hỗ trợ rộng rãi. Không giống như JSON, XML có thể bao gồm thuộc tính trên các phần tử.
Tại sao chuyển đổi XML sang JSON?
- Kích thước tệp nhỏ hơn · JSON gọn hơn XML.
- API web · Hầu hết các dịch vụ web hiện đại sử dụng JSON thay vì XML.
- Phân tích dễ dàng hơn · JSON ánh xạ trực tiếp với các đối tượng JavaScript.
- Tích hợp hệ thống cũ · Chuyển đổi dữ liệu XML cũ sang định dạng JSON hiện đại.
Câu hỏi thường gặp
Các thuộc tính XML được xử lý như thế nào?
Thuộc tính XML được chuyển đổi thành thuộc tính JSON với tiền tố @ (ví dụ: @id, @href). Điều này bảo toàn thông tin thuộc tính trong cấu trúc JSON.
Thế còn namespace thì sao?
Namespace được bảo lưu trong đầu ra. Tiền tố được bao gồm trong tên phần tử (ví dụ: "ns:element").
Tôi có thể chuyển đổi JSON ngược lại thành XML không?
Công cụ này chuyển đổi XML sang JSON. Để làm điều ngược lại, bạn có thể sử dụng bộ chuyển đổi JSON sang XML của chúng tôi.
Hai định dạng, cách nhau ba thập kỷ
XML 1.0 trở thành Khuyến nghị W3C vào ngày 10 tháng 2 năm 1998. Các biên tập viên gốc là Tim Bray (Textuality / Netscape), Jean Paoli (Microsoft) và C. M. Sperberg-McQueen (Đại học Illinois tại Chicago); Ban Làm việc do Jon Bosak của Sun Microsystems chủ trì. Xuất xứ của XML bắt nguồn từ SGML (ISO 8879:1986), tiêu chuẩn đánh dấu tài liệu vốn phát triển từ GML của IBM trong thập niên 1970. SGML mạnh mẽ nhưng phức tạp; mục tiêu thiết kế của XML là «design a 'lite' version of SGML», cắt giảm các tính năng tùy chọn xuống một cấu hình có thể triển khai trong vài nghìn dòng code trong khi vẫn giữ Unicode, namespace và tài liệu giàu thuộc tính.
JSON (JavaScript Object Notation) được khám phá, không phải thiết kế. Douglas Crockford và Chip Morningstar gửi tin nhắn JSON đầu tiên vào tháng 4 năm 2001 tại State Software, rút ra định dạng từ cú pháp object-literal của JavaScript. Crockford đăng ký json.org vào năm 2002 và đăng đặc tả một trang. Định dạng được chính thức hóa lần đầu thành RFC 4627 vào tháng 7 năm 2006, tái ban hành thành RFC 7159 năm 2014, và ổn định thành RFC 8259 / STD 90 vào tháng 12 năm 2017, cùng năm ECMA-International xuất bản ECMA-404. Mục tiêu thiết kế của JSON (theo hồi ký của Crockford): tối giản, độc lập ngôn ngữ, dễ tạo và phân tích, không có số phiên bản («không có số phiên bản»), và cố tình không có comment («Tôi đã bỏ comment vì thấy mọi người dùng chúng để chứa chỉ thị phân tích»).
JSON chiếm lĩnh API web vào cuối những năm 2000 khi REST thay thế SOAP và XMLHttpRequest nhường chỗ cho JSON-over-fetch. Đến năm 2015, JSON là định dạng phản hồi mặc định của hầu hết mọi API công khai; XML còn tồn tại trong SOA doanh nghiệp dài hơi, định dạng tài liệu (Office Open XML, OpenDocument) và các niche ràng buộc tiêu chuẩn.
XML và JSON khác nhau ở điểm nào
| XML | JSON | |
|---|---|---|
| Thuộc tính | Hạng nhất (<item id="5"/>) | Không có thuộc tính, mọi thứ đều là cặp key/value |
| Namespace | Gốc (xmlns:prefix="uri") | Tên phẳng; xung đột prefix là vấn đề của ứng dụng |
| Comment | <!-- … --> | Không có theo đặc tả |
| Nội dung hỗn hợp | Gốc (<p>text <b>and</b> markup</p>) | Khó xử, cần mảng hoặc chuỗi hóa |
| Schema | DTD, XSD 1.0 (2001) / 1.1 (2012), RELAX NG, Schematron | JSON Schema (đặc tả cộng đồng, bản nháp 2020-12) |
| Thứ tự | Thứ tự phần tử có ý nghĩa theo đặc tả | Thứ tự key của object không được đảm bảo (hầu hết trình phân tích giữ thứ tự chèn trên thực tế); mảng có thứ tự |
| Số | Chuỗi cho đến khi được schema định kiểu | IEEE 754 double; không phân biệt số nguyên/số thực ở cấp độ đặc tả |
| Độ dài dòng | Cao (mọi giá trị được bọc trong thẻ | Thấp) chỉ có dấu câu |
Tại sao XML→JSON về cơ bản là mất mát
Không có ánh xạ chuẩn hóa W3C từ XML sang JSON. Mọi công cụ chuyển đổi phải tự nghĩ ra câu trả lời cho những câu hỏi mà XML cho phép diễn đạt nhưng JSON không có từ vựng gốc. Những quyết định thường gặp:
- Thuộc tính so với phần tử con: XML cho phép diễn đạt cùng dữ liệu theo cả hai cách. JSON chỉ có một khái niệm (key trên object), nên công cụ chuyển đổi phải tạo ra dấu hiệu. Các quy ước phổ biến: BadgerFish dùng
@cho thuộc tính và$cho văn bản; Parker bỏ hoàn toàn thuộc tính (mất mát nhưng đơn giản); JsonML biểu diễn phần tử dưới dạng mảng với thẻ kiểu (giữ thứ tự và cấu trúc); GData / Newtonsoft / xml2js dùng sub-object@attributescộng với key#textkhi cần. Công cụ này theo quy ước kiểu GData: thuộc tính dưới@attributes, văn bản nội dung hỗn hợp dưới#text, các con lặp lại trở thành mảng. - Các phần tử con lặp lại: nếu công cụ chuyển đổi tạo một key cho mỗi con, con thứ hai sẽ ghi đè con đầu tiên. Cách sửa tiêu chuẩn: phát hiện lặp lại và phát ra mảng. Nhưng điều này có nghĩa là hình dạng JSON phụ thuộc vào dữ liệu, một
<book>tạo ra chuỗi, hai tạo ra mảng chuỗi. Một số consumer muốn dạng mảng ngay cả với một item; một số công cụ cung cấp toggle «always-array» cho tên phần tử cụ thể. - Nội dung hỗn hợp:
<p>Hello <b>world</b>!</p>đan xen văn bản và phần tử với thứ tự có ý nghĩa. JSON không thể diễn đạt tự nhiên sự đan xen đó nếu không có mảng kiểu hỗn hợp hoặc key sentinel#text. Nhiều công cụ chuyển đổi bỏ văn bản giữa các phần tử; những công cụ thận trọng hơn chia nó thành nhiều mục text-node. - Namespace:
<soap:Envelope xmlns:soap="…">có cả prefix lẫn URI ràng buộc. Hầu hết công cụ chuyển đổi giữ prefix như một phần của key JSON (soap:Envelope) và bỏ ràng buộc, điều này ổn miễn là consumer không cần giải quyết namespace. - Comment và processing instruction: thường bị bỏ im lặng, vì JSON không có cú pháp comment.
- Phần CDATA: được làm phẳng thành chuỗi thông thường; wrapper
<![CDATA[…]]>bị mất. - Khoảng trắng: XML có
xml:space="preserve"cho khoảng trắng có ý nghĩa; JSON không có tương đương. Hầu hết công cụ chuyển đổi loại bỏ text node chỉ có khoảng trắng giữa các phần tử.
Khi nào bạn dùng công cụ này
- Tiêu thụ dịch vụ SOAP kế thừa từ frontend JS hiện đại. Phản hồi SOAP là XML; chuyển đổi một lần tại biên giới cho phép phần còn lại của ứng dụng làm việc với JSON.
- Xử lý RSS / Atom feed: cả hai đều là định dạng XML; trình đọc tin tức và aggregator hiện đại thường muốn JSON.
- XML sitemap (
sitemap.xml), chuyển sang JSON giúp kiểm tra và xử lý lập trình dễ hơn. - Dữ liệu OpenStreetMap OSM: được xuất bản dưới dạng XML, thường cần dưới dạng JSON cho bản đồ client-side.
- File Google Earth KML / GPX: định dạng dữ liệu địa lý được cung cấp dưới dạng XML.
- Nội bộ Office Open XML:
.docx,.xlsxvà.pptxlà file XML được nén; nếu bạn đã giải nén một file và muốn kiểm tra cấu trúc của nó dưới dạng JSON, đây là bước chuyển đổi. - Thao tác SVG: SVG là XML. Chuyển sang JSON giúp dễ dàng duyệt và chỉnh sửa cây trong JavaScript trước khi serialize lại.
- Maven POM, file build Ant, cấu hình Spring, tài nguyên Android, Apple plist, dữ liệu tài chính XBRL, hồ sơ y tế HL7, MusicXML, tài liệu pháp lý NMX: các định dạng XML dài hơi thường cần JSON cho công cụ downstream.
Các lựa chọn thay thế hiện đại
- API JSON gốc. Nếu dịch vụ upstream cung cấp biến thể JSON, hãy dùng nó. Dịch vụ SOAP thường không có nhưng hầu hết các tương đương hiện đại thì có.
- GraphQL. Ngôn ngữ truy vấn cho phép client yêu cầu đúng hình dạng JSON nó cần từ schema có kiểu.
- Protocol Buffers (Protobuf), MessagePack, CBOR, Avro. Định dạng serialize nhị phân có schema và kích thước truyền tải nhỏ hơn nhiều so với cả XML lẫn JSON. Phổ biến bên trong mesh microservice; hiếm khi dùng tại biên giới trình duyệt vì cần thư viện giải mã rõ ràng.
- Giữ nguyên XML. Nếu dữ liệu thực sự hướng tài liệu (nội dung hỗn hợp, cấu trúc kiểu sâu, xác thực schema quan trọng), XML phù hợp hơn. Điểm mạnh của JSON là dữ liệu dạng API; độ trung thực tài liệu không phải chuyên môn của nó.
Câu hỏi thêm
Tại sao cùng một XML lại tạo ra hình dạng JSON khác nhau trên các công cụ khác nhau?
Vì không có ánh xạ XML→JSON chuẩn hóa. Mỗi công cụ chuyển đổi chọn một quy ước (BadgerFish, Parker, JsonML, kiểu GData) và các hình dạng JSON kết quả khác nhau về cách đánh dấu thuộc tính, cách bảo toàn nội dung hỗn hợp và cách mảng hóa các con lặp lại. Chuyển đổi vòng XML qua các công cụ khác nhau tạo ra JSON khác nhau; chuyển đổi vòng JSON trở lại XML qua các công cụ khác nhau có thể thay đổi vị trí thuộc tính và thậm chí thứ tự phần tử. Để tương thích, hãy ghi lại quy ước bạn đang dùng và nhất quán với nó.
Còn CDATA, comment và processing instruction thì sao?
Phần CDATA (<![CDATA[…]]>) được làm phẳng thành nội dung chuỗi thông thường, wrapper biến mất nhưng văn bản bên trong được giữ nguyên. Comment XML (<!-- … -->) và processing instruction (<?xml-stylesheet …?>) bị bỏ, vì JSON không có cú pháp cho cả hai. Nếu bạn cần độ trung thực vòng lặp bảo toàn comment, cách tiếp cận đúng là chỉ dùng XML.
XML schema (XSD) của tôi có tồn tại qua quá trình chuyển đổi không?
Không. XSD mô tả cấu trúc và kiểu XML; JSON Schema là tiêu chuẩn tương tự (riêng biệt) cho JSON. Một số công cụ nâng cao có thể dịch XSD sang JSON Schema, nhưng đó là thao tác mất mát, XSD có các tính năng (nội dung hỗn hợp, substitution group, derived type) không có tương đương JSON Schema rõ ràng. Đối với xác thực tài liệu quan trọng, hãy chạy XSD với XML gốc, không phải với bản chuyển đổi JSON.
Tại sao JSON thắng cho API web?
Một vài lý do. JSON ánh xạ trực tiếp vào object JavaScript, nên phân tích phía trình duyệt chỉ là một lần gọi JSON.parse(). Định dạng nhỏ hơn nhiều, không có thẻ đóng, không khai báo namespace, không có gánh nặng schema. REST đã thay thế SOAP cho hầu hết API công khai vào cuối những năm 2000, và JSON là payload tự nhiên cho REST. Điểm mạnh của XML (schema nghiêm ngặt, namespace, nội dung hỗn hợp) quan trọng đối với tài liệu và hệ thống doanh nghiệp kế thừa nhưng hiếm khi cho «give me the user object». Web tối ưu hóa cho trường hợp đơn giản hơn.
Có dữ liệu nào được gửi lên máy chủ không?
Không. XML được phân tích bởi DOMParser gốc của trình duyệt, rồi duyệt đệ quy bằng JavaScript để xây dựng đầu ra JSON. XML được dán vào không bao giờ rời khỏi trang. Công cụ hoạt động ngoại tuyến sau khi đã tải, điều này quan trọng khi XML nguồn chứa endpoint API nội bộ, dữ liệu khách hàng hoặc schema độc quyền mà bạn không muốn tải lên bất kỳ đâu.