提交到 SQS 时将消息自动编码为 base64 的规则

Question

我正在开发一个应用程序，其中客户端（用多种语言编写 - Go、C++、Python、C#、Java、Perl 以及将来可能更多）向 SQS 提交 protobuf（在某些情况下，还有 JSON）消息。在另一端，消息由 Python 和 Go 客户端读取和解码 - 取决于消息类型。Boto 似乎自动将消息编码为 base64，但其他语言库似乎没有这样做。或者也许还有其他一些规则？Boto 确实可以选择提交原始消息。这里的预期行为是什么？我应该自己将消息编码到 base64 中 - 这使 boto 成为一个奇怪的案例 - 还是我遗漏了什么？这在我的应用程序中造成了一些微妙的错误，因为额外的 base64 编码或解码层。据我所知，没有惯用的方法来检测消息是否是 base64 编码的。最好的选择是尝试解码并查看它是否抛出异常 - 我不太喜欢这种情况。我试图寻找一些文档，但找不到任何具有明确指导方针的内容。也许我看错了地方？在此先感谢您的指点。

Answer 1

您可能希望将您的消息编码为某种东西，因为 SQS 在 API 处不接受消息有效负载中所有可能的字节组合。仅支持有效的 UTF-8、制表符、换行符和回车符。

重要的

根据 W3C XML 规范，以下列表显示了您的消息中允许的字符（Unicode）。如需更多信息，请访问http://www.w3.org/TR/REC-xml/#charsets如果您发送列表中未包含的任何字符，您的请求将被拒绝。

#x9 | #xA | #xD | [#x20 to #xD7FF] | [#xE000 to #xFFFD] | [#x10000 to #x10FFFF]

http://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html

base64 字母表显然落在这个范围内，使得带有 base64 编码的消息不可能被视为无效而被拒绝。当然，它也会使您的负载膨胀，因为 base64 会将原始消息的每 3 个字节扩展为 4 个输出字节（64 个符号将每个输出字节限制为携带 6 位可用信息，3 x 8 → 4 x 6）。

大概 boto 会自动为您进行 base64 编码和解码消息，以便“有用”。

但是完全没有理由必须使用 base64。

想到的一个例子......有效的 JSON 也将符合 SQS 有效负载支持的受限字符范围。（从理论上讲，我想，JSON 可以被认为不是“编码”，但这有点迂腐）。

除了您提出的粗略方法之外，没有明确的方法可以确定一条消息是否需要多次解码，但是可以提出这样的论点，即如果您处于解码需要不明确的情况下，那么应该被淘汰。

如果 boto 的行为没有记录在案，并且没有办法让它表现得如此，我会说这是错误的行为。但是，事实上，我不得不松口气，说这很不寻常。