代码之家  ›  专栏  ›  技术社区  ›  Simon_Weaver

Xml是否可以用</>压缩到最终元素?

  •  5
  • Simon_Weaver  · 技术社区  · 16 年前

    是否有任何理由可以使用如下XML:

    <person>    
        <firstname>Joe</firstname>    
        <lastname>Plumber</lastname>
    </person>
    

    无法对客户端/服务器传输进行这样的压缩。

    <person>    
        <firstname>Joe</>    
        <lastname>Plumber</>
    </>
    

    它会更小,解析速度也会更快。

    假设没有边缘条件意味着这将不起作用-有没有库可以做这样的事情?

    这对谷歌来说是一件困难的事情,事实证明:

    你的搜索- </> -不匹配任何

    建议:

    尝试不同的关键字。

    编辑:我的问题似乎有点混乱。我在谈论我自己的压缩形式。我完全知道,目前这不是XML。服务器和客户端必须“参与方案”。这对于具有很长元素名的模式尤其有用,因为这些元素名占用的带宽将减半。

    14 回复  |  直到 16 年前
        1
  •  8
  •   Pete Kirkham    16 年前

    如果您编写了一个压缩例程来实现这一点,那么是的,您可以压缩流并在另一端恢复它。

    没有这样做的原因是:

    • 解压器必须解析非标准XML,并保留它遇到的打开标记的堆栈。因此,除非您插入它而不是解析器,否则解析成本将翻一番。如果插入它而不是插入解析器,则是在混合不同的层,这可能会在某个点上造成混淆
        2
  •  5
  •   cletus    16 年前

    这不是有效的XML。必须命名结束标记。否则它可能会出错,坦白地说,我认为按照您的方式,它的可读性会降低。

    1. 这是不标准的,可能在未来很长一段时间内必须得到支持;
    2. Gzip压缩很简单,而且更有效,不会违反标准。如果您看到一个gzip八位组流,就不会把它误认为是XML。你所拥有的速记方案的真正问题是,它仍然在顶部,因此一些糟糕的、毫无戒心的解析器可能会错误地认为它是有效的,并以一个不同的、误导性的错误爆发出来;
    3. 信息论:压缩是通过消除信息的冗余来工作的。如果你用手去做,gzip压缩就不再有效,因为同样数量的信息被表示出来;
    4. 在将文档转换为此方案和从该方案转换文档时,会有很大的开销。这不能用标准的XML解析器来完成,因此您必须有效地编写自己的XML解析器和输出程序,以理解此方案(实际上,转换为这种格式可以用解析器来完成;取回它更困难),这是一项大量的工作(和许多bug)。
        3
  •  5
  •   Boris Pavlović    16 年前

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

    <person firstname="Joe" lastname="Plumber" />
    
        4
  •  5
  •   Paul Dixon    16 年前

    正如您所说,这不是XML,那么为什么还要让它看起来像XML呢?您已经失去了使用任何XML解析器或工具的能力。我也会

    • 使用XML,并在线压缩它,因为您将看到比使用您自己的方案节省更多的成本
    • YAML JSON
        5
  •  4
  •   peterchen    16 年前

    若数据的大小有任何问题,那个么XML就不适合您。

        6
  •  4
  •   13ren    16 年前

    从哲学角度看待你的问题,SGML 允许 </> 关闭标签。关于将其纳入XML标准,存在着争论。拒绝它的理由是,从结束标记中省略名称有时会导致可读性较差的XML。因此,这就是“原因”。

    可读 在电线上。另一个优点是,如果必须手动输入XML(例如用于测试),则不必关闭结束标记(次要)是一种方便。就是更 人类可写 而不是标准的XML。我说“minor”,因为大多数编辑器都会为您完成字符串补全(例如vim中的^n和^p)。

    除去关闭标签 :最简单的方法是使用如下内容: s_</[a-zA-Z0-9_$]+>_</>_

    把它们加回去 :您需要一个特殊的解析器,因为SAX和其他XML解析器无法识别它(因为它不是“XML”)。但是(最简单的)解析只需要识别打开的标记名和关闭的标记名。

    have a stack.
    scan the XML, and output it, as-is.
    if you recognize an open tag, push its name.
    if you recognize close tag, pop to get its name, and
      insert that in the output (you can do this even when there is a proper close tag).
    

    顺便说一句(作为对上面评论的回应),这是有效的,因为在XML中,关闭标记只能与最近打开的标记相对应。与嵌套括号相同。

    然而,我认为你是对的,肯定有人已经这样做了。也许可以检查Python或Perl存储库?

    编辑:您可以进一步省略尾随 </&燃气轮机;

    <person>    
        <firstname>Joe</>    
        <lastname>Plumber
    
        7
  •  3
  •   dalle    16 年前

    你所描述的是 SGML ,它使用 </>

        8
  •  2
  •   annakata    16 年前

    即使这是可能的,它也只需要更长的时间来解析,因为现在解析器必须找出关闭的内容,并且必须不断检查是否正确。

    如果您想要压缩,XML是高度gzip的。

        9
  •  1
  •   Greg Hewgill    16 年前

    tag formats in SGML . 例如,以下可能是有效的SGML:

    <p/This paragraph contains a <em/bold/ word./
    

        10
  •  0
  •   raupach    16 年前

    spec . 如果您有一个大的XML文件,最好通过zip、gzip等进行压缩。

        11
  •  0
  •   Karan    16 年前

        12
  •  0
  •   Toon Krijthe    16 年前

    是的,xml是一种很重的格式。但它有一定的优势。

    如果您认为xml对您的使用来说过于繁重,那么可以看看JSON。它重量轻,但功能不如xml。

    如果您想要非常小的文件,请使用二进制格式;-)。

        13
  •  0
  •   Svante Svenson    16 年前

    如果不使用gzip或类似的东西,我只需在发送之前和在接收端使用xml之前用一个较短的标记名替换每个标记名。所以你会得到这样的结果:

    <a>
        <b>Joe</b>
        <c>Plumber</c>
    </a>
    

        14
  •  0
  •   Martin Plante    16 年前

    不要为XML的文本内优化和降低读/写性能/简单性而烦恼。使用deflate compression在客户端和服务器之间压缩负载。我做了一些测试,压缩一个普通的10KXML文件会得到一个2.5KBLUB。删除所有端点结束标记名称会将原始文件大小降低到9k,但一旦缩小,它将再次降低到2.5k。这是一个非常好的例子,基于字典的压缩是压缩端点之间有效负载的简单方法。“”和“”将(几乎)在压缩数据中使用相同的空间。