2009-04-29 38 views
25

Tôi vừa mới nghe về JSON (Ký hiệu đối tượng Javascript). Ai có thể giải thích lý do tại sao nó được xem xét (bởi một số trang web/blog/etc) là quan trọng? Chúng tôi đã có XML, tại sao JSON lại tốt hơn (ngoài việc là 'bản địa của Javascript')?Tại sao JSON quan trọng?

Chỉnh sửa: Hmm, chủ đề trả lời chính có vẻ là 'nó nhỏ hơn'. Tuy nhiên, thực tế là nó cho phép tìm nạp dữ liệu trên các tên miền, có vẻ quan trọng đối với tôi. Hoặc là trong thực tế này chưa (chưa) được sử dụng nhiều?

+8

tôi nghe nói họ sẽ đổi tên XML để OEML (Over Engineered Markup Language) –

+2

như thế nào JSON xử lý bảng mã ký tự khác nhau (như XML không). Có một mã hóa ký tự ngầm trong một biểu diễn JSON không? –

+1

Cho phép lấy dữ liệu từ một miền khác không thực sự là một tính năng vốn có với định dạng XML hoặc JSON * *. Đó là một thứ liên quan đến trình duyệt. –

Trả lời

0

Nó không phải là nó là tốt hơn, nhưng nó có thể buộc nhiều thứ lại với nhau để cho phép truyền dữ liệu liền mạch mà không cần phân tích thủ công!

Ví dụ javascript -> C# dịch vụ web -> javascript

+0

Tôi không nghĩ rằng được tính là một đối số xem xét rằng ngay cả trong JavaScript thường JSON không được đánh giá nhưng được phân tích vì lý do bảo mật. –

+0

@Benedikt Eger - Có một thay thế mới cho eval sắp tới sẽ đánh giá JSON mà không có rủi ro của eval. Thêm vào đó nếu JSON đến từ một nguồn đáng tin cậy thì nó sẽ được đánh giá bình thường. – stevehipwell

13

JSON thường nhỏ hơn nhiều so với tương đương XML của nó. Truyền nhỏ hơn có nghĩa là chuyển nhanh hơn, điều này mang lại trải nghiệm người dùng tốt hơn.

+0

Tôi không đồng ý rằng json nhỏ hơn. Thẻ '' là định dạng XML nhỏ gọn. 44 ký tự. Nhỏ gọn là: '{person: {" name ":" John Doe "," tag ": [" friend "," male "]}}' 52 ký tự. Có sự khác biệt 25%, ủng hộ XML. XML * có thể * lớn hơn, nhưng không cần phải như vậy. – Cheeso

+4

Tôi đồng ý, do đó tôi sử dụng từ "thường". Khi bạn có các mảng phức tạp, XML trở nên lớn hơn JSON. Chắc chắn sự hiểu lầm của bạn về từ "nói chung" không đáng để bỏ qua? –

+1

JSON nhỏ gọn của bạn không chính xác, nó phải là '{" name ":" John Doe "," tag ": [" friend "," male "]}'. Điều này làm cho nó 45 ký tự, mà vẫn còn lớn hơn XML nhưng chỉ có 1 ký tự. –

4
+0

Từ liên kết thứ hai "Nếu dữ liệu được định dạng là XML thì Ajax bị giới hạn trong việc tìm nạp dữ liệu từ cùng một tên miền (trang web) mà ứng dụng Ajax đến. Nếu dữ liệu được định dạng là JSON thì Ajax có thể di chuyển trên các tên miền" Điều đó không đúng, phải không? –

+0

Brian, tôi nghĩ bạn nói đúng. Đề nghị liên kết thứ hai được coi là nghi ngờ - nó dường như chỉ trả lời câu hỏi trong nhiệm vụ của nó mặc dù nó không đạt được nó ở những nơi. –

+0

@Sam. Đủ công bằng. Cám ơn. –

19

XML có một số nhược điểm:

  • Đó là nặng!
  • Nó cung cấp một đại diện phân cấp của nội dung không chính xác giống như (nhưng khá giống với) mô hình đối tượng Javascript.
  • Javascript có sẵn ở mọi nơi. Không có bất kỳ trình phân tích cú pháp bên ngoài nào, bạn có thể xử lý JSON trực tiếp bằng trình thông dịch JS.

