VSCode C 扩展中System.Uri解析RFC合规URI的问题分析

问题概述

在VSCode的C#扩展开发过程中，我们发现System.Uri类在处理某些符合RFC规范的URI时会抛出异常。这个问题主要出现在URI主机名包含"sub-delims"字符（如#和+）的情况下，导致语言服务器无法正常处理文档请求。

技术背景

URI规范(RFC 3986)允许在主机名部分使用特定的子分隔符(sub-delims)，包括：

• !
• $
• &
• '
• (
• )
• ,
• ;
• =
• %

然而，.NET框架中的System.Uri类对这些字符进行了额外的验证，超出了RFC规范的要求。这种严格验证导致了一些实际应用场景中的兼容性问题。

典型场景

1. Perforce集成场景：当启用"Perforce for VS Code"扩展时，某些包含百分号编码#字符的主机名会导致URI解析失败。

2. 开发容器环境：在devcontainer中运行的VSCode生成的Notebook URI可能包含+字符，同样会触发解析异常。

影响分析

当遇到这类URI时，语言服务器会：

1. 无法反序列化包含问题URI的请求
2. 抛出UriFormatException异常
3. 导致服务器崩溃，无法处理didOpen等基本请求
4. 最终影响整个C#开发体验

解决方案探讨

方案一：推动运行时改进

建议.NET运行时增加完全符合RFC规范的URI解析模式：

• 优点：从根本上解决问题，符合标准
• 挑战：需要等待新版本运行时，最早可能在.NET 10中实现
• 影响：仅适用于新版本运行时，存在兼容性问题

方案二：自定义URI解析

完全替换System.Uri，实现自己的URI解析逻辑：

• 优点：完全控制解析行为
• 缺点：实现复杂，需要长期维护
• 参考：类似OmniSharp项目中的DocumentUri实现

方案三：混合处理策略

在协议序列化层避免直接使用System.Uri：

1. 使用字符串或字符串包装类处理URI传输
2. 仅在需要文件路径解析时才调用System.Uri
3. 优点：
   • 保持服务器稳定性
   • 仅影响特定功能而非整个服务器
4. 缺点：
   • 部分功能仍会受限
   • 需要重构现有代码

技术决策建议

基于当前情况，推荐采用渐进式解决方案：

1. 短期：实现方案三的混合处理策略，确保服务器稳定性
2. 中期：向.NET团队反馈问题，推动运行时改进
3. 长期：评估是否需要完全自定义URI解析方案

总结

URI解析问题看似简单，实则涉及标准合规性、框架限制和实际应用场景的复杂平衡。在VSCode C#扩展开发中，我们需要在保持稳定性的同时，逐步推动底层框架的改进，最终为用户提供无缝的开发体验。