EXI标准
<p><a href="https://www.w3.org/XML/EXI/docs/format/exi.html">https://www.w3.org/XML/EXI/docs/format/exi.html</a>
<a href="http://www.w3.org/TR/2009/WD-exi-primer-20091208/">http://www.w3.org/TR/2009/WD-exi-primer-20091208/</a>
<a href="https://www.w3.org/2011/03/exi-pr.html.en">https://www.w3.org/2011/03/exi-pr.html.en</a></p>
<p>下面接收EXI标准的overview。</p>
<h3>背景</h3>
<p>如果你是web开发者你知道XML的子形式XHTML。xml是标识层次化信息的标准。如文档包含的元素（属性或嵌套的元素）。
<code>XML</code>:</p>
<pre><code><document>
<element attribute="value">
<nested-element>text contents</nested-element>
</element>
</document></code></pre>
<h3>overhead</h3>
<p>一个主要问题是XML数据有很大一部分overhead，如表示<code>document</code>元素开始则占用10个字节，11个字节表示结束。
考虑到频繁使用的标签，<code>overhead</code>增长更加快。这种开销在应用程序中几乎不成问题，但在处理更大或更频繁地访问的 XML 数据时，它变得非常重要。以<code>Tweakers.net</code>主页为例。目前，它大约有80KB的数据（只是<code>HTML</code>），它传输约<code>7000</code>个字符的可读数据给用户（估计，我只是复制/粘贴整个页面到文本文档进行测试）。
每天有数百万的页面浏览量，这种表示<code>XML</code>数据的方法造成的开销变得非常重要——<code>Tweakers.net</code>实际上只是一个小玩家，如果你把它与真正庞大的国际网站和其他应用程序相比.</p>
<h3>减少Overhead</h3>
<p>有多种方法减少传输XML中的overhead，如大部分网站使用的GZip。这减少XML传输的大小，大于减少了超过50%，80%或更多。这很大程度上依赖应用，尽管小XML文档，在压缩gzip中甚至更大。
这部分原因是因为gzip不是为xml量身定做的。
但是，它不能节省处理能力。在XML文档传输的"生成"方，仍然需要生成XML。在"接收方"，例如您的浏览器，XML 文档仍然需要从字符流转换为文档对象模型，而文档对象模型又会转换为网站或您正在查看的数据的可视化表示形式。
GZip对此没有帮助，因为它实际上增加了一些开销，在压缩和解压缩XML文档。对用户来说，这种开销很难像现在这样快，但是如果你把这一切放在一起，这是一个非常重要的过程。
在需要高传输速度和低开销的环境中，人们没多久就发现XML不是理想的格式。这就是为什么XML从未真正取代现有的或新的所谓的二进制格式，因为它们效率更高，几乎没有任何开销。然而，XML确实提供了其他优势。</p>
<h3>EXI</h3>
<p>W3C发布了新的高效XML交换标准。可以解决XML的缺陷。根据最新标准，它不是基于将文档转成字符流，而是将信息作为编码为二进制格式的事件流。如</p>
<pre><code><document>
<element attribute="value">
<nested-element>text contents</nested-element>
</element>
</document></code></pre>
<p>根据之前对标准的解释，通过 <code>EXI</code> 传输的此文档转换成一组"事件"，告诉客户端文档包含的内容，一组有效执行某些内容的消息：</p>
<pre><code>Element 'document' starts.
Element 'element' starts.
Attribute 'attribute' contains 'value'
Element 'nested-element' starts
Text-node contains 'text contents'
Element 'nested-element' stops
Element 'element' stops
Element 'document' stops</code></pre>
<p>JAVA开发者使用过SAX(Simple API for XML)解析XML文档应该熟悉。它处理提供SAX解析器处理XML文档。不同在于SAX和其他XML解析器处理字符流。
EXI标准指定如何将信息作为事件流传递，从而大大减少了将该数据表示为纯文本字符流造成的开销。理论上，可以将 EXI 流转换为人类可读的 XML 文档，因为它的实际信息和层次结构不会改变 - 因此，EXI 保留了 XML 是人可读的优势。</p>
<p>EXI 的另一个主要优点是它与 XML 信息集兼容。这意味着现有的XML解析器将能够处理EXI流中包含的XML数据，无需任何调整——只需提供一个新的输入源，以触发开发人员提供的XML解析器中的事件。对于 SAX 尤其如此，因为它已经基于指示元素何时启动的"事件"。将读取编码为字符集的 XML 文档的代码位替换为读取 EXI 二进制流的一些代码，并将事件传递给用户定义的处理程序，这几乎应该是一件小事。</p>
<h3>Performance</h3>
<p>与表示XML的经典形式相比，EXI标准本身并没有指定它实际节省多少。然而，W3C确实做了性能测试，而且非常彻底。在 EXI 评估文档中，他们首先比较了一组 XML 文档的"紧凑性"，这些文档作为普通旧 XML 文本传输，使用相同的 XML 文本使用 <code>GZip</code>压缩并使用 EXI 传输。</p>
<p><img src="https://www.showdoc.cc/server/api/common/visitfile/sign/dfb8455bb2619dbc0c1311d03be7ca01?showdoc=.jpg" alt="" /></p>
<p>与 GZip 一样，在某些情况下，表示文档所需的字节数降低高达 99%，并且经常高于 80%，最低可压缩文档仍减少近 40%。但是，正如您所看到的，在紧凑性方面，将数据表示为 EXI 比 GZip 更加一致。部分原因在于 GZip 最适合使用"重复"字的大型文档 - 正如文档所示，GZip 在包含许多短消息（如地理位置和传感器读数）的 XML 文档中遇到问题。</p>
<h3>解码速度</h3>
<p>由于 EXI 减少了读取 XML 字符流的开销，并且让解析器尝试理解它（通常复制 EXI 已经执行的内容），因此预计 EXI 当然也会提高 XML 处理速度。根据处理速度基准，将普通旧 XML 解析与使用 EXI 的解析进行比较是正确的。</p>
<p><img src="https://www.showdoc.cc/server/api/common/visitfile/sign/7d1627cc07fa170b1e3f132f3862ba28?showdoc=.jpg" alt="" /></p>
<p>在除一个测试用例外的所有测试用例中，EXI 的速度都更快，在一个特定情况下从 75% 快到 2500%， 但通常快约 6.7 倍。</p>
<p>在 XML 文档包含包含来自多个命名空间的元素和属性的重复结构的情况下，获得了极快的速度提升，这在经典 XML 处理程序中会导致大量开销，但在 EXI 中则不产生，这在很大程度上消除了命名空间开销。</p>
<p>令我本人惊讶的是，与GZip压缩XML文档相比，速度提升不那么极端。我不确定为什么会这样，可能是在 GZip 压缩时字节的吞吐量更快，并且文档的实际大小比实际内容对性能的影响更大。但我想其他对GZip和XML解析器内部有更多的了解的人有答案。</p>
<p><img src="https://www.showdoc.cc/server/api/common/visitfile/sign/af7a80cbb269f87090c11aee1346cccd?showdoc=.jpg" alt="" /></p>
<h3>编码速度</h3>
<p>当然，在编码文档时，EXI 也应该更快。对文档进行编码会有效地将某些数据转换为 XML 文档，然后将其转换为 XML 文档字符流并发送它。如果可以跳过转换步骤，则显然需要加快速度。
<img src="https://www.showdoc.cc/server/api/common/visitfile/sign/9c07143c82000794e3a22dd3b581e7cb?showdoc=.jpg" alt="" /></p>
<p>这里的差别并不极端，但仍然很大。在某些情况下，它实际上比他们使用的 XML 编码器（AgileDelta efficient XML）效率低，但在绝大多数情况下，它比 XML 解析器快 2.4 倍。（我在这里使用中值速度增加数字，平均（6.0）的提升速度不成比例地提高 21 倍。</p>
<p>与压缩的 XML 文档生成相比，EXI 的速度要快一些，可能是因为它没有压缩结果的开销。此处的另一个重要点是，GZip 压缩实际上必须等到生成整个 XML 文档（纯文本、中间形式）才能应用有效的压缩。这会增加内存使用量（或者，将某些数据保留在内存中的时间更长），并且从客户端增加它必须等待的时间，直到它开始接收数据。EXI 没有此缺点，因为它可以立即开始发送字节（客户端可以开始处理它们）。
<img src="https://www.showdoc.cc/server/api/common/visitfile/sign/31399142ccdfa6bcab8aec84f3c29d4b?showdoc=.jpg" alt="" /></p>
<h3>结论</h3>
<p>EXI是真棒。它最终可能解决使用XML的缺点，那些高（数据）开销和次优的处理速度，这尤其重要，如果XML已被选择为在高容量环境中使用的格式。W3C 并不羞于说出大型、听起来重要的用例，如军事和实时交易系统，但这些正是导致大量数据需要快速处理的环境。我实际上还不能确定这些环境是否确实会使用XML的缺点，但我想，如果它们这样做，好处就大于缺点。</p>
<p>EXI 的另一个优势当然是环境，因为 W3C 自鸣得意地宣布，与普通旧的 XML 传输系统一样，EXI 的主要优势是 EXI。保存的每个字节（保存每个处理指令）在能源上成本更低，尤其是在高容量环境中。</p>
<p>实现 EXI 也应该相对无痛，而不是使用二进制格式转换 XML 信息共享体系结构，因为现有的解析器只需进行一些调整即可处理 EXI。</p>
<p>我认为这实际上是一大步。之前曾尝试将XML转换为更有效的可转移结构，但这似乎是迄今为止最好的。当然，在大型利益相关者和聪明人民多年发展之后，它应当。因为它被定义为官方标准，它应该能够在现有体系结构中相当快地实现它。</p>
<p>将其应用于 Web 很可能需要对 Web 服务器进行一些更改。可以安装 Web 服务器修改，将 Web 服务器喷出的 HTML 代码转换为 EXI 数据流，这已经提供了性能提升，但它的缺点与 GZip 压缩相同 - "中间"格式首先必须生成和处理，即纯文本 HTML。必须更改 Web 服务器，以将数据作为 EXI 流返回。</p>
<p>（Web） 应用程序也必须更改。大多数 Web 应用程序目前都会输出纯旧的 HTML，使用模板将数据放入 HTML 进行输出。如果要将 EXI 应用于 Web，模板要么必须完全废除，以便将输出生成为抽象的 XML 文档（DOM 再次出现），要么需要更改，以便读取模板并将其输出为 EXI。当然，这是在循环中运行，因为这样的系统实际上是一个 XML 解析器，它输出的数据与 EXI 相同。我不确定EXI在Web上的应用有多有效。</p>
<p>然而，根据评估摘要，EXI 是独立于传输的，这意味着它可以"通过 TCP、UDP、HTTP 和各种无线和卫星传输"使用。</p>
<p>在任何情况下。我读了FP的文章，并很感兴趣，它和反应，阅读了部分规范和相关页面，并决定我只是专门一篇关于这个主题的帖子。作为免责声明，我不是专家，我没有彻底阅读过W3C文档，从未编写过自己的XML解析器，而且对整个XML故事的深入程度也不够深入，这限制了自己相对简单的XML应用程序。</p>
<p>但是，我确实知道这是一个重大的发展，并且可能是XML开发中最重要的一步，因为它被设想了。使用 EXI，XML 文档现在可以快速传输，并且传输大小和处理速度开销较低，最终使其成为二进制格式的一个有价值的对手，尽管二进制格式具有明显的优势，但仍然具有经常是不灵活和难以处理。</p>
<p>作为一种"公共"格式，二进制格式从未真正起步，因为处理它们并不像解析XML那样简单（或者可以）。毫不奇怪，XML 长期以来一直是公共（Web）服务和数据的格式。使用 EXI，这些 XML 提供程序现在可以（理论上）以更高的效率使用，使 EXI 成为 IT 领域长期性能改进的又一个好步骤。</p>