【问题标题】:Any algorithm that mangles/hashes a string but can be matched against?任何可以破坏/散列字符串但可以匹配的算法?
【发布时间】:2013-05-29 01:17:50
【问题描述】:

用例:客户端需要通过 HTTP 发送一个巨大的字符串。服务器回复字符串是否包含一些子字符串。然而,巨大的字符串是巨大的。结果,这个系统效率很低。而且,巨大的字符串包含一些敏感信息,所以这真的很不安全。

是否有某种伪散列机制以某种方式将一个大字符串汇总为某个数字,这个大字符串的所有子字符串都会散列到相同的数字,但非子字符串很可能不会散列到这个大字符串?

【问题讨论】:

  • 我不知道如何证明,但我发现这样的事情是不可能的。首先,考虑“一个巨大字符串的所有子字符串”可能包含“a”、“b”、“c”等。
  • 为什么客户端仍然发送巨大的字符串?客户端自己不能搜索子串吗?
  • 嗯。自我证明:假设存在这样的功能。然后可以将其改写为所有字符串哈希到与字符串的任何 superstring 相同的数字。假设“”哈希为0。通过这个论点,所有字符串都哈希到0,这与它可以用作子字符串的确定器是矛盾的。
  • 顺便说一句:对于每个长度为 N 的字符串,有 N(N-1) 个可能的子字符串。
  • @wildplasser:这不正确。子字符串可以被认为是在字符串中放置两个标记,一个指定开始,另一个指定结束。标记有n + 1 可能的位置,我们必须从中选择两个。但是,这忽略了计算空字符串。因此,有1 + (n + 1 choose 2) = 1 + n(n + 1) / 2 可能的子字符串。但是,这种推理假设重复的子字符串被计算多次,每次出现一次。

标签: string algorithm hash


【解决方案1】:

是否有某种伪散列机制以某种方式将一个大字符串汇总为某个数字,这个大字符串的所有子字符串都会散列到相同的数字,但非子字符串很可能不会散列到这个大字符串?

没有。

f 成为这样的哈希。考虑一个字符串s 和非子字符串t。请注意sts + t 的子字符串。因此,st 具有相同的哈希值(即f(s) = f(t) = f(s + t))。这与f(s) != f(t)概率高的要求相反。

特别是,对于s = "",我们看到所有字符串t 都有f(s) = f(t),因此f 是常量并且等于f("")

【讨论】:

    【解决方案2】:

    是否有某种伪散列机制以某种方式将一个大字符串汇总为某个数字,这个大字符串的所有子字符串都会散列到相同的数字,但非子字符串很可能不会散列到这个大字符串?

    我想我得解释一下为什么这不会发生:

    String string = "the quick brown fox jumps over the lazy dog";
    

    这意味着,根据您的要求,其中的每个字母都将散列到相同的值。散列算法是确定性的。在这个例子中,t -> 5h -> 5e -> 5...等等,但如果你有一些字符串:

    String string2 = "hello there";
    

    那么现在,您希望 h 散列到不同的值,并且您希望 e 散列到不同的值,所以给定完全相同的输入,您需要不同的值。这违背了数学函数的定义。

    这是什么意思?

    好吧,如果您的函数中没有任何确定性方面,您的数据在值和被散列的字母之间没有可重复的映射,这意味着您的数据毫无意义。

    【讨论】:

      【解决方案3】:

      如果您的子字符串长度恒定,您可以像许多文件共享程序一样使用哈希列表或类似老虎树哈希的东西。

      哈希列表:为某个预设长度(例如 64kB)的文件的每个块创建一个哈希,然后传输这些哈希的列表,以便验证这些块。

      老虎树哈希:http://en.wikipedia.org/wiki/Merkle_tree#Tiger_tree_hash 基本上构建一个哈希二叉树,叶子是块的哈希,就像在哈希列表中一样。

      如果您需要匹配每个可能的子字符串而不是只匹配预定义的块,那么这将不起作用。

      【讨论】:

        【解决方案4】:

        所有子字符串听起来都不可行,但我想您可能对尚未告诉我们的子字符串有一些限制。

        如果您将子字符串块对齐或空白对齐或其他方式,您可能会考虑使用布隆过滤器,例如:https://pypi.python.org/pypi/drs-bloom-filter/1.01。布隆过滤器可以存储集合的成员并用于测试集合的成员资格,有时每个元素只需一位。它们有时会给出误报,但误报概率可由用户调整。

        【讨论】:

          猜你喜欢
          • 1970-01-01
          • 1970-01-01
          • 2019-05-21
          • 1970-01-01
          • 2018-06-22
          • 2021-04-12
          • 2010-11-19
          • 2015-12-14
          • 2015-03-16
          相关资源
          最近更新 更多