So sánh JSON và XML [đã đóng]


273

Tôi muốn biết cái nào nhanh hơn: XML và JSON? Khi nào nên sử dụng cái nào?


60
Nhanh hơn ở đâu? Quá trình lây truyền? Chế biến? Tạo ra? Cả hai đều không có chân bạn biết. Có khả năng JSON "nhanh hơn" theo một cách nào đó vì nó có ít chi phí đánh dấu hơn. Mặt khác, XML cung cấp XMLSchema để đảm bảo các loại, cấu trúc ... có hiệu lực. Có XSLT để chuyển đổi XML ở gần như bất kỳ định dạng đầu ra nào khác ... Nó phụ thuộc vào những gì bạn cần .
Felix Kling

2
Ngoài ra, hãy kiểm tra các câu hỏi đã hỏi trước đây: stackoverflow.com/search?q=json+vs+xml
Felix Kling

16
BỎ L !! Đây là điều tôi thực sự muốn biết, và thực sự vui mừng vì nó đã ở đây, và câu trả lời là HOÀN HẢO. TRỞ LẠI CHO BẠN , người điều hành: có lẽ đã đến lúc kéo dài hàng loạt sự tham gia của bạn. Tốt cho bạn đã cho phép nó được trả lời, ít nhất!
Mark Gerolimatos

Tôi không quan tâm nếu bài đăng này là cực kỳ muộn cho trò chơi, nhưng tôi đồng ý. Nếu một câu hỏi là một bản sao, không liên quan hoặc mâu thuẫn với các điều khoản dịch vụ, có lẽ (chủ đề đóng / vô dụng) không phải là điều đầu tiên xuất hiện trong tìm kiếm. (btw, đây là kết quả [bị lừa] lần thứ 2 xuất hiện) Tôi đồng ý rằng có lẽ câu trả lời nên gọn gàng và súc tích nhưng nếu kết quả sau kết quả là một chuỗi đóng, không được trả lời chứa đầy các bình luận chủ đề (trái với điều khoản sử dụng) thì nó không giúp được ai
Izaac Corbett

2
Mặc dù câu hỏi khi được hỏi là không rõ ràng, đây KHÔNG phải là một câu hỏi dựa trên ý kiến.
qwr

Câu trả lời:


221

Trước khi trả lời khi nào nên sử dụng cái nào, một chút nền tảng:

chỉnh sửa: Tôi nên đề cập rằng so sánh này thực sự từ góc độ sử dụng chúng trong trình duyệt với JavaScript. Nó không phải là cách định dạng hoặc dữ liệu được sử dụng, và có rất nhiều phân tích cú pháp tốt mà sẽ thay đổi chi tiết để làm những gì tôi đang nói không hoàn toàn hợp lệ.

JSON nhỏ gọn hơn và (theo quan điểm của tôi) dễ đọc hơn - trong quá trình truyền tải, nó có thể "nhanh hơn" đơn giản vì ít dữ liệu được truyền đi.

Trong phân tích cú pháp, nó phụ thuộc vào trình phân tích cú pháp của bạn. Trình phân tích cú pháp biến mã (có thể là JSON hoặc XML) thành cấu trúc dữ liệu (như bản đồ) có thể được hưởng lợi từ tính chất nghiêm ngặt của XML ( Các lược đồ XML phân biệt cấu trúc dữ liệu một cách độc đáo) - tuy nhiên trong JSON là loại vật phẩm (Chuỗi / Số / Đối tượng JSON lồng nhau) có thể được suy ra theo cú pháp, ví dụ:

myJSON = {"age" : 12,
          "name" : "Danielle"}

Trình phân tích cú pháp không cần phải đủ thông minh để nhận ra rằng 12 đại diện cho một số, (và Daniellelà một chuỗi như bất kỳ chuỗi nào khác). Vì vậy, trong javascript chúng ta có thể làm:

anObject = JSON.parse(myJSON);
anObject.age === 12 // True
anObject.name == "Danielle" // True
anObject.age === "12" // False

Trong XML, chúng ta phải làm một cái gì đó như sau:

<person>
    <age>12</age>
    <name>Danielle</name>
</person>

(như một bên, điều này minh họa điểm XML khá dài dòng; mối quan tâm về truyền dữ liệu). Để sử dụng dữ liệu này, chúng tôi sẽ chạy nó thông qua trình phân tích cú pháp, sau đó chúng tôi phải gọi một cái gì đó như:

