Shlink短链接服务中查询参数空格被替换为下划线的技术解析与修复

在Shlink短链接服务的使用过程中，开发团队发现了一个关于URL查询参数处理的特殊问题：当查询参数名称中包含空格时，系统会自动将空格转换为下划线。这个问题不仅影响了空格的处理，还涉及其他特殊字符的编码转换行为。

问题现象

用户报告称，当使用类似https://internal.fqdn/F4UVN?spaces are valid=true这样的短链接时，实际重定向后查询参数中的空格会被替换为下划线，变成http://www.example.com/?spaces_are_valid=true。这种行为在某些特定场景下会造成功能性问题，比如在Tableau等系统中使用查询参数设置过滤器时，由于过滤器名称通常包含空格，这种自动转换会导致过滤功能失效。

进一步测试发现，这个问题不仅限于空格字符，还影响了一系列特殊字符的编码处理：

• %20(空格) → 下划线
• %22 → 双引号
• %2E → 下划线
• %3C → 小于号
• %3E → 大于号

技术原因分析

经过深入调查，开发团队发现这个问题的根源在于PHP语言对查询参数处理的特殊机制。当PHP解析查询字符串时，出于历史兼容性考虑，会将参数名称转换为有效的变量名格式。这一转换过程包括：

1. 将空格转换为下划线
2. 对某些特殊字符进行解码
3. 确保参数名称符合PHP变量命名规范

Shlink在处理短链接重定向时，需要合并两个来源的查询参数：

1. 短链接URL本身可能包含的查询参数
2. 用户访问短链接时附加的查询参数

为了实现这种合并逻辑，Shlink必须先将查询字符串解析为参数数组，进行必要的处理后再重新序列化为查询字符串。正是这个解析-处理-序列化的过程导致了参数名称的意外转换。

解决方案

开发团队通过以下方式解决了这个问题：

1. 保留原始查询字符串的访问方式
2. 实现自定义的查询字符串解析逻辑
3. 在参数合并处理过程中保持参数名称的原始形式
4. 确保特殊字符编码在最终重定向URL中保持不变

这种解决方案既保留了Shlink原有的查询参数合并功能，又避免了PHP内置解析机制带来的副作用。

影响与升级建议

该问题已在Shlink 4.2.2版本中得到修复。对于依赖查询参数精确传递的应用场景，特别是参数名称中包含空格或其他特殊字符的情况，建议用户尽快升级到最新版本。升级后，Shlink将能够正确处理各种特殊字符编码，确保查询参数在重定向过程中保持原样传递。

对于短链接服务开发者而言，这个案例也提供了一个重要的经验：在处理URL和查询参数时，需要特别注意语言或框架层面的隐式转换行为，必要时应该绕过默认处理机制，实现更精确的控制逻辑。