Xml可以用</>压缩到结束元素吗？

是否有任何理由为什么这样的XML:

    
    Joe    
    Plumber

无法像这样压缩客户端/服务器传输.

    
    Joe    
    Plumber

它会更小 - 解析起来稍快一点.

假设没有边缘条件意味着这不起作用 - 是否有任何库可以做这样的事情？

事实证明这是一件很难的事情:

您的搜索 - - 与任何文件都不匹配.

建议:

尝试不同的关键字

编辑:似乎是我所要求的混乱.我正在谈论我自己的压缩形式.我完全清楚,因为它不是XML.服务器和客户端必须"参与计划".对于具有很长元素名称的模式,这将特别有用,因为这些元素名称占用的带宽将减半.

如果您编写了一个执行该操作的压缩例程,那么是的,您可以压缩流并在另一端恢复它.

没有这样做的原因是:

已经存在更好的XML不可知压缩方案(就压缩比而言,可能在CPU和空间方面 - 某个7 N UTF-8文档将获得14%的压缩但需要至少2 N字节空间来解压缩,而不是大多数解压缩算法所需的恒定空间.

已经存在更好的XML感知压缩方案(谷歌'二进制xml').对于模式感知压缩,基于ASN.1的方案比将指示元素类型的大小减少一半要好得多.

解压缩程序必须解析非标准XML并保留它遇到的打开标记的堆栈.因此,除非您将其插入而不是解析器,否则您的解析成本会翻倍.如果你插入它而不是解析器,你会混合不同的层,这在某些时候容易引起混淆

这不是有效的XML.必须命名结束标记.否则它可能容易出错,坦率地说,我认为你的方式可读性较差.

关于你对这是一个非标准违反XML标准以保存几个字节的说明,这是一个非常糟糕的主意,原因有以下几点:

它是非标准的,未来可能必须得到支持;

标准存在是有原因的.标准和惯例具有很强的功能,并且有"自定义XML"排名,象牙塔图形设计师迫使程序员编写自定义按钮替换,因为标准版无法做任何奇怪,奇妙和混乱的行为被设想;

Gzip压缩很容易,效率更高,不会破坏标准.如果你看到一个gzip八位字节流,那就没有错误的XML了.你得到的速记方案的真正问题在于它仍然处于最顶层,所以一些可怜的毫无防备的解析器可能会犯错误,认为它有效并且用一种不同的误导性错误炸弹;

信息理论:通过消除信息冗余来实现压缩.如果你这样做,它会使gzip压缩不再有效,因为相同数量的信息被重新设置;

将文档转换为此方案或从此方案转换文档会产生巨大的开销.使用标准XML解析器无法做到这一点,因此您必须有效地编写自己的XML解析器和输出器来理解这个方案(实际上可以使用解析器转换为此格式;将其恢复更困难),这是很多工作(和很多错误).

如果您需要更好的压缩和更容易的解析,您可以尝试使用XML属性:

正如你所说,这不是XML,为什么它甚至看起来像XML？您已经失去了使用任何XML解析器或工具的能力.我要么

使用XML,并在线上压缩它,因为您将看到比您自己的方案更大的节省

使用另一种更紧凑的格式,如YAML或JSON