blocks|key|1690201|text|是的，JSON将会快30%25左右，更少的字符通过行，并且它的解析速度非常快。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1690202|Ypu还可以看看"YAML“，它在消息中发送了一个绝对最小的元数据。|1690203|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Yes JSON would be about 30% faster there are fewer characters going over the line and its very quick to parse.

Ypu could also take a look at "YAML" which sends an absolute mininmum of metadata in the message.

blocks|key|1690228|text|一般来说，JSON比同等的XML要快得多，而且更小。XML更加丰富，因为您可以将元数据(属性)和内容分开存储，但在JSON中也可以通过适当的结构化约定来实现这一点。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1690229|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Generally speaking, JSON is much faster and smaller than the equivalent XML. XML is richer in that you can store metadata (attributes) and content separately, but the same can be achieved in JSON with appropriate structuring conventions.

blocks|key|3098757|text|不是一个答案，而是一个检查你的假设的建议。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3098758|JSON是怎么变小的？|3098759|JSON：|3098760|"person":{"firstname":"Fred",+
++++++++++"lastname":"Flintstone",++
++++++++++"age":38,+
++++++++++"spouse":"Wilma"+}|code-block|syntax|javascript|3098761|XML：|3098762|<person+firstname='Fred'+
++++++++lastname='Flintstone'+
++++++++age='38'+
++++++++spouse='Wilma'/>|3098763|我只是不明白，一般来说，JSON表达式怎么会比“等价的”XML小30%25。即使增加了这些东西的复杂性，使用嵌套结构和数组，也不会有30%25的差异。它大致相当，json获得了优势，因为嵌套结构的结束标记是}，而XML获得了优势，因为它不需要引用字段名。|3098764|如果您强迫我使用XML元素，如下所示：|3098765|<person>
+++<firstname>Fred<firstname>
+++<lastname>Flintstone<lastname>
+++<age>38</age>
+++<spouse>Wilma</spouse>
</person>|3098766|...sure，则生成的XML比以前的JSON更大。但这看起来像是作弊。|3098767|3098768|现在可能的情况是，目前格式化XML的方式将元素用于所有内容，并且有机会相应地缩小有效负载。但这并不一定意味着JSON。如果您有处理XML的工具和库，则可以保留XML和收缩。|3098769|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|11|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|12|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|13|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|14|8|@]|9|@]|A|$I|J]]|$1|K|3|L|5|6|7|15|8|@]|9|@]|A|$]]|$1|M|3|N|5|H|7|16|8|@]|9|@]|A|$I|J]]|$1|O|3|P|5|6|7|17|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|18|8|@]|9|@]|A|$]]|$1|S|3|T|5|H|7|19|8|@]|9|@]|A|$I|J]]|$1|U|3|V|5|6|7|1A|8|@]|9|@]|A|$]]|$1|W|3|-4|5|6|7|1B|8|@]|9|@]|A|$]]|$1|X|3|Y|5|6|7|1C|8|@]|9|@]|A|$]]|$1|Z|3|-4|5|6|7|1D|8|@]|9|@]|A|$]]]|10|$]]

Not an answer, but rather a suggestion to examine your assumptions. 

How is JSON smaller? 

JSON:

<pre><code>"person":{"firstname":"Fred", 
 "lastname":"Flintstone", 
 "age":38, 
 "spouse":"Wilma" }
</code></pre>

XML: 

<pre><code>&lt;person firstname='Fred' 
 lastname='Flintstone' 
 age='38' 
 spouse='Wilma'/&gt;
</code></pre>

I just don't see how, in general, a JSON expression is going to be 30% smaller than "equivalent" XML. Even as you ramp up the complexity of these things, with nested structures and arrays, it's not going to be a 30% difference. It's approximately equivalent, with json earning an advantage because the end tag of a nested structure is a } , while XML earns an advantage because it need not quote field names. 

If you forced me to use XML elements, like this: 

<pre><code>&lt;person&gt;
 &lt;firstname&gt;Fred&lt;firstname&gt;
 &lt;lastname&gt;Flintstone&lt;lastname&gt;
 &lt;age&gt;38&lt;/age&gt;
 &lt;spouse&gt;Wilma&lt;/spouse&gt;
&lt;/person&gt;
</code></pre>

