2016-08-11 38 views
1

我試圖從我的AWS Lambda函數返回十六進制字符串作爲響應。當它到達客戶端時,數據似乎被修改。在AWS API網關響應正文中修改的數據

  • 數據:
    FF FF FF 21 F9 04 01 00 00 01 00 2C 00 00 00 00
    01 00 01 00 00 08 04 00 03 04 04 00 3B

  • 十六進制Excaped數據(發送的數據):

    \ x47 \ x49 \ x46 \ x38 \ x39 \ x61 \ x01 \ x00 \ x01 \ x00 \ x80 \ x00 \ x00 \ x00 \ x00 \ x00「 」\ xff \ xff \ xff \ x21 \ xf9 \ x04 \ x01 \ x00 \ x00 \ x00 \ x00 \ x00 \ x03 \ x04 \ x04 \ x00 \ x00 \ x00 \ x00「 」\ x01 \ x00 \ x01 \ x01 \ x00 \ x00 \ x00 \ x03b

  • 接收數據
    47 49 46 38 39 61 01 00 01 00 C2 80 00 00 00 00
    00 C3 BF C3 BF C3 BF 21 C3 B9 04 01 00 00 01 00
    2C 00 00 00 00 01 00 01 00 00 08 04 00 03 04 04
    00 3b

    如何解決這個問題?

回答

2

我最後一次檢查是不是在文檔非常明確的,但API網關真正爲JSON(或類似),並支持二進制提出是「對路線圖」,但顯然不似乎是優先權。它轉換它發送給utf-8的所有內容。

正是自己的原始數據與接收到的一個比較,你可以看到它:

47 49 46 38 39 61 01 00 01 00 80 00 00 00 00 00 ff ff ff 21 f9 04 01 00 00 01 00 2c 00 00 00 00 01 00 01 00 00 08 04 00 03 04 04 00 3b 
47 49 46 38 39 61 01 00 01 00 c2 80 00 00 00 00 00 c3 bf c3 bf c3 bf 21 c3 b9 04 01 00 00 01 00 2c 00 00 00 00 01 00 01 00 00 08 04 00 03 04 04 00 3b 

下0x7f的一切都OK,因爲Unicode代碼點是一樣的編碼的字節(U + 0047 - > 47) ,但是對於0x80或更多,則會出現問題:U + 0080 - > c2 80,U + 00FF - > c3 bf等等。

最近我們遇到了一個類似的問題:通過網關發送的二進制數據比直接訪問我們的後端時損壞和變大。這是因爲許多字節被Unicode特殊的「替換字符」又名'U + FFFD'又名'0xEF 0xBF 0xBD'取代。

如何解決?我們剛剛停止使用網關,但如果您可以承擔更大的數據,則可以使用base64進行編碼。