在 JavaScript 中存储文本文件（包含 25% 的重复单词）的算法答案

【问题标题】：Algorithm to store text file (with 25% of repeated words) in JavaScript在 JavaScript 中存储文本文件（包含 25% 的重复单词）的算法
【发布时间】：2012-05-14 15:49:03
【问题描述】：

我有文本文件格式的原始数据，其中包含大量重复标记 (~25%)。我想知道是否有任何算法可以帮助： (A) 以紧凑的形式存储数据 (B) 然而，允许在运行时重构原始文件。

有什么想法吗？

更多细节：

原始数据在纯 html+javascript 应用程序中使用，以便使用正则表达式进行即时搜索。
数据由包含（区分大小写）字母字符和少量标点符号的标记组成。
标记用空格、换行符分隔。

迄今为止最有前途的算法：下面讨论的简洁数据结构，但重构看起来很困难。

http://stevehanov.ca/blog/index.php?id=120

http://ejohn.org/blog/dictionary-lookups-in-javascript/

http://ejohn.org/blog/revised-javascript-dictionary-search/

PS：目前正在使用服务器端 gzip，但它只是一种传输层优化，并无助于最大限度地利用离线存储。鉴于 25% 的大量重复性，应该可以以更紧凑的方式存储，不是吗？

【问题讨论】：

使用服务器端 gzip 压缩怎么样？
您可以使用deflate/inflate，它应该非常适合此类任务。
如何消费数据？是否会使用 AJAX 请求从服务器加载？
我不太确定你想要激活什么，但一些 JavaScript 混淆是为了压缩数据。如果你有冒险的心情，你可以尝试在 JavaScript 中实现 LZ 压缩算法。
确认！很抱歉没有提供实际使用的细节。这是为了允许使用正则表达式进行实时搜索。 gzip 已启用，并且有很大帮助。我已经玩过 jsunzip，将数据从 .png 编码/解码到画布。虽然有一种算法完全适合这个（紧凑表示+动态重构）要求，但我有一种烦人的感觉。

标签： javascript algorithm

【解决方案1】：

鉴于实际用途还不清楚，我不知道这是否有用，但对于最小的总大小（html+javascript+data），有些人想出了将文本数据存储在灰度 .png 中的想法文件，每个像素一个字节。然后，一个小的加载器脚本可以将 .png 绘制到画布上，逐个像素地读取它并以这种方式重新组合原始数据。这使您无需在 Javascript 中实现压缩即可缩小压缩。参见例如here 了解更多详细信息。

请不要使用这样的技术，除非您有非常深奥的要求，例如对于规模受限的编程竞赛。你的同事会感谢你的:-)

【讨论】：

不要这样做，即使有深奥的要求。解包数据所花费的时间（250k 为 6 秒）不仅可能比传输未压缩的数据要长，而且在 JavaScript 中实现任何类型的压缩简直是愚蠢的，因为 JavaScript 是单线程的。
确认！很抱歉没有提供实际使用的细节。这是为了允许使用正则表达式进行实时搜索。 gzip 已启用，并且有很大帮助。我已经玩过 jsunzip，将数据从 .png 编码/解码到画布等。尽管有一种算法完全适合这个（紧凑的表示 + 动态重构）要求，但我有一种唠叨的感觉。有什么想法吗？
@josh3736 对于某些用途，这是完全可以接受的，尽管我提到的那个是我所知道的唯一一个 - 如果你想尽可能多地进入 4kb 的比赛，任何事情都会发生：P 现在我们对这个问题有更多了解，我同意这个想法在这里没有用。

【解决方案2】：

一般来说，尝试在 JavaScript 中实现压缩是个坏主意。压缩正是 JS 最不擅长的工作类型：CPU 密集型计算。

请记住，JS 是单线程的¹，因此在解压缩数据的整个过程中，您都会阻塞浏览器 UI。相比之下，HTTP gzipped 内容由浏览器异步解压。

鉴于您必须重建整个数据集（以便针对正则表达式测试每条记录），我怀疑 Succinct Trie 是否适合您。老实说，我怀疑你会得到比原生 gzipping 更好的压缩。

^{1 - 尽管有网络工作者。}

【讨论】：

同意解压和 javascript 的单线程是糟糕的合作伙伴。这就是为什么对 jsunzip 不感兴趣的原因。这里有一个很大的动机：gzip 只提供传输级别的优化。一旦原始数据到达客户端，大小气球就会恢复到原始大小。考虑离线存储..您正在尝试将其最大化。至少从概念上讲，这些数据的熵（即如此多的重复）似乎表明我们可以以更紧凑的格式存储它。是吗？