...sure, the resulting XML is larger than the prior JSON. But that seems like cheating. 

<hr>

Now it may be that the way you format your XML currently uses elements for everything, and that there's an opportunity to shrink the payload accordingly. But that doesn't necessarily imply JSON. If you've got tools and libraries that handle XML, you can keep XML and shrink.

blocks|key|1112941|text|回答这个问题的最好方法是自己测试它，因为涉及到压缩。您还可以通过一个客观的答案巧妙地避免XML与JSON的圣战！|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1112942|由于这只是一个测试，实际上并不需要工作，您只需用javascript编写一个xml->json转换器，它遍历XML树并将其复制到嵌套的数组/对象结构中，然后将其传递给JSON.stringify()。唯一的棘手之处是决定什么是数组，什么是对象。|1112943|找到要发送的数据的代表性样本(或几个)，使用您的工具将其转换为JSON，将其与原始XML压缩并比较大小。|1112944|注意:我四处寻找在线XML->JSON转换器，它们都很糟糕--引号外的copius空格(在JSON中是非法的，改变大小)和无引号的键名(同上)。不要在测试中使用它们，否则会得到错误的数据。|1112945|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

The best way to answer this is to test it yourself, since compression is involved. You also neatly avoid the XML vs JSON holy war by having an objective answer! 

Since it's just a test and doesn't really need to work, you could just write up an xml->json converter in javascript that walked the XML DOM tree and copied it into a nested array/object structure then passed it to JSON.stringify(). The only tricky bit would be deciding what becomes an array and what becomes an object.

Find a representative sample (or a few) of the data being sent, convert it to JSON with your tool, gzip it and the original XML and compare sizes.

Note: I looked around for an online XML->JSON converter and they were all terrible--copius whitespace outside of quotes (illegal in JSON, alters size) and unquoted key names (ditto). Don't use them for your test or you'll get bad data.

blocks|key|1112956|text|<person+firstname='Fred'+
++++++++lastname='Flintstone'+
++++++++age='38'+
++++++++spouse='Wilma'/>

"person":{"firstname":"Fred",+
++++++++++"lastname":"Flintstone",++
++++++++++"age":38,+
++++++++++"spouse":"Wilma"+}|type|code-block|depth|inlineStyleRanges|entityRanges|data|syntax|javascript|1112957|XML:+80个字符|unstyled|1112958|JSON:+92个字符。|1112959|XML是比瘦了13%25的获胜者，谁会想到所有这些虚假的说法呢？|offset|length|style|BOLD|1112960|上面的例子取自Cheeso。请注意，回车类型会改变大小，但两者的大小是相同的。在没有任何回报的情况下，这个比率是XML:+74，JSON:+86，相差14%25|1112961|有人在这个讨论中声称“使用内容的属性是作弊”(引用这一点)。|1112962|1)请告诉我XML的格式有多好是“作弊”？如果它没有欺骗(很长的)规范，那么让我们克服它。Valid是有效的。|1112963|2)在这种情况下，ASP.NET+web.config是“作弊”，在上千个其他大型狗的例子中。|1112964|<forms+loginUrl="~/Home/Login"+
+++++++defaultUrl="~/Home"+
+++++++timeout="2880"+
+++++++requireSSL="false"+
+++++++slidingExpiration="true"+/>|1112965|公平地说，有些人倾向于在如何形成XML方面有一种臃肿的XML心态。|1112966|，但不应该说13%25的瘦XML型不是有效的。因此，它甚至击败了JSON+(在大小上)。|1112967|1：http://www.ibm.com/developerworks/xml/library/x-eleatt/index.html+2004文章，请注意|1112968|entityMap|0|LINK|mutability|MUTABLE|url|http://www.ibm.com/developerworks/xml/library/x-eleatt/index.html^0|0|0|0|0|5|0|0|0|19|9|0|0|0|0|0|16|0|2|1T|0|0^^$0|@$1|2|3|4|5|6|7|1C|8|@]|9|@]|A|$B|C]]|$1|D|3|E|5|F|7|1D|8|@]|9|@]|A|$]]|$1|G|3|H|5|F|7|1E|8|@]|9|@]|A|$]]|$1|I|3|J|5|F|7|1F|8|@$K|1G|L|1H|M|N]]|9|@]|A|$]]|$1|O|3|P|5|F|7|1I|8|@]|9|@]|A|$]]|$1|Q|3|R|5|F|7|1J|8|@]|9|@]|A|$]]|$1|S|3|T|5|F|7|1K|8|@$K|1L|L|1M|M|N]]|9|@]|A|$]]|$1|U|3|V|5|F|7|1N|8|@]|9|@]|A|$]]|$1|W|3|X|5|6|7|1O|8|@]|9|@]|A|$B|C]]|$1|Y|3|Z|5|F|7|1P|8|@]|9|@]|A|$]]|$1|10|3|11|5|F|7|1Q|8|@$K|1R|L|1S|M|N]]|9|@]|A|$]]|$1|12|3|13|5|F|7|1T|8|@]|9|@$K|1U|L|1V|1|1W]]|A|$]]|$1|14|3|-4|5|F|7|1X|8|@]|9|@]|A|$]]]|15|$16|$5|17|18|19|A|$1A|1B]]]]

