String 压缩包含windows文件路径的字符串的高效算法

我需要设计一种有效的方法，在长期存储有限的嵌入式系统上对包含windows文件路径的多个字符串进行编码/解码，例如C:\Users\Public\Documents\CompanyName\ApplicationName\VersionNumber\Filename.ext

目前，我们获取3个字符并将其转换为一个唯一的整数，然后将其存储在其中一个寄存器位置。由于整个单元只有约500个存储位置，很明显，对3个字符使用1个寄存器不是一个好的解决方案

应用程序工作流：

用户在Windows PC上选择一个文件

文件名如上所述进行编码，并与其他信息（与文件名无关）一起发送到嵌入式系统的持久化存储器

操作员选择何时执行步骤2中发送的信息。这可能是遥远的未来

嵌入式系统执行操作

信息（包括已解码的文件名）将发送回Windows PC

Windows PC使用操作结果更新文件

注:

对于这种混合系统（Windows PC和嵌入式系统），处理能力（CPU）不是一个约束条件。目前，我们在Windows PC上进行编码，在嵌入式系统上进行解码，但情况并非如此

Windows文件路径通常位于一个或多个位置中的一个，但是客户可以将默认文件位置更改为他们想要的任何位置，并且他们通常会这样做

修改后的算法最有可能在C++中实现。 <> P/>编码/解码的算法有哪些？

---

如果我忘记了任何重要的细节，请告诉我。我已经尽可能彻底地做了，但压缩绝对不是我的专长。

由于路径名中有许多类似的前缀，您可以使用。这节省了大量空间，而且检索速度也很快。互联网上有很多免费的实现，实现一个也很简单

这里有更多的解释为什么这是有用的。让我们将每个文件路径视为一个字符串。这些字符串中有许多具有公共前缀，例如字符串

C:\Users\Public\Documents\

将经常出现。即使你有类似的东西

C:\Users\Public\Documents\file1
C:\Users\Public\Documents\file2
.....
C:\Users\Public\Documents\file10000

然后整个前缀

C:\Users\Public\Documents\file

出现在许多文件中，我们不需要全部保存它们。但是我们也不知道这个结构是怎样的（因为它是动态的而不是静态的），所以我们不能硬编码来保存前缀x。但是trie有助于在较小的空间内维护整个字符串。e、 每一个巨大的文本搜索引擎都有一个类似trie的结构。因为他们无法保存所有的行文本，因为这样做成本高昂且需要大量硬件，而且更重要的是，在数十亿行文本中很难找到特定的文本。取而代之的是，它们使其结构紧凑，如trie

---

还有其他类似的结构可以相对有效地压缩庞大的字符串数据库，但在您的特定情况下，我认为您不仅仅是在寻找压缩字符串的方法，而是希望能够查询并快速找到相关信息。所以trie会有所帮助。

将zlib与字典结合使用。更好的解决方案取决于了解嵌入端数据和程序的空间限制、更新数据和程序的成本、更新的频率和大小、更新内容与以前内容的相关性等。

这是否适用于需要保留的字符串？“trie”似乎是一个非常宽泛的话题，所以如果我遗漏了什么，请原谅。@markf78，解释补充道。如果仍然不清楚，请让我知道如何修复它。不清楚目标的文件命名是什么。。。请精确。也不清楚您称之为寄存器的内容。在此上下文中，寄存器是一个可以存储数字（整数或浮点）的内存位置。您（一次）只存储一个文件名，对吗？或者，嵌入式设备在其有限的内存中是否有可能存在这些问题？还有，寄存器有多大（以位为单位）？三个字符似乎是一个奇怪的选择。@我不知道为什么选择了三个字符（这是一个糟糕的选择）。是的，一次只有一个文件名。寄存器为4字节，但根据API文档，寄存器的内容似乎被任意限制在999999999到-999999999的范围内。因此，一个62个字符的文件路径目前需要21个寄存器加上另一个字符串长度寄存器；您的位略少于31位，不足4个字符。虽然您可以在不做太多工作的情况下做得更好，比如说，使用每个寄存器30位，在四个寄存器中分布15个字符。如果还将长度存储在字符而不是完整寄存器中，您可以将62个字符的路径存储在17个寄存器中，而不是22…@johr我可以通过在其中一台Windows PC上进行压缩/解压缩，消除任何空间或更新嵌入式端数据和程序的成本限制。字符串数据需要与嵌入式系统实际使用的其他数据一起使用但是这个压缩字符串实际上并没有在嵌入式系统上使用。