在 AWS SimpleDB 中更新值时使用非 ASCII 字符返回 SignatureDoesNotMatch 错误答案

【问题标题】：Using non ASCII characters when updating values in AWS SimpleDB returns SignatureDoesNotMatch error在 AWS SimpleDB 中更新值时使用非 ASCII 字符返回 SignatureDoesNotMatch 错误
【发布时间】：2012-02-29 12:24:34
【问题描述】：

我正在开发一个将一些数据存储在 Amazon SimpleDB 实例中的应用程序。在此数据库中更新值时，我从 API 收到错误：

Array ( [curl] => [Errors] => Array ( [0] => Array ( [Code] => SignatureDoesNotMatch [Message] => 我们计算的请求签名与您提供的签名不匹配。请检查您的AWS Secret Access Key 和签名方法。详情请查阅服务文档。[BoxUsage] => ) ) )

我发现如果我尝试使用一些非 ASCII 字符（如“ØÆÅ”）更新数据库，就会发生这种情况。我已经仔细检查了用于生成签名的时间戳是否有问题（就像 Stack Overflow 上有关该主题的一些问题所暗示的那样）。

谁能确认 SimpleDB 不支持这些字符？有人对此有解决方法吗？

我正在使用第 3 方库来访问数据库。可以在这里找到：http://sourceforge.net/projects/php-sdb/

编辑：

对第 3 方库的进一步调查表明，所有参数都使用rawurlencode() 进行编码。据我所知，它也遵循了亚马逊的要求，可以在这篇文章中找到：http://aws.amazon.com/articles/1928

所以我不知道接下来该尝试什么。

编辑 2：

我想我可能会在这里解决这个问题。我有一个 iPhone 应用程序，它也使用相同的 PHP API 来存储值。发布这些非 ASCII 字符时，应用程序可以正常工作。在应用程序中，我们将“Content-Type”设置为“application/x-www-form-urlencoded”。

我找到了一些描述相同的文章：

http://chris.finne.us/2010/04/12/amazon-simpledb-signaturedoesnotmatch-error-when-putting-utf-8-characters-via-a-http-post/

http://groups.google.com/group/simple-record/browse_thread/thread/aa3cd430b35e8e1c?pli=1

我尝试在我的代码中指定content-type，但尚未成功。该实现使用 PHP 函数 curl 来执行请求。我已经添加了这段代码来设置标题，但它似乎没有任何区别：

($headers variable declared at the top of the class)
$this->headers[] = 'Content-Type: application/x-www-form-urlencoded;charset=utf-8';
curl_setopt($curl, CURLOPT_HTTPHEADER, $this->headers);

【问题讨论】：

添加了一些我认为是问题的信息。我认为需要在请求上设置 Content-Type 才能使其工作。通过相同的 API 从 iphone 发布非 ASCII 字符可以正常工作，而从 php 脚本中则不行。
会不会是编码问题？您提到了 ASCII，但亚马逊想要规范化的 UTF-8。见docs.amazonwebservices.com/AmazonSimpleDB/latest/DeveloperGuide/…
是的，一切都表明这是一个编码问题。通过始终确保将值发布到脚本，然后再将它们再次发布到亚马逊，我已经能够规避这个问题。这似乎以某种方式应用了正确的内容类型元数据，并且亚马逊接受了这些字符。这不是最好的解决方案，但考虑到我的项目时间框架，它会做。
由于 UTF-8 是 US-ASCII 的严格超集，ASCII === UTF-8。但是，如果数据设法被编码为 Latin1 (ISO-8859-1) 或 Windows-1252，您几乎肯定会遇到问题。

标签： php amazon-web-services http-headers amazon-simpledb

【解决方案1】：

我通过将数据发布到 php 脚本，然后使用此脚本将值发布到亚马逊来规避了这个问题。这解决了我在直接从 cookie 中读取值时遇到的内容类型问题。

【讨论】：

【解决方案2】：

使用 3rd 方库不是一个好主意，因为如果他们有错误，那么比在您自己的代码中更难找到它。

【讨论】：

我假设您完全从头开始构建所有东西，包括您自己的操作系统、编译器等？重新发明轮子很少是一个好主意。哦，这真的没有回答这个问题......
是的，我同意。我倾向于尽可能多地使用 3rd 方库。前提是他们很好。