Rõ ràng là không có nghĩa là thay thế hoàn toàn XML. Đối với các ứng dụng web dựa trên JS, lợi thế của nó có thể hữu ích.

+1

Bạn có ý nghĩa gì bởi 'Javascript có sẵn ở mọi nơi'? Nếu tôi giao tiếp ứng dụng Java của mình cho một cá thể CouchDb, tôi có sẵn các trình phân tích cú pháp XML, nhưng không có trình phân tích cú pháp Javascript. –

+1

Mọi nơi theo nghĩa này có nghĩa là "trên mọi máy tính (với trình duyệt hiện đại)". –

+0

@Rabarberski: Là cùng một mô hình đối tượng chính xác cũng là một lợi thế rất lớn đôi khi có thể bị đánh giá thấp. –

12

JSON ngắn gọn hơn nhiều. XML:

<person> 
    <name>John Doe</name> 
    <tags> 
     <tag>friend</tag> 
     <tag>male</tag> 
    </tags> 
</person> 

JSON:

{"name": "John Doe", "tags": ["friend", "male"]} 

Có ít tính năng chồng chéo, quá. Ví dụ, trong XML có sự căng thẳng giữa việc chọn sử dụng các phần tử (như trên), so với các thuộc tính (<person name="John Doe">).

+9

Tôi thực sự tìm thấy XML dễ đọc hơn nhiều. –

+0

Bỏ qua khoảng trống không liên quan, đó là khoảng 44 ký tự so với 78 nhưng nhớ rằng bất kỳ phần tử con nào giống như tên có thể được thay thế bằng thuộc tính (lưu 7 ký tự khác). – cletus

+4

@Steve, vì khi nào khả năng đọc quan trọng trên các định dạng trao đổi dữ liệu? – James

1

JSON là cách để tuần tự hóa dữ liệu trong đối tượng Javascript. Cú pháp được lấy từ ngôn ngữ, vì vậy nó nên quen thuộc với nhà phát triển giao dịch với Javascript, và - là sự xâu chuỗi của một đối tượng - đó là một phương pháp tuần tự hóa tự nhiên hơn cho tương tác trong trình duyệt hơn là một dẫn xuất XML chính thức (với tất cả các quyết định thiết kế tùy ý ngụ ý).

Thật nhẹ nhàng và trực quan.

11

JSON được sử dụng phổ biến chủ yếu bởi vì nó cung cấp một cách để phá vỡ chính sách cùng nguồn gốc được sử dụng trong trình duyệt web và do đó cho phép kết hợp.

Giả sử bạn đang viết dịch vụ web trên miền A.Bạn không thể tải dữ liệu XML từ miền B và phân tích cú pháp nó vì cách duy nhất để làm điều đó là XMLHttpRequest và XMLHttpRequest ban đầu bị giới hạn bởi chính sách cùng nguồn gốc để chỉ nói đến các URL ở cùng miền với trang chứa.

Nó chỉ ra rằng vì nhiều lý do, bạn được phép yêu cầu < tập lệnh > thẻ trên nguồn gốc. Những người thông minh nhận ra đây là một cách hay để làm việc xung quanh giới hạn với XMLHttpRequest. Thay vì máy chủ trả về XML, nó có thể trả về một chuỗi đối tượng JavaScript và các mảng chữ.

(bonus câu hỏi trái như một bài tập cho người đọc: tại sao là < script src = "..." > phép trên các lĩnh vực mà không cần máy chủ opt-in nhưng XHR không phải là)