myObject = parseThatXMLPlease();
thePeople = myObject.getChildren("person");
thePerson = thePeople[0];
thePerson.getChildren("name")[0].value() == "Danielle" // True
thePerson.getChildren("age")[0].value() == "12" // True

Trên thực tế, một trình phân tích cú pháp tốt cũng có thể gõ age cho bạn (mặt khác, bạn có thể không muốn nó). Điều gì đang xảy ra khi chúng ta truy cập dữ liệu này - thay vì thực hiện tra cứu thuộc tính như trong ví dụ JSON ở trên - chúng ta đang thực hiện tra cứu bản đồ trên khóa name. Có thể trực quan hơn để tạo XML như thế này:

<person name="Danielle" age="12" />

Nhưng chúng tôi vẫn phải thực hiện tra cứu bản đồ để truy cập dữ liệu của mình:

myObject = parseThatXMLPlease();
age = myObject.getChildren("person")[0].getAttr("age");

EDIT: Bản gốc:

Trong hầu hết các ngôn ngữ lập trình (không phải tất cả, bằng bất kỳ độ dài nào), việc tra cứu bản đồ như thế này sẽ tốn kém hơn so với tra cứu thuộc tính (như chúng tôi đã nói ở trên khi phân tích cú pháp JSON).

Điều này là sai lệch: hãy nhớ rằng trong JavaScript (và các ngôn ngữ động khác) không có sự khác biệt giữa tra cứu bản đồ và tra cứu trường. Trong thực tế, một tra cứu trường chỉ một tra cứu bản đồ.

Nếu bạn muốn một so sánh thực sự đáng giá, tốt nhất là đánh giá nó - thực hiện các điểm chuẩn trong bối cảnh bạn dự định sử dụng dữ liệu.

Khi tôi đang gõ, Felix Kling đã đưa ra một câu trả lời khá ngắn gọn, so sánh chúng về thời điểm sử dụng mỗi loại, vì vậy tôi sẽ không tiếp tục nữa.


Chỉ là một ghi chú mô phạm ... Một tra cứu trường JavaScript không nhất thiết phải là tra cứu bản đồ. Nó phụ thuộc vào đối tượng và lĩnh vực trong câu hỏi. Các đối tượng nhỏ (đặc biệt là các đối tượng không có thuộc tính được đính kèm sau khi xây dựng) thường sử dụng "loại nhanh" được tối ưu hóa với bộ đệm nội tuyến trong các công cụ JS hiện đại và quay lại các túi thuộc tính chậm hơn (tra cứu bản đồ) cho các đối tượng có số lượng lớn thuộc tính hoặc trường hợp một cấu trúc đối tượng thường xuyên thay đổi.
Brandon Paddock

2
Tôi thấy rằng JSON dễ dàng hơn cho con người để phân tích cú pháp nhưng XML thì máy tính dễ phân tích cú pháp hơn.
Jus12

5
Không đúng, ví dụ, trong PHP, JSON sử dụng json.so không có phụ thuộc ở mức 78k, mặt khác, cần xml.so hoặc xmlreader.so với giá 54k / 32k, nhưng cũng yêu cầu libxml2.so mà 1,4megs . Nhiều mã hơn làm cho nó mất nhiều thời gian hơn để xử lý và sử dụng nhiều bộ nhớ hơn. Chưa kể, XML, do cấu trúc nút / cây của nó, có các tham chiếu vòng tròn, có thể là một nỗi đau trong bất kỳ ngôn ngữ nào không có các tham chiếu yếu. Tôi đã tìm thấy trong một số ngôn ngữ rằng trình phân tích cú pháp XML lớn hơn FAR (chiếm nhiều bộ nhớ hơn và sử dụng nhiều bộ nhớ hơn) so với bất kỳ trình phân tích cú pháp JSON đối tác nào của chúng.
La Mã

Tại sao bạn trộn vấn đề trạng thái nghiêm ngặt của JS với so sánh không liên quan này? Giới thiệu gấp đôi hoặc gấp ba dấu bằng.
atilkan

1
@atilkan vì nhiều trình phân tích cú pháp diễn giải các chuỗi số là số hoặc lưu trữ số dưới dạng chuỗi số.
mazunki

244

Nhanh hơn không phải là một thuộc tính của JSON hoặc XML hoặc kết quả là so sánh giữa những thứ đó sẽ mang lại. Nếu có, thì đó là một thuộc tính của trình phân tích cú pháp hoặc băng thông mà bạn truyền dữ liệu.

Đây là (phần đầu) một danh sách các ưu điểm và nhược điểm của JSON và XML:


JSON

