我正在开发一个应用程序，其中客户端(用多种语言编写 - Go、C++、Python、C#、Java、Perl 以及 future 可能更多)向 SQS 提交 protobuf(在某些情况下，JSON)消息。在另一端，消息由 Python 和 Go 客户端读取和解码——取决于消息类型。 Boto 似乎会自动将消息编码为 base64，但其他语言库似乎不会这样做。或者可能还有其他一些规则？
Boto 确实有提交原始消息的选项。
这里的预期行为是什么？我是否应该自己将消息编码为 base64 - 这使得 boto 成为一个奇怪的情况 - 或者我是否遗漏了什么？
这在我的应用程序中引起了一些细微的错误，因为有一层额外的 base64 编码或解码。据我所知，没有惯用的方法来检测消息是否经过 base64 编码。最好的选择是尝试解码并查看它是否引发异常 - 我不太喜欢这种情况。
我试图寻找一些文档，但找不到任何具有明确指南的内容。也许我看错地方了？
在此先感谢您的指点。
最佳答案
您可能希望将您的消息编码为某物，因为 SQS 不会在 API 上接受消息负载中所有可能的字节组合。仅支持有效的 UTF-8、制表符、换行符和回车符。
Important
The following list shows the characters (in Unicode) allowed in your message, according to the W3C XML specification. For more information, go to http://www.w3.org/TR/REC-xml/#charsets If you send any characters not included in the list, your request will be rejected.
#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 的行为并且没有办法让它表现得不一样，我会说这是错误的行为。但是，事实上，我不得不宽容一点，说这很不寻常。
关于java - 提交到 SQS 时有关将消息自动编码为 base64 的规则，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/33019426/