@moioooo 你的控制台应该显示类似这样。User ID: 1 Authorization successful. 728 days remaining until expiration.

User ID 后面那个数字是你的 id ，那个框框是对号，我看来应该把这个对号去掉，否则微软 cmd 和 powershell 等等可能显示不一致。

@moioooo 自用或者分享都可以，你可以自行处置所有的激活码。是的，所有 pro 版本自带 30 天试用，uid 是在软件启动的命令行上显示，因为我不想在页面 web 上显示这个，主要是隐私考虑。命令行上的框框应该是编码问题，等过期了它其实会自己访问激活页面并且自动填入 uid ，你到时候只需要输入激活码即可。

@moioooo 10 个激活 cdkey 已经发送，请检查邮件，如果没收到请查看垃圾邮件

@moioooo 谢谢你的打赏，你是唯一一个打赏的，请把你的姓氏，只要姓氏，打赏留言内容和打赏金额发送到 [email protected]

如果你想不起来当时打赏留言之类的信息，如果你有打赏转账单号也可以发送到上面邮箱。

信息验证无误后，我会邮件回复送你 10 个增加一年使用期限的激活码，至于你是想一下自己一个机器激活 10 年还是给 10 个机器各自激活完全由你决定。激活码需要在 1 年内使用掉。

我本来是想走完整开源路线打造跨平台文件名文件内容搜索引擎，但是我发现靠打赏只有你打赏了一笔，半年高强度研发，为了提高性能推翻了 4 到 5 次架构设计，如果指望打赏，那真是吃饭都困难，所以这次商业化路线只能走收费了。

@dreamkuo 网页里面有完整性能功能详细对比。

@bronyakaka 禁止造谣，闭源怎么了，其他类似能达到这个效率的软件哪个不闭源，想白嫖别人核心算法？还木马，笑话，看看 https://habo.qq.com/file/showdetail?pk=ADEGZF1lB2UIMVs6U2oHYA%3D%3D

@humbass 上来动不动就最烦，我可以翻过来说，我最烦你这种不认真审题的，我哪里写我必须开源的，github 使用条例哪一条说必须完全开源才能创建 repo ，没人逼你用，你既不是投资人也不是赞助者，你的意见压根不重要，不要像个领导一样发号施令。

@NoOneNoBody 我也没逼着你用啊，你说的一切无非是加个功能而已，everything 做了 20 年，都没满足你的全部需求，让我上来满足一切？

@NoOneNoBody everything 开放的 sdk 功能很有限，这是理所当然，如果开放的功能超过其本身就会功高盖主。对于那些只需要短暂用一下的项目，sdk 是可行的，因为这种项目出发点就仅仅是能用而已。但是我的出发点是做一个大系统，我认为为了支持更多的功能，自研算法是唯一出路。我喜欢研究底层原理，不管做什么，我喜欢了解底层原理。在研制核心搜索算法的过程中我也提高了很多，这些技术积累将用于我其他的工作上，我认为非常有益。

至于你说的这些 everything sdk 无法满足的这些，因为我算法是自研的，我全都可以做到，无非是花时间的问题了，如果一开始用了受限的 sdk 再去想加一些功能甚至比自研还要麻烦。

@NoOneNoBody 你说的这些问题我当然都研究过，他自己的 SDK 功能很不全，和他自己的搜索差很多。而且只有自己写出来核心算法才能真的学到东西，成天调 SDK 就只能永远只做个一个调包侠。

@moioooo 没关系，目前是 demo 版本主要研究的是搜索核心算法的性能。其他这些问题我会后续解决。因为只有先解决了文件名搜索下一步才能解决文件内容搜索。

顺便说一句，如果不想用 hosts ，也可以采用 https://github.com/FilePulseSoft/FilePulse 里面提到的“方案一：极简启动”，如果只希望在本地运行的话，可以直接输入 https://127.0.0.1 ，这样就不需要改 hosts 了。

我做这个工具的初衷是由于我需要远程对机器上的文件进行搜索，下载等操作，所以我才选用的 http2/http3 ，而 everything 的 http 服务是 http1.0 ，这个实在太老了，无法支持未来我的远程办公，远程协作，远程差异化存储等操作。所以我才下定决心做一个自己的。