<pre><code>&lt;person firstname='Fred' 
 lastname='Flintstone' 
 age='38' 
 spouse='Wilma'/&gt;

"person":{"firstname":"Fred", 
 "lastname":"Flintstone", 
 "age":38, 
 "spouse":"Wilma" }
</code></pre>

XML: 80 chars

JSON: 92 chars.

XML is the 13% slimmer winner, who would have thought for all the bogus claims?

[Example taken from Cheeso above. Note that carriage return types change the size but equally for both. Without any returns in either, the ratio is XML: 74, JSON: 86, a 14% difference]

Someone claimed in this discussion that "using attributes for content is cheating" (citing [this][1]).

1) Pray tell how well formed XML is 'cheating'? If it doesn't cheat the (very long) spec, then let's please get over it. Valid is valid. 

2) In that case an ASP.NET web.config is 'cheating', among a thousand other big-dog examples. 

<pre><code>&lt;forms loginUrl="~/Home/Login" 
 defaultUrl="~/Home" 
 timeout="2880" 
 requireSSL="false" 
 slidingExpiration="true" /&gt;
</code></pre>

To be fair, there are those who tend to have a bloated-XML mentality in how they form the XML. 

But it should not be said that the 13% slimmer XML variety is not just as valid. And thus it even beats JSON (in size).

[1]: <a href="http://www.ibm.com/developerworks/xml/library/x-eleatt/index.html" rel="nofollow">http://www.ibm.com/developerworks/xml/library/x-eleatt/index.html</a> [2004 article, mind you]

blocks|key|1690407|text|实际上，这似乎更难回答，|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1690408|几年前，json是“更快的”，但两者之间的差异已经变得更加细微。|1690409|我观察到的是；|1690410|1690411|xml用gzip比用json压缩得更好。下载过程中节省的时间可以抵消其他组件的影响原始js中的|unordered-list-item|1690412|xml解析/查询大致相当于json+|1690413|中的|1690414|xml解析/查询要慢得多……我不会嫉妒jquery开发人员专注于json|1690415|1690416|总体而言，加快现代浏览器速度的技术也适用于xml处理。|1690417|一般来说，每当我听到json被吹捧为XML的“低脂肪”替代品时，我就在想，这不是某种对体重问题的潜意识痴迷……这就是我悲观的日子；|1690418|基本上，我遵循的经验法则是|1690419|标记适用于文档json适用于数据|1690420|然后继续前进..。这里没什么可看的|1690421|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|12|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|13|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|14|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|15|8|@]|9|@]|A|$]]|$1|G|3|H|5|I|7|16|8|@]|9|@]|A|$]]|$1|J|3|K|5|I|7|17|8|@]|9|@]|A|$]]|$1|L|3|M|5|I|7|18|8|@]|9|@]|A|$]]|$1|N|3|O|5|I|7|19|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|1A|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1B|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|1C|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|1D|8|@]|9|@]|A|$]]|$1|W|3|X|5|6|7|1E|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|6|7|1F|8|@]|9|@]|A|$]]|$1|10|3|-4|5|6|7|1G|8|@]|9|@]|A|$]]]|11|$]]

actually this is harder to answer then it seems, 

several years ago json was 'faster' but the differences have become finer between the two.

what I've observed is;

