您会模拟哪个正则表达式 api？
大多数编程语言都有用于正则表达式搜索和替换的 API。根据我的经验，API 可能相当笨重，可能是由于可用操作的数量和效率方面的考虑。
如果您要实现一个 api，您会模拟哪一个？
特别令人感兴趣的是 api 的方法和对象，还有正则表达式方言和对任何标准的遵守。
Most programming languages have apis for regular expression searching and replacing. In my experience the apis can be quite clunky, probably due to the number of actions available and efficiency considerations.
If you were going to implement an api, which one would you emulate?
Of particular interest is the methods and objects of the api, but also the regexp dialect and adherence to any standards.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果你模拟一个API，它会和原来的一样笨重（如果不是更笨重的话）。我不明白你在说什么。如果您真的担心正则表达式 API 会丢失 100 KB，您应该只实现一个与大型子集不同的简约子集。检查是否有任何 API 具有禁用您不需要的功能的配置。
If you emulate an API it is going to be just as clunky as the original (if not more.) I don't see what you are getting at. If you are really worried about losing 100 KB to a regex API you should only implement a minimalistic subset which wouldn't resemble a large one. Check to see if any APIs have configs to disable features you don't need.
我认为 Lua 模式匹配 API 是一个优秀的模拟 API。它在功能与简单性之间实现了极好的平衡。还有一个绝妙设计选择：正则表达式的转义字符与字符串文字的转义字符不同，因此没有反斜杠地狱。
如果我要向 Lua API 添加一件事，那就是 or 模式。
I think the Lua pattern matching API is an excellent API to emulate. It has a superb balance of power versus simplicity. And there's one brilliant design choice: the escape character for regular expressions is different from the escape character for string literals—so there's no backslash hell.
If I were to add one thing to the Lua API it would be or-patterns.
实际上已经实现了完整的正则表达式引擎（在我公司的产品中使用，例如 RegexBuddy）和基于 PCRE（Delphi 的 TPerlRegEx 组件）的公开可用的“API”，我建议不要太担心模拟这个或而是关注你的正则表达式库的用途。不幸的是，除了提到效率之外，您对此没有说太多。正确开发的库不一定会因为具有更多可用功能而降低效率。例如，PCRE 提供了功能丰富的正则表达式风格和出色的性能，但其周围的库功能有限（例如，没有搜索和替换）。但是添加更多的库功能（例如搜索和替换）不会使 PCRE 变慢，因为未使用的调用甚至不必链接到最终的 .exe。
没有正则表达式标准。只有经常以微妙的方式炫耀的惯例。如果“标准”很重要，只需使用流行的正则表达式库之一，即使它并不完美。
如果您想要现成的简约的东西，可以找到 Henry Spencer 的 regex.c 的副本，它实现了 POSIX 正则表达式。
Having actually implemented a full regular expression engine (used in-house in my company's products such as RegexBuddy) and a publicly available "API" based on PCRE (the TPerlRegEx component for Delphi), I recommend not too worry too much about emulating this or that, but instead focus on what your regex library will be used for. Unfortunately, you don't say much about this other than mentioning efficiency. A properly developed library doesn't have to be less efficient just because it has more available features. E.g. PCRE offers a feature-rich regex flavor and excellent performance, but a limited set of library features around it (e.g. no search-and-replace). But adding more library features such as a search-and-replace wouldn't make PCRE slower, because unused calls don't even have to be linked into the final .exe.
There are no regex standards. Only conventions that are frequently flaunted in subtle ways. If "standards" matter, simply use one of the popular regex libraries, even if it isn't perfect.
If you want something off-the-shelf minimalistic, dig up a copy of Henry Spencer's regex.c which implements POSIX regular expressions.