使用Chilkat调用AWS S3 GET请求时遇SignatureDoesNotMatch 403错误

问题根源：文件名的双重URL编码 #

从提供的错误日志里的CanonicalRequest可以看到，prefix参数的值是：

prefix=recovery%2FR%C3%83%C2%A9cup%C3%83%C2%A9ration_VOL-b001.spf

其中的é被编码成了%C3%83%C2%A9，但é的正确UTF-8 URL编码应该是%C3%A9。这说明文件名被做了两次URL编码：第一次把é转成UTF-8的C3 A9，第二次又把这两个字节当成Latin-1字符再次编码，导致最终的编码值错误。AWS服务端会用正确的单次编码值计算签名，而客户端用了双重编码的值计算，自然出现SignatureDoesNotMatch。

排查与修复步骤 #

• 检查客户端编码逻辑：确认生成ListMultipartUploads请求的prefix参数时，是否对文件名做了多次URL编码。比如部分SDK或自定义代码会自动处理编码，若手动重复编码就会触发问题。
• 确保单次UTF-8编码：文件名必须以UTF-8字符集进行URL编码，且仅编码一次。正确流程是：先将文件名（如Récupération_VOL-b001.spf）转换为UTF-8字节流，再对非ASCII字符和特殊字符做URL编码，得到R%C3%A9cup%C3%A9ration_VOL-b001.spf后拼入prefix参数。
• 验证编码结果：生成请求前检查prefix最终值，确保特殊字符仅被编码一次。比如é对应的编码应为%C3%A9，而非%C3%83%C2%A9。
• 升级AWS SDK版本：如果使用官方SDK，确保版本为最新，旧版本可能存在特殊字符编码bug，升级后可解决问题。

额外验证方式 #

手动构造含正确单次编码prefix的ListMultipartUploads请求，通过Postman等工具测试，确认是否能正常返回结果，以此排除权限等其他问题。

内容的提问来源于stack exchange，提问作者Izaq110