Re.Pack项目中ScriptLocator双重编码问题的分析与解决

在React Native应用开发中，Re.Pack作为一个强大的模块化打包工具，被广泛应用于优化应用性能和管理代码资源。然而，近期发现了一个影响资源加载的关键问题：当通过ScriptLocator获取远程bundle时，URL查询参数会被意外地进行双重编码，导致资源请求失败。

问题现象

开发者在使用Azure存储托管bundle文件时，发现需要传递包含特殊字符的认证令牌参数。例如传递时间戳参数"t=2024-09-04T04:56:27Z"时，系统会出现异常行为。经过深入排查，发现查询参数在传输过程中被编码了两次：

1. 第一次编码发生在JavaScript层，通过URLSearchParams进行标准编码
2. 第二次编码发生在原生iOS层，在构建最终请求URL时再次对已编码的参数进行编码

这种双重编码会导致原始参数值被破坏，特别是当参数包含保留字符（如冒号、加号等）时，服务器无法正确解析参数，最终导致资源加载失败。

技术分析

在iOS平台实现中，ScriptLocator的URL构建流程存在逻辑缺陷。当处理查询参数时：

1. JavaScript层已经按照标准对参数进行了百分号编码
2. 原生层在拼接URL时，错误地将整个查询字符串再次进行编码处理
3. 而Android平台的实现则正确处理了这种情况，没有进行二次编码

这种平台差异性的实现导致了iOS平台上特有的问题。例如，原始参数中的冒号":"在第一次编码后变为"%3A"，第二次编码后又变为"%253A"，使得服务器端无法识别原始参数值。

解决方案

修复方案的核心思想是确保查询参数只被编码一次。具体实现包括：

1. 在iOS原生代码中移除对已编码查询参数的二次处理
2. 保持与Android平台一致的行为，信任JavaScript层已经提供的正确编码结果
3. 确保URL构建过程中各组件拼接符合RFC标准

该修复已通过测试验证，能够正确处理包含各种特殊字符的查询参数，包括但不限于：

• 时间戳中的冒号和加号
• 认证令牌中的特殊符号
• 各种保留字符和百分号编码序列

最佳实践建议

对于使用Re.Pack的开发者，在处理远程bundle加载时应注意：

1. 对于包含特殊字符的查询参数，确保在JavaScript层正确编码
2. 避免在原生层对URL组件进行不必要的编码处理
3. 跨平台开发时，应对URL处理逻辑进行充分测试
4. 对于认证令牌等敏感参数，建议进行额外的完整性验证

这个问题提醒我们在处理URL和网络请求时，需要特别注意编码的一致性和平台差异性，特别是在React Native这种跨平台框架中。合理的编码策略应该遵循"一次编码，全程有效"的原则，避免多层编码导致的不可预测行为。