这是什么编码/为什么这些.txt文件不是纯文本？

我在浏览the deck.gl repo。它带有一些带有文本文件的示例，例如this one。这些文件有一个.txt扩展，但不是纯文本：这是什么编码/为什么这些.txt文件不是纯文本？

[email protected][[email protected]^?N?FAD 

[email protected]@@@@[email protected][email protected][email protected][email protected]@[email protected][email protected][email protected]? 
=urmwF|[email protected]@@[email protected]@[email protected][email protected][email protected]@[email protected]@GR][email protected]\[email protected][email protected]?A\T 

<[email protected]@[email protected]AIVCCEL

的例子也包含看起来好像他们正在使用这些文件进行解码，例如this one for the file above JavaScript文件。

这里究竟发生了什么？我认为这是一种减少数据大小的方法，但为什么不仅仅依靠浏览器gzip？

为什么使用纯文本扩展名时，文件显然是纯文本？为什么要有一个自定义解码器呢？

来源

2016-12-12 Richard

有可能这个数据是由一个完全不同的系统输出的，他们必须编写JavaScript来解析这个输入。并非所有的东西都可以是JSON，你知道。 – Dai

术语“纯文本”与“二进制”相反。这些数据显然符合这样的定义。 –

使用这种数据格式的真正原因只能由deck.gl自己的创建者解释，如果他们还没有在他们的博客/ github页面上这样做的话。 StackOverflow可能是错误的地方问。 – Tomalak

它看起来像使用字节值来编码坐标/ GeoJSON功能的自定义编码。

例如，该行从/dist-demo/data/building-data.txt：

!GqgmwFrhwbM}C}@@[email protected]@[email protected]@[email protected]

使用decodePolyline()效用函数这个数组解码：

[ 
    [0.00004,0.00001], 
    [40.70541,0.00002], 
    [40.7062,-74.01624], 
    [40.70619,-74.01593], 
    [40.70618,-74.01587], 
    [40.70616,-74.01582], 
    [40.70615,-74.01574], 
    [40.7056,-74.01569], 
    [40.70558,-74.0159], 
    [40.70556,-74.01582], 
    [40.70532,-74.01575], 
    [40.70527,-74.01584], 
    [40.70531,-74.01586], 
    [40.70537,-74.01605], 
    [40.70537,-74.01603] 
]

其JSON格式中的大得多。

所以我的猜测是，主要原因是能够使用小型数据文件仍然便携/可缓存。它仍然是基于行的清晰文本，所以它也是不同的。

此外，这些文件仍然是可压缩的。我假设一个完整的JSON文件不仅更大，而且还表现出比这个文件更不利的压缩特性。对building-data.txt的快速测试显示gzip/deflate（压缩比例为139,089字节至72,660字节）的压缩比大约为2：1。原始JSON中相同文件的压缩结果不会在任何地方靠近。

来源

2016-12-12 09:53:27 Tomalak

优秀的答案，谢谢！我怀疑这是自定义编码，但不确定。 – Richard

我也不确定。也许他们没有推出自己的，但实施了一些现有的编码方案。 'decodePolyline（）'函数对我来说看起来很自定义，但是要用一粒盐。 – Tomalak

这是什么编码/为什么这些.txt文件不是纯文本？

回答

相关问题