<ul>
<li>xml compresses better with gzip then json .. time saved in download can offset other components </li>
<li>xml parsing/querying in raw js is roughly equiv with json </li>
<li>xml parsing/querying in jquery is much slower ... I won't begrudge jquery developers to focus on json</li>
</ul>

overall, tech that speeds up modern browsers also applies to xml processing as well.

generally, whenever I hear json touted as a 'lowfat' alternative to XML I wonder if its not some subliminal obsession with weight issues ... thats on my pessimistic days; 

basically the rule of thumb I follow is 

markup good for documents 
json good for data 

and move on ... nothing to see here

blocks|key|3098981|text|在对象序列化方面，JSON通常更紧凑(即使经过压缩)。例如：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3098982|我将一个对象的相同实例序列化为XML和JSON，并得到以下结果：|3098983|JSON|3098984|{
++++"Account":+"2222",
++++"Login":+"124235",
++++"SalesId":+null,
++++"CustomerReference":+"9652358474",
++++"Status":+null,
++++"DropShip":+0,
++++"PromoCode":+null,
++++"Notes":+"For+the+truck",
++++"Errors":+null,
++++"ReferenceId":+null,
++++"PaymentMethod":+"CKPhone",
++++"CheckPayment":+{
++++++++"Name":+"Simon+Riggs",
++++++++"CompanyName":+"Darth+Inc",
++++++++"AccountNumber":+"565555555",
++++++++"RoutingNumber":+"222224455116",
++++++++"CheckNumber":+"32",
++++++++"Address":+{
++++++++++++"Attention":+null,
++++++++++++"Street1":+"555+W+Portebello+Rd",
++++++++++++"Street2":+null,
++++++++++++"City":+"London",
++++++++++++"State":+"Texas",
++++++++++++"Zipcode":+"45217",
++++++++++++"Country":+null,
++++++++++++"ReferenceId":+null,
++++++++++++"GetAxType":+2
++++++++},
++++++++"ReferenceId":+null,
++++++++"GetAxType":+2
++++},
++++"CreditCardPayment":+{
++++++++"Name":+"Simon+Riggs",
++++++++"CardNumber":+"1111222233334444",
++++++++"Cvv2":+"546",
++++++++"Month":+10,
++++++++"Year":+2018,
++++++++"Address":+{
++++++++++++"Attention":+null,
++++++++++++"Street1":+"555+W+Portebello+Rd",
++++++++++++"Street2":+null,
++++++++++++"City":+"London",
++++++++++++"State":+"Texas",
++++++++++++"Zipcode":+"45217",
++++++++++++"Country":+null,
++++++++++++"ReferenceId":+null,
++++++++++++"GetAxType":+2
++++++++},
++++++++"ReferenceId":+"0",
++++++++"GetAxType":+2
++++},
++++"ShippingAddress":+{
++++++++"Attention":+"Simon+Riggs",
++++++++"Street1":+"555+W+Portebello+Rd",
++++++++"Street2":+null,
++++++++"City":+"London",
++++++++"State":+"Texas",
++++++++"Zipcode":+"45217",
++++++++"Country":+null,
++++++++"ReferenceId":+null,
++++++++"GetAxType":+2
++++},
++++"Totals":+{
++++++++"SubTotal":+25.0,
++++++++"TotalTax":+5.0,
++++++++"ShippingTotal":+10.0,
++++++++"ShippingTax":+1.5,
++++++++"GrandTotal":+35.0
++++},
++++"Lines":+[{
++++++++"SKU":+"1442-4521",
++++++++"LineNum":+0.0,
++++++++"Qty":+2.0,
++++++++"Price":+72.95,
++++++++"ShippingClass":+"Ground",
++++++++"ReferenceId":+null,
++++++++"GetAxType":+2
++++},
++++{
++++++++"SKU":+"1212-5549",
++++++++"LineNum":+0.0,
++++++++"Qty":+1.0,
++++++++"Price":+31.15,
++++++++"ShippingClass":+"Ground",
++++++++"ReferenceId":+null,
++++++++"GetAxType":+2
++++}],
++++"GetAxType":+2
}|code-block|syntax|javascript|3098985|XML|3098986|<?xml+version="1.0"+encoding="utf-16"?>
<SalesOrder+xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"+xmlns:xsd="http://www.w3.org/2001/XMLSchema">
++<Account>2222</Account>
++<Login>124235</Login>
++<CustomerReference>9652358474</CustomerReference>
++<DropShip>0</DropShip>
++<Notes>For+the+truck</Notes>
++<PaymentMethod>CKPhone</PaymentMethod>
++<CheckPayment>
++++<Name>Simon+Riggs</Name>
++++<CompanyName>Darth+Inc</CompanyName>
++++<AccountNumber>565555555</AccountNumber>
++++<RoutingNumber>222224455116</RoutingNumber>
++++<CheckNumber>32</CheckNumber>
++++<Address>
++++++<Street1>555+W+Portebello+Rd</Street1>
++++++<City>London</City>
++++++<State>Texas</State>
++++++<Zipcode>45217</Zipcode>
++++</Address>
++</CheckPayment>
++<CreditCardPayment>
++++<Name>Simon+Riggs</Name>
++++<CardNumber>1111222233334444</CardNumber>
++++<Cvv2>546</Cvv2>
++++<Month>10</Month>
++++<Year>2018</Year>
++++<Address>
++++++<Street1>555+W+Portebello+Rd</Street1>
++++++<City>London</City>
++++++<State>Texas</State>
++++++<Zipcode>45217</Zipcode>
++++</Address>
++++<ReferenceId>0</ReferenceId>
++</CreditCardPayment>
++<ShippingAddress>
++++<Attention>Simon+Riggs</Attention>
++++<Street1>555+W+Portebello+Rd</Street1>
++++<City>London</City>
++++<State>Texas</State>
++++<Zipcode>45217</Zipcode>
++</ShippingAddress>
++<Totals>
++++<SubTotal>25</SubTotal>
++++<TotalTax>5</TotalTax>
++++<ShippingTotal>10</ShippingTotal>
++++<ShippingTax>1.5</ShippingTax>
++++<GrandTotal>35</GrandTotal>
++</Totals>
++<Lines>
++++<SalesLine>
++++++<SKU>1442-4521</SKU>
++++++<LineNum>0</LineNum>
++++++<Qty>2</Qty>
++++++<Price>72.95</Price>
++++++<ShippingClass>Ground</ShippingClass>
++++</SalesLine>
++++<SalesLine>
++++++<SKU>1212-5549</SKU>
++++++<LineNum>0</LineNum>
++++++<Qty>1</Qty>
++++++<Price>31.15</Price>
++++++<ShippingClass>Ground</ShippingClass>
++++</SalesLine>
++</Lines>
</SalesOrder>|3098987|当以ASCII编码时，JSON是1422字节，而XML是1954字节。使用GZipStream对它们进行压缩后，差别较小，但仍然非常明显。JSON压缩为524字节，而XML压缩为695字节。|3098988|序列化/反序列化时间会因实现(当然还有硬件)而有所不同，但我在一个循环中对上述JSON和XML进行了100,000次序列化和反序列化，得到了总的累积时间：|3098989|JSON序列化:5258ms，XML序列化:3266ms|3098990|JSON反序列化:9582ms，XML反序列化:4604ms|3098991|因此，使用我正在使用的库(见下文)，XML的序列化和反序列化速度更快，但由于平均值是以百分之一毫秒为单位测量的，我认为网络带宽和传输时间更重要。|3098992|(注意:我使用微软的System.Xml.Serialization.XmlSerializer和JSON.Net的Newtonsoft.Json.JsonConvert类在C#中做到了这一点)|3098993|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|12|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|13|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|14|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|15|8|@]|9|@]|A|$I|J]]|$1|K|3|L|5|6|7|16|8|@]|9|@]|A|$]]|$1|M|3|N|5|H|7|17|8|@]|9|@]|A|$I|J]]|$1|O|3|P|5|6|7|18|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|19|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|1A|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|1B|8|@]|9|@]|A|$]]|$1|W|3|X|5|6|7|1C|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|6|7|1D|8|@]|9|@]|A|$]]|$1|10|3|-4|5|6|7|1E|8|@]|9|@]|A|$]]]|11|$]]

In terms of object serialization, JSON will generally be more compact (even when compressed). For Example:

I serialized the same instance of an object into both XML and JSON and got the following: 

JSON

<pre><code>{
 "Account": "2222",
 "Login": "124235",
 "SalesId": null,
 "CustomerReference": "9652358474",
 "Status": null,
 "DropShip": 0,
 "PromoCode": null,
 "Notes": "For the truck",
 "Errors": null,
 "ReferenceId": null,
 "PaymentMethod": "CKPhone",
 "CheckPayment": {
 "Name": "Simon Riggs",
 "CompanyName": "Darth Inc",
 "AccountNumber": "565555555",
 "RoutingNumber": "222224455116",
 "CheckNumber": "32",
 "Address": {
 "Attention": null,
 "Street1": "555 W Portebello Rd",
 "Street2": null,
 "City": "London",
 "State": "Texas",
 "Zipcode": "45217",
 "Country": null,
 "ReferenceId": null,
 "GetAxType": 2
 },
 "ReferenceId": null,
 "GetAxType": 2
 },
 "CreditCardPayment": {
 "Name": "Simon Riggs",
 "CardNumber": "1111222233334444",
 "Cvv2": "546",
 "Month": 10,
 "Year": 2018,
 "Address": {
 "Attention": null,
 "Street1": "555 W Portebello Rd",
 "Street2": null,
 "City": "London",
 "State": "Texas",
 "Zipcode": "45217",
 "Country": null,
 "ReferenceId": null,
 "GetAxType": 2
 },
 "ReferenceId": "0",
 "GetAxType": 2
 },
 "ShippingAddress": {
 "Attention": "Simon Riggs",
 "Street1": "555 W Portebello Rd",
 "Street2": null,
 "City": "London",
 "State": "Texas",
 "Zipcode": "45217",
 "Country": null,
 "ReferenceId": null,
 "GetAxType": 2
 },
 "Totals": {
 "SubTotal": 25.0,
 "TotalTax": 5.0,
 "ShippingTotal": 10.0,
 "ShippingTax": 1.5,
 "GrandTotal": 35.0
 },
 "Lines": [{
 "SKU": "1442-4521",
 "LineNum": 0.0,
 "Qty": 2.0,
 "Price": 72.95,
 "ShippingClass": "Ground",
 "ReferenceId": null,
 "GetAxType": 2
 },
 {
 "SKU": "1212-5549",
 "LineNum": 0.0,
 "Qty": 1.0,
 "Price": 31.15,
 "ShippingClass": "Ground",
 "ReferenceId": null,
 "GetAxType": 2
 }],
 "GetAxType": 2
}
</code></pre>

XML

<pre><code>&lt;?xml version="1.0" encoding="utf-16"?&gt;
&lt;SalesOrder xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"&gt;
 &lt;Account&gt;2222&lt;/Account&gt;
 &lt;Login&gt;124235&lt;/Login&gt;
 &lt;CustomerReference&gt;9652358474&lt;/CustomerReference&gt;
 &lt;DropShip&gt;0&lt;/DropShip&gt;
 &lt;Notes&gt;For the truck&lt;/Notes&gt;
 &lt;PaymentMethod&gt;CKPhone&lt;/PaymentMethod&gt;
 &lt;CheckPayment&gt;
 &lt;Name&gt;Simon Riggs&lt;/Name&gt;
 &lt;CompanyName&gt;Darth Inc&lt;/CompanyName&gt;
 &lt;AccountNumber&gt;565555555&lt;/AccountNumber&gt;
 &lt;RoutingNumber&gt;222224455116&lt;/RoutingNumber&gt;
 &lt;CheckNumber&gt;32&lt;/CheckNumber&gt;
 &lt;Address&gt;
 &lt;Street1&gt;555 W Portebello Rd&lt;/Street1&gt;
 &lt;City&gt;London&lt;/City&gt;
 &lt;State&gt;Texas&lt;/State&gt;
 &lt;Zipcode&gt;45217&lt;/Zipcode&gt;
 &lt;/Address&gt;
 &lt;/CheckPayment&gt;
 &lt;CreditCardPayment&gt;
 &lt;Name&gt;Simon Riggs&lt;/Name&gt;
 &lt;CardNumber&gt;1111222233334444&lt;/CardNumber&gt;
 &lt;Cvv2&gt;546&lt;/Cvv2&gt;
 &lt;Month&gt;10&lt;/Month&gt;
 &lt;Year&gt;2018&lt;/Year&gt;
 &lt;Address&gt;
 &lt;Street1&gt;555 W Portebello Rd&lt;/Street1&gt;
 &lt;City&gt;London&lt;/City&gt;
 &lt;State&gt;Texas&lt;/State&gt;
 &lt;Zipcode&gt;45217&lt;/Zipcode&gt;
 &lt;/Address&gt;
 &lt;ReferenceId&gt;0&lt;/ReferenceId&gt;
 &lt;/CreditCardPayment&gt;
 &lt;ShippingAddress&gt;
 &lt;Attention&gt;Simon Riggs&lt;/Attention&gt;
 &lt;Street1&gt;555 W Portebello Rd&lt;/Street1&gt;
 &lt;City&gt;London&lt;/City&gt;
 &lt;State&gt;Texas&lt;/State&gt;
 &lt;Zipcode&gt;45217&lt;/Zipcode&gt;
 &lt;/ShippingAddress&gt;
 &lt;Totals&gt;
 &lt;SubTotal&gt;25&lt;/SubTotal&gt;
 &lt;TotalTax&gt;5&lt;/TotalTax&gt;
 &lt;ShippingTotal&gt;10&lt;/ShippingTotal&gt;
 &lt;ShippingTax&gt;1.5&lt;/ShippingTax&gt;
 &lt;GrandTotal&gt;35&lt;/GrandTotal&gt;
 &lt;/Totals&gt;
 &lt;Lines&gt;
 &lt;SalesLine&gt;
 &lt;SKU&gt;1442-4521&lt;/SKU&gt;
 &lt;LineNum&gt;0&lt;/LineNum&gt;
 &lt;Qty&gt;2&lt;/Qty&gt;
 &lt;Price&gt;72.95&lt;/Price&gt;
 &lt;ShippingClass&gt;Ground&lt;/ShippingClass&gt;
 &lt;/SalesLine&gt;
 &lt;SalesLine&gt;
 &lt;SKU&gt;1212-5549&lt;/SKU&gt;
 &lt;LineNum&gt;0&lt;/LineNum&gt;
 &lt;Qty&gt;1&lt;/Qty&gt;
 &lt;Price&gt;31.15&lt;/Price&gt;
 &lt;ShippingClass&gt;Ground&lt;/ShippingClass&gt;
 &lt;/SalesLine&gt;
 &lt;/Lines&gt;
&lt;/SalesOrder&gt;
</code></pre>

When encoded in ASCII, the JSON is 1422 bytes while the XML is 1954 bytes. After compressing them using a GZipStream, the difference is smaller but still pretty clear. The JSON compresses down to 524 bytes while the XML compresses down to 695 bytes.

Serialization/deserialization time will vary by implementation (and hardware of course) but I serialized and deserialized the above JSON and XML 100,000 times in a loop and got the total accumulative times:

JSON Serialization: 5258 ms,
XML Serialization: 3266 ms

JSON Deserialization: 9582 ms,
XML Deserialization: 4604 ms

So XML serializes and deserializes faster using the libraries I'm using (see below), but with averages measuring in the hundredths of milliseconds, I'd say network bandwidth and transfer time is more consequential. 

(Note: I did this in C# using Microsoft's System.Xml.Serialization.XmlSerializer and JSON.Net's Newtonsoft.Json.JsonConvert classes)

I have an application that performs a little slow over the internet due to bandwidth reasons. I have enabled GZip which has improved download time by a significant amout, but I was also considering whether or not I could switch from XML to JSON in order to squeeze out that last bit of performance. Would using JSON make the message size significantly smaller, or just somewhat smaller? Let's say we're talking about 250kB of XML data (which compresses to 30kB).

How does JSON compare to XML in terms of file size and serialisation/deserialisation time?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我有一个应用程序，由于带宽的原因，在互联网上执行有点慢。我启用了GZip，它极大地缩短了下载时间，但我也在考虑是否可以从XML切换到JSON，以便挤出最后一点性能。使用JSON会使消息大小明显变小，还是只是稍微变小一些？假设我们讨论的是250kB的XML数据(压缩到30kB)。

问在文件大小和序列化/反序列化时间方面，JSON与XML相比如何？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在文件大小和序列化/反序列化时间方面，JSON与XML相比如何？EN