Chuyên nghiệp:

  • Cú pháp đơn giản, dẫn đến chi phí "đánh dấu" ít hơn so với XML.
  • Dễ sử dụng với JavaScript vì đánh dấu là một tập hợp con của ký hiệu đối tượng JS và có các kiểu dữ liệu cơ bản giống như JavaScript.
  • Lược đồ JSON để mô tả và xác thực kiểu dữ liệu và cấu trúc
  • JsonPath để trích xuất thông tin trong các cấu trúc lồng nhau sâu

Con:

  • Cú pháp đơn giản, chỉ một số ít các loại dữ liệu khác nhau được hỗ trợ.

  • Không hỗ trợ cho ý kiến.


XML

Chuyên nghiệp:

  • Đánh dấu tổng quát; có thể tạo ra "phương ngữ" cho bất kỳ mục đích nào
  • Lược đồ XML cho kiểu dữ liệu, xác thực cấu trúc. Làm cho nó cũng có thể tạo các kiểu dữ liệu mới
  • XSLT để chuyển đổi thành các định dạng đầu ra khác nhau
  • XPath / XQuery để trích xuất thông tin trong các cấu trúc lồng nhau sâu
  • được xây dựng để hỗ trợ cho các không gian tên

Con:

  • Tương đối dài dòng so với JSON (kết quả là có nhiều dữ liệu hơn cho cùng một lượng thông tin).

Vì vậy, cuối cùng bạn phải quyết định những gì bạn cần . Rõ ràng cả hai định dạng có trường hợp sử dụng hợp pháp của họ. Nếu bạn chủ yếu sử dụng JavaScript thì bạn nên dùng JSON.

Xin vui lòng thêm ưu và nhược điểm. Tôi không phải là chuyên gia XML;)


20
Một Con cho JSON và Pro cho XML: JSON không hỗ trợ tham chiếu đối tượng (tuần hoàn hay không), XML thì có. XML thực hiện điều này bằng cách buộc idthuộc tính là duy nhất trong tài liệu.
Động cơ Trái đất

7
@EarthEngine Trên thực tế Json.Net ( json.codeplex.com ) không hỗ trợ các tham chiếu đối tượng: james.newtonking.com/projects/json/help/index.html?topic=html/ .
Dmitrii Lobanov

22
@DmitryLobanov: Họ chỉ thêm một số hạn chế bổ sung cho tiêu chuẩn JSON, nhưng nó không được các công cụ JSON khác nhận ra. Vì vậy, nó không phải là "bản địa" cho JSON. Tuy nhiên, đối với XML, hạn chế được viết theo tiêu chuẩn để nó có nguồn gốc.
Động cơ Trái đất

1
Lược đồ JSON thì sao? vi.wikipedia.org/wiki/JSON#JSON_Schema
John Doe

5
JSON có các mảng sẵn có, cũng như giá trị "null". Trong khi đó trong XML bạn cần một số loại quy ước trên các trình phân tích cú pháp lược đồ của bạn. Ngoài ra còn có XSLT giống như các dự án chuyển đổi cho JSON (ví dụ github.com/emlynoregan/bOTLjs )
Vasyl Boroviak

22

Tốc độ xử lý có thể không phải là vấn đề duy nhất có liên quan, tuy nhiên, vì đó là câu hỏi, đây là một số con số trong điểm chuẩn: JSON so với XML: Một số số khó về mức độ chi tiết . Về tốc độ, trong điểm chuẩn đơn giản này, XML thể hiện 21% chi phí so với JSON.

Một lưu ý quan trọng về tính dài dòng, như bài báo đã nói, khiếu nại phổ biến nhất: điều này không liên quan nhiều trong thực tế (cả dữ liệu XML và JSON thường không được xử lý bởi con người, mà cả máy móc), ngay cả đối với vấn đề tốc độ, nó đòi hỏi một số thời gian hợp lý để nén.

Ngoài ra, trong điểm chuẩn này, một lượng lớn dữ liệu đã được xử lý và một ứng dụng web thông thường sẽ không truyền các khối dữ liệu có kích thước như vậy, lớn tới 90MB và nén có thể không có lợi (đối với khối dữ liệu đủ nhỏ, khối dữ liệu nén sẽ lớn hơn chunk không nén), vì vậy không áp dụng.

Tuy nhiên, nếu không có nén, JSON, như rõ ràng hơn, sẽ giảm trọng lượng so với kênh truyền, đặc biệt là nếu được truyền qua kết nối WebSocket, trong đó việc không có phí HTTP cổ điển có thể tạo ra sự khác biệt về lợi thế của JSON, thậm chí nhiều hơn có ý nghĩa.

