关于在提交给SQS时将消息自动编码到base64的规则 我正在开发一个应用程序，其中客户机（用多种语言编写，如GO、C++、Python、C、java、Perl，并且将来可能会更多）将PotoBuf（和在某些情况下，JSON）提交给SQL。在另一端，消息由Python和Go客户端读取和解码，具体取决于消息类型。Boto似乎会自动将消息编码到base64中，但其他语言库似乎不会这样做。或者可能还有其他一些规则

Boto确实有一个提交原始消息的选项

这里的预期行为是什么？我应该自己将消息编码到base64中吗？这让boto成为一个奇怪的例子，还是我遗漏了什么

这在我的应用程序中造成了一些微妙的错误，因为有一层额外的base64编码或解码。据我所知，没有惯用的方法来检测消息是否是base64编码的。最好的选择是尝试解码，看看它是否抛出异常——这是我不太喜欢的

我试图查找一些文档，但找不到任何有明确指导方针的文档。也许我看错地方了

---

提前感谢您提供的任何指针。

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

重要

根据W3C XML规范，下面的列表显示了消息中允许的字符（Unicode）。有关更多信息，请转到。如果发送列表中未包含的任何字符，您的请求将被拒绝

#x9 | xA | xD |[#x20到#xD7FF]|[#xE000到#xffd]|[#x10000到#x10FFFF]

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

据推测，boto会自动为您对base64消息进行编码和解码，以“提供帮助”

但根本没有理由使用base64。

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

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

---

如果波托的行为没有被记录在案，也没有办法让它做出其他的行为，我会说这是错误的行为。但是，事实上，我不得不稍微缓和一点，说这很不寻常。

我只是希望各种SDK的行为是一致的。或者有一本明确的规则书规定哪些语言自动编码，哪些不自动编码，而不是必须彻底检查每一个API引用。似乎是合法的。但boto不是SDK，至少最初不是。更像是领养的继子。boto3是否也会使用Base64编码自动编码和解码SQS消息？@bappak它不应该这样做，否则“消息只能包含XML、JSON和未格式化文本”就没有意义了，因为这是使用Base64的典型原因——通过只支持字符数据的通道传递任意二进制数据。此外，boto3的

send_message（）

的

MessageBody

参数的数据类型为string。所有这些都意味着，如果负载不是utf8文本，那么在传递它之前，您需要自己对它进行编码。