Tất nhiên, trở về một tập lệnh < > không bao gồm các chữ cái đối tượng không hữu ích vì không gán các giá trị cho một số biến, bạn không thể làm bất cứ điều gì với nó. Do đó, hầu hết các dịch vụ sử dụng một biến thể của JSON, được gọi là JSONP (http://bob.pythonmac.org/archives/2005/12/05/remote-json-jsonp/).

Với sự gia tăng về mức độ phổ biến của các ứng dụng, mọi người nhận ra rằng JSON là một định dạng trao đổi dữ liệu thuận tiện nói chung, đặc biệt khi JavaScript là một đầu của kênh. Ví dụ: JSON được sử dụng rộng rãi trong Chromium, ngay cả trong trường hợp C++ ở cả hai bên. Nó chỉ là một cách nhẹ nhàng để thể hiện dữ liệu đơn giản, rằng các trình phân tích cú pháp tốt tồn tại trong nhiều ngôn ngữ.

Ngạc nhiên thay, sử dụng < tập lệnh > thẻ để làm mashup cực kỳ không an toàn vì bản chất XSS'ing là chính bạn có mục đích. Vì vậy, bản địa JSON (http://ejohn.org/blog/native-json-support-is-required/) đã được giới thiệu, mà obviates lợi ích ban đầu của định dạng. Nhưng vào thời điểm đó, nó đã rất phổ biến :)

+0

Tôi không hiểu câu chuyện gốc này. Việc viết một hàm JavaScript trả về một tài liệu XML (chưa được phân tích) là không quan trọng. Bạn có thể sử dụng hack này để cung cấp XML dễ dàng như sử dụng nó để cung cấp một định dạng tuần tự hoàn toàn mới. –

+0

Đó là sự thật, bạn chỉ có thể trả về một chuỗi XML và sau đó phân tích nó. Nhưng chuỗi sẽ phải được thoát ra một cách cẩn thận bên trong một chuỗi JavaScript. Mọi người thấy mình tự động tạo: returnData ("< dữ liệu foo = \" thanh \ "> ...</foo > ") ... và tự hỏi tại sao phải bận tâm khi họ có thể trả lại trực tiếp các đối tượng và mảng. Và một khi bạn đi xuống con đường đó, bạn nhận ra rằng làm việc với các đối tượng gốc và mảng không có phân tích cú pháp riêng biệt Tuy nhiên, tôi nghĩ rằng các mashup là cách mà JSON bắt đầu, hoặc ít nhất một trong một vài lý do chính. –

2

Nó phụ thuộc vào những gì bạn định làm. Có rất nhiều câu trả lời ở đây thích JSON hơn XML. Nếu bạn nhìn sâu hơn thì không có sự khác biệt lớn.

Nếu bạn có một cây đối tượng, bạn chỉ lấy lại được các đối tượng javascript. Nếu bạn nhìn vào sự căng thẳng để sử dụng truy cập kiểu OOP hơn lượt quay trở lại bạn. Giả sử bạn có một đối tượng kiểu A, B, C được xây dựng trong một cây. Bạn có thể dễ dàng cho phép chúng được nối tiếp với JSON. Nếu bạn đọc chúng trở lại trong bạn chỉ nhận được một cây của các đối tượng javascript. Để tái tạo lại A, B, C, bạn phải nhồi các giá trị theo cách thủ công vào các đối tượng được tạo thủ công hoặc bạn thực hiện một số hacks. Âm thanh như phân tích cú pháp XML và tạo đối tượng? Vâng, có :)

Ngày nay chỉ có các trình duyệt mới nhất có hỗ trợ gốc cho JSON. Để hỗ trợ nhiều trình duyệt hơn, bạn có hai tùy chọn: a) bạn tải một công cụ json paraser trong javascript giúp bạn phân tích cú pháp. Vì vậy, chất béo này âm thanh liên quan đến fatreeness như thế nào? Các tùy chọn khác như tôi thường thấy là eval. Bạn có thể chỉ cần thực hiện eval() trên một chuỗi JSON để lấy các đối tượng. Nhưng điều đó giới thiệu một bộ hoàn toàn mới của các vấn đề an ninh. JSON được chỉ định để nó không thể chứa hàm. Nếu bạn không kiểm tra các đối tượng cho hàm, ai đó có thể dễ dàng gửi cho bạn mã đang được thực hiện.