Sau khi truyền, dữ liệu sẽ được tiêu thụ và tính vào thời gian xử lý chung. Nếu dữ liệu đủ lớn hoặc phức tạp được truyền đi, việc thiếu lược đồ được kiểm tra tự động bởi trình phân tích cú pháp XML hợp lệ, có thể yêu cầu kiểm tra nhiều hơn về dữ liệu JSON; các kiểm tra này sẽ phải được thực thi bằng JavaScript, vốn không được biết là đặc biệt nhanh và do đó, nó có thể đưa ra một chi phí bổ sung trên XML trong các trường hợp như vậy.

Dù sao, chỉ kiểm tra sẽ cung cấp câu trả lời cho trường hợp sử dụng cụ thể của bạn (nếu tốc độ thực sự là vấn đề duy nhất, và không phải là tiêu chuẩn cũng như an toàn cũng không toàn vẹn).

Cập nhật 1: đáng nói, là EXI, định dạng XML nhị phân, cung cấp nén với chi phí thấp hơn so với sử dụng Gzip và lưu xử lý nếu không cần thiết để giải nén XML đã nén. EXI là XML, BSON là gì đối với JSON. Có một cái nhìn tổng quan nhanh ở đây, với một số tham khảo về hiệu quả cả về không gian và thời gian: EXI: Tiêu chuẩn nhị phân cuối cùng? .

Cập nhật 2: cũng tồn tại một báo cáo hiệu suất XML nhị phân, được thực hiện bởi W3C, vì hiệu quả và bộ nhớ CPU thấp, cũng là một vấn đề đối với khu vực XML: Đánh giá trao đổi XML hiệu quả .

Cập nhật 2015 / 03-01

Đáng chú ý trong bối cảnh này, vì chi phí HTTP được nêu ra là một vấn đề: IANA đã đăng ký mã hóa EXI (XML nhị phân hiệu quả được đề cập ở trên), như Mã hóa nội dung cho giao thức HTTP (cùng với nén , khử runggzip ) . Điều này có nghĩa là EXI là một tùy chọn mà trình duyệt có thể hiểu được trong số các máy khách HTTP khác. Xem Thông số giao thức truyền siêu văn bản (iana.org) .


"Về tốc độ, trong điểm chuẩn đơn giản này, XML thể hiện 21% chi phí so với JSON" - có một sự khác biệt lớn trong phân tích cú pháp JSON tùy thuộc vào trình phân tích cú pháp cụ thể được sử dụng. Nó gần như vô nghĩa để trích dẫn bất kỳ trình phân tích cú pháp cụ thể. Tương tự đối với XML.
Jeffrey Blattman

17

Tôi tìm thấy bài viết này tại chợ kỹ thuật số thực sự thú vị. Trích dẫn trích dẫn của họ từ Norm:

Về ưu điểm JSON:

Nếu tất cả những gì bạn muốn vượt qua là các giá trị nguyên tử hoặc danh sách hoặc giá trị băm của các giá trị nguyên tử, JSON có nhiều ưu điểm của XML: nó có thể sử dụng trực tiếp trên Internet, hỗ trợ nhiều ứng dụng, dễ dàng viết các chương trình để xử lý JSON, nó có một vài tính năng tùy chọn, dễ đọc và hợp lý rõ ràng, thiết kế của nó trang trọng và súc tích, các tài liệu JSON dễ tạo và sử dụng Unicode. ...

Về ưu điểm XML:

XML xử lý rất tốt với sự phong phú đầy đủ của dữ liệu phi cấu trúc. Tôi hoàn toàn không lo lắng về tương lai của XML ngay cả khi cái chết của nó được tổ chức một cách vui vẻ bởi một cán bộ thiết kế API web.

Và tôi không thể cưỡng lại việc "Tôi đã nói với bạn như vậy!" mã thông báo đi trong bàn của tôi. Tôi mong muốn được thấy những người JSON làm gì khi họ được yêu cầu phát triển các API phong phú hơn. Khi họ muốn trao đổi dữ liệu ít cấu trúc tốt hơn, họ sẽ chuyển nó thành JSON? Tôi thấy thỉnh thoảng đề cập đến một ngôn ngữ lược đồ cho JSON, các ngôn ngữ khác có tuân theo không? ...

Cá nhân tôi đồng ý với Norm. Tôi nghĩ rằng hầu hết các cuộc tấn công vào XML đều đến từ các Nhà phát triển Web cho các ứng dụng điển hình và không thực sự từ các nhà phát triển tích hợp. Nhưng đó là ý kiến ​​của tôi! ;)