@moioooo https://github.com/FilePulseSoft/FilePulse 在未来计划有提到，这个是第一步，未来会支持毫秒级文件内容搜索，将会成为一个既可以搜索文件名又可以搜索内容的实时搜索系统。

@cat9life 早就有详细对比在 github ，主要优势未来计划都在里面，v2ex 没法写这么全，内容越长 V2EX 扣费越多

https://github.com/FilePulseSoft/FilePulse

@gwy15 谢谢回复，但是我把 HS_FLAG_LITERAL 改成了 0 或者其他值后，输出结果是下面，还是不对，头疼
Hyperscan 版本: 5.4.2 2024-10-06
模式 "test" 首次出现位置: 0
模式 "string" 首次出现位置: 0
模式 "example" 首次出现位置: 0
模式 "中文" 首次出现位置: 0

@kuanat 恕我直言，你这个和没逆向没有任何区别。
1.MFT 和 USN 这个所有人都知道，根本不需要逆向，直接跳过。
2.文件大小，修改时间这些信息当然不用逆向都知道必须存内存，否则根本无法这么快。能优化排序的方法就那么几个，和没说一样。
3.唯一有逆向价值的就是，everything 作者自述它自己实现了高度优化的正则引擎，而这个你又根本什么都没分析出来。
4.pcre 需要外部安装，这根本不需要逆向，Levenshtein 内存消耗太大，everything 搜索的时候根本内存变化很小，根本没必要逆向就知道不使用的外部 PCRE 或者 RE2 。

恕我直言，你这个逆向和没逆向没有任何区别，都仅仅是泛泛而谈，不停的在表示 everything 没壳没混淆很好分析，而我表示大部分算法级别从汇编还原是非常难的。

我可没有泛泛而谈，每一个实现方法我都说出了具体算法名字和我自己实现后大约什么性能，我是真的做过测试。既然这样你认为逆向分析 everything 这么简单，那你就分析一下作者这个高度优化正则引擎具体是怎么做的，把具体分析的地址和对应汇编贴出来还有你分析过的 everything 版本都发出来，我看得懂汇编，我也懂动态和静态逆向分析，请不要泛泛而谈。Talk is cheap. Show me the code.

@ntedshen 感谢手动测试，类似的测试我试过，你看你的索引文件已经超过 120MB ，显然还是 everything 的方式更小，而且你这样做是不支持 everything 正则表达式的，everything 正则表达式和普通搜索是几乎一样速度，而且你只获取了前 500 个，这个不能说明问题，如果不优化会出现深分页问题。还有就是这种方法我也尝试过，如果大量插入数据，无法在 1 秒内对 100 万文件实现插入。

@iseki
@soy
非常感谢两位，这个作者的回复收益良多。我自己测试过，多线程正则的确能将速度压倒 6 到 10 毫秒，对方是经过特殊优化的，我这个只是通用的。
我想问一下“至于搜索结果快速排序，everything 额外维护了一个快速排序索引，所有文件已经按日期/大小等索引预排序了”这个具体如何做？

根据我的理解，比如按文件大小排序，文件大小是排序 key ，然后每一项至少还得保存一个指针指向自己的主结构吧，然后遍历这个提前排好的数组或者链表，然后一个一个走正则。当文件变动的时候这个数组或者链表也要调整。

@kuituosi 我想了解一下，如何剪枝，怎么剪枝这很关键。剪枝一般用于树，全文索引可不是树，你怎么剪枝呢？请给一个具体例子

@BeautifulSoap 感谢，你是唯一愿意自己动手测试一下，go 语言我也会，我一开始整个项目就是 go 写的，后来发现性能完全不能满足我的要求，所以我换成了比 go 更快的编译型语言写。正如你自己所说，你是用的随机字符串，并不是真实数据，所以就会有很大的偏差，我当然自己也试过，我不是那种不动手就上来。实验结果就是真实数据单线程查询超过了 40 毫秒，因为我搜的是包含"a"，100 万真实数据有大量是包含“a”的，而且有个最关键因素，你搜的[]string 吧，真实数据每一个记录不可能 string ，因为至少还有文件大小，修改时间等等，一带上这些立刻性能严重下降，为什么会突然下降呢？这个问题留给你