我正在開發一個應用程序，其中客戶端（用多種語言編寫 - Go、C++、Python、C#、Java、Perl 以及將來可能更多）向 SQS 提交 protobuf（在某些情況下，還有 JSON）消息。在另一端，消息由 Python 和 Go 客戶端讀取和解碼 - 取決于消息類型。Boto 似乎自動將消息編碼為 base64，但其他語言庫似乎沒有這樣做?；蛘咭苍S還有其他一些規則？Boto 確實可以選擇提交原始消息。這里的預期行為是什么？我應該自己將消息編碼到 base64 中 - 這使 boto 成為一個奇怪的案例 - 還是我遺漏了什么？這在我的應用程序中造成了一些微妙的錯誤，因為額外的 base64 編碼或解碼層。據我所知，沒有慣用的方法來檢測消息是否是 base64 編碼的。最好的選擇是嘗試解碼并查看它是否拋出異常 - 我不太喜歡這種情況。我試圖尋找一些文檔，但找不到任何具有明確指導方針的內容。也許我看錯了地方？在此先感謝您的指點。
1 回答
慕勒3428872
TA貢獻1848條經驗 獲得超6個贊
您可能希望將您的消息編碼為某種東西，因為 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 的行為沒有記錄在案，并且沒有辦法讓它表現得如此，我會說這是錯誤的行為。但是，事實上，我不得不松口氣，說這很不尋常。
- 1 回答
- 0 關注
- 229 瀏覽
添加回答
舉報
0/150
提交
取消