SuperEditor 中非标准 URL 链接的自动识别问题解析

在富文本编辑器 SuperEditor 的开发过程中，我们发现了一个关于非标准 URL 链接自动识别的问题。具体表现为，当用户输入类似 Obsidian 应用链接（如 obsidian://open?vault=98_Obsidian_NEW_2023&file=30-）这样的非标准 URL 时，编辑器无法自动将其转换为可点击的链接。

问题背景

SuperEditor 使用 LinkifyReaction 组件来处理文本中的链接自动识别功能。该组件底层依赖于 linkify 库，默认配置了两种链接识别器：

1. UrlLinkifier - 用于识别标准 HTTP/HTTPS 等网络 URL
2. EmailLinkifier - 用于识别电子邮件地址

然而，这种默认配置存在局限性，无法识别应用特定的 URI 方案（URI scheme），如 obsidian:// 这样的应用深层链接。

技术分析

URI 方案是 URI 的重要组成部分，位于冒号（:）之前。虽然常见的网络 URL 使用 http:// 和 https:// 方案，但许多应用程序会注册自己的方案以实现深层链接功能。例如：

• obsidian:// - Obsidian 笔记应用的深层链接
• slack:// - Slack 客户端链接
• zoommtg:// - Zoom 会议链接

当前的 UrlLinkifier 实现可能过于严格，只匹配有限的已知网络协议方案，导致这些应用链接无法被正确识别。

解决方案探讨

针对这一问题，我们提出了几种可能的解决方案：

1. 宽松的 URI 方案识别
   修改链接识别逻辑，接受任何包含 :// 分隔符的字符串作为有效链接。这种方案实现简单，但可能产生误识别。

2. 可配置的 URI 方案白名单
   允许开发者指定需要识别的额外 URI 方案列表，如 ['obsidian', 'slack', 'zoommtg']。这种方式更加精确但需要额外配置。

3. 自定义链接识别器
   开发者可以继承 Linkifier 类实现自己的识别逻辑，专门处理应用特定的链接格式。

从技术实现角度看，第一种方案最为通用，因为它不需要预先知道所有可能的 URI 方案，能够适应各种应用场景。我们可以在 linkify 的 URL 识别模式中，将严格的协议检查改为接受任意字母数字组合后跟 :// 的模式。

实现建议

基于以上分析，建议采用宽松的 URI 方案识别策略。具体实现可考虑：

1. 扩展 UrlLinkifier 的正则表达式模式，使其能够匹配任意有效的 URI 方案
2. 确保识别后的链接能够正确转换为 URI 对象
3. 添加测试用例验证各种应用链接的识别情况

这种改进既能解决当前 Obsidian 链接的问题，也能兼容未来可能出现的其他应用链接格式，为开发者提供更好的开箱即用体验。

总结

SuperEditor 作为一款功能强大的富文本编辑器，处理各种链接格式的能力至关重要。通过改进链接自动识别逻辑，我们能够更好地支持现代应用生态系统中广泛使用的深层链接，提升编辑器的实用性和用户体验。这一改进也体现了良好软件设计的原则：在保持核心功能稳定的同时，通过适度的灵活性来适应各种使用场景。