Vâng đặt! Nếu 80% nhà phát triển hoạt động là những đứa trẻ javascript, 80% sẽ nói lên ý kiến ​​của họ rằng JSON "tốt hơn". Nhưng bất cứ ai sử dụng các ngôn ngữ được gõ chỉ là một chút thích thú về JSON. { "foo": 42 }Loại đối tượng đó là gì? Sau đó, để khắc phục tình trạng thiếu loại, những thứ như thế này hiển thị : { "__type": "Bar", "foo": 42 }. Trong XML, loại tương phản có thể được liên kết với tên thành phần : <Bar><foo>42</foo></Bar>. Chỉ những kẻ lisp và javascript như json;)
BitTickler

15

XML (Ngôn ngữ đánh dấu mở rộng) thường được sử dụng XHR vì đây là ngôn ngữ phát sóng tiêu chuẩn, ngôn ngữ lập trình có thể được sử dụng và hỗ trợ cả phía máy chủ và máy khách, vì vậy đây là giải pháp linh hoạt nhất. XML có thể được tách ra cho nhiều phần hơn để một nhóm được chỉ định có thể phát triển phần của chương trình mà không ảnh hưởng đến các phần khác. Định dạng XML cũng có thể được xác định bởi XML DTD hoặc Lược đồ XML (XSL) và có thể được kiểm tra.

JSON một định dạng trao đổi dữ liệu đang trở nên phổ biến hơn như các định dạng ứng dụng JavaScript có thể. Về cơ bản đây là một mảng ký hiệu đối tượng. JSON có một cú pháp rất đơn giản để có thể dễ dàng học được. Và JavaScript cũng hỗ trợ phân tích cú pháp JSON với evalhàm. Mặt khác,eval chức năng đã có tiêu cực. Ví dụ, chương trình có thể phân tích cú pháp JSON rất chậm và vì bảo mật nên evalcó thể rất rủi ro. Điều này không có nghĩa là JSON không tốt, chỉ là chúng ta phải cẩn thận hơn.

Đề nghị của tôi là bạn nên sử dụng JSON cho các ứng dụng trao đổi dữ liệu nhẹ, như trò chơi. Bởi vì bạn không cần phải thực sự quan tâm đến việc xử lý dữ liệu, điều này rất đơn giản và nhanh chóng.

XML là tốt nhất cho các trang web lớn hơn, ví dụ như các trang web mua sắm hoặc một cái gì đó như thế này. XML có thể an toàn và rõ ràng hơn. Bạn có thể tạo cấu trúc dữ liệu và lược đồ cơ bản để dễ dàng kiểm tra hiệu chỉnh và tách nó thành các phần dễ dàng.

Tôi khuyên bạn nên sử dụng XML vì tốc độ và bảo mật, nhưng JSON cho những thứ nhẹ.


Tôi không hạ thấp nhưng tôi tò mò về cách bạn nhìn thấy JSON là một trọng tải nặng hơn hoặc nói chung là chậm hơn. GZip / Deflate có thể được áp dụng. Cú pháp của nó vốn đã làm cho nó nhỏ hơn về mặt byte. JSON cũng có thể định nghĩa lược đồ của nó như một hợp đồng và được tuần tự hóa một cách dễ dàng.
Anthony Mason

JSON không cần phải được phân tích cú pháp.
Yay295

7

Điều quan trọng về JSON là giữ cho việc truyền dữ liệu được mã hóa vì lý do bảo mật. Không còn nghi ngờ gì nữa, JSON nhanh hơn nhiều so với XML. Tôi đã thấy XML mất 100ms trong khi JSON chỉ mất 60ms. Dữ liệu JSON dễ thao tác.


5
Tôi đồng ý, JSON chiến thắng trong cuộc chiến chuyển dữ liệu nhưng nó thiếu về đánh dấu, xác nhận và mở rộng các yếu tố. Đó là lý do tại sao Google thu thập dữ liệu sitemap.xml chứ không phải sitemap.json
Chetabahana

1
Sơ đồ trang web đã được xác định trước khi json phổ biến vì vậy đó không phải là ví dụ tốt nhất. Sơ đồ trang web cũng được xem như một máy chủ đến máy chủ nơi XML phổ biến hơn JSON. (JSON thực sự chỉ vì phổ biến vì dễ làm việc với JavaScript.)
Matthew Whited

nhưng Google AMP sử dụng json chứ không phải xml
Ashraf
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.