Vì vậy, nó có thể phụ thuộc vào những gì bạn thích hơn: JSON hoặc XML. Sự khác biệt lớn nhất chính là cách tiếp cận mọi thứ, có thể là các thẻ script XMLHTTPRequest ... Tôi sẽ quyết định điều này để sử dụng. Theo ý kiến ​​của tôi nếu có sự hỗ trợ thích hợp cho XPATH trong các trình duyệt, tôi thường quyết định sử dụng XML. Nhưng thời trang được hướng tới json và tải các trình phân tích cú pháp json bổ sung trong javascript.

Nếu bạn không thể quyết định và bạn biết bạn cần một cái gì đó thực sự mạnh mẽ, bạn phải có một cái nhìn tại YAML. Đọc về YAML rất thú vị để hiểu rõ hơn về chủ đề này. Nhưng nó thực sự phụ thuộc vào những gì bạn đang cố gắng làm.

1

Định dạng tuần tự hóa đối tượng dựa trên văn bản của JSON nhẹ hơn XML và tích hợp trực tiếp với mô hình đối tượng của JavaScript. Đó là hầu hết các lợi thế của nó ngay tại đó.

Những nhược điểm của nó (so với XML), gần như: ít công cụ có sẵn hơn (quên xác nhận và/hoặc chuyển đổi chuẩn) để không nói gì về việc đánh dấu cú pháp hoặc kiểm tra tốt trong hầu hết các trình chỉnh sửa), ít có khả năng có thể đọc được (có các biến thể lớn về khả năng đọc của cả JSON và XML, vì vậy đó là một câu lệnh mờ nhất), tích hợp chặt chẽ với JavaScript làm cho việc tích hợp không chặt chẽ với các môi trường khác.

5

Nếu bạn đang làm việc trong Javascript, chúng tôi sẽ dễ dàng hơn nhiều với JSON. Điều này là do JSON có thể được đánh giá trực tiếp vào một đối tượng Javascript, dễ dàng hơn nhiều so với DOM.

vay và hơi thay đổi XML và JSON từ trên

XML: 

<person> 
    <name>John Doe</name> 
    <tag>friend</tag> 
    <tag>male</tag> 
</person> 

JSON: 

{ person: {"name": "John Doe", "tag": ["friend", "male"]} } 

Nếu bạn muốn để có được những đối tượng thẻ thứ hai với XML, bạn sẽ cần phải sử dụng apis DOM mạnh mẽ nhưng tiết:

var tag2=xmlObj.getElementsByTagName("person")[0].getElementsByTagName("tag")[1]; 

trong khi với một đối tượng Javascript đi kèm trong thông qua JSON, bạn chỉ có thể sử dụng:

var tag2=jsonObj.person.tag[1]; 

Tất nhiên, Jquery làm cho ví dụ DOM đơn giản hơn nhiều:

Tuy nhiên, JSON vừa "vừa" trong một thế giới Javascript. Nếu bạn làm việc với nó một lúc, bạn sẽ thấy rằng bạn có ít chi phí tinh thần hơn nhiều so với dữ liệu dựa trên XML.

Tất cả các ví dụ trên đều bỏ qua khả năng một hoặc nhiều nút khả dụng, được sao chép hoặc khả năng nút đó chỉ có một hoặc không có con. Tuy nhiên, để minh họa cho bản địa-Ness của JSON, để làm điều này với jsonObj, bạn sẽ chỉ phải:

var tag2=(jsonObj.person && jsonObj.person.tags && jsonObj.person.tags.sort && jsonObj.person.tags.length==2 ? jsonObj.person.tags[1] : null); 

(một số người có thể không thích điều đó dài ternary, nhưng nó hoạt động). Nhưng XML sẽ là (theo ý kiến ​​của tôi) nastier (Tôi không nghĩ rằng bạn muốn đi theo cách tiếp cận thứ ba vì bạn cứ tiếp tục gọi các phương thức dom có ​​thể phải thực hiện lại công việc tùy thuộc vào việc thực hiện):

var tag2=null; 
var persons=xmlObj.getElementsByTagName("person"); 
if(persons.length==1) { 
    var tags=persons[0].getElementsByTagName("tag"); 
    if(tags.length==2) { tag2=tags[1]; } 
} 

jquery (chưa được kiểm tra):

var tag2=$("person:only-child tag:nth-child(1)",xmlObj).get(0); 
Các vấn đề liên quan