在AWS API网关响应正文上修改的数据

问题描述

我试图从我的 AWS Lambda 函数返回十六进制字符串作为响应。当它到达客户端时，数据似乎被修改。

• 数据：
  
  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




• 十六进制Excaped Data（发送数据）：

  
  
  

  \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\x01\x00\\ \\ x2c \x00\x00\x00\x00
  \x01\x00\x01\x00\x00\x08\x04\x00\x03\x04 \x04\x00\x3b




• 接收的数据
  
  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 0 0 03 04 04
  
  00 3b

  
  
  

  如何解决此问题？

$上一次我在文档中检查了它并不是非常明确，但是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下的所有东西都可以，因为unicode代码点与编码字节（U + 0047 - > 47）相同，但是对于0x80或更多，问题出现：U + 0080 - > c2 80，U + 00FF - > c3 bf等。

b
$ b

最近我们遇到了类似的问题：通过网关发送时，二进制数据损坏并且比直接访问我们的后端时大。这是因为许多字节被Unicode特殊的'替换字符'aka'U + FFFD'又名'0xEF 0xBF 0xBD'所取代。

如何解决？我们刚刚停止使用网关，但如果您可以承担更大的数据，则可以使用base64对其进行编码。

I am trying to return hexadecimal string as response from my AWS Lambda function. When it reaches to the client the data seems to be modified.

• Data :
  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

• Hexadecimal Excaped Data ( Sent Data ):

  \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\x01\x00\x2c\x00\x00\x00\x00" "\x01\x00\x01\x00\x00\x08\x04\x00\x03\x04\x04\x00\x3b

• Received Data
  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

  How to fix this?

解决方案

Last time I checked it was not very explicit in the doc, but API Gateway is really made for json (or similar) and support for binary is 'on the roadmap' but clearly doesn't seem to be a priority. It converts everything it sends to utf-8.

Comparing precisely your original data with the received one you can see it :

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

Everything under 0x7f is OK because the unicode code point is the same as the encoded byte (U+0047 -> 47), but for 0x80 or more the problem arises : U+0080 -> c2 80, U+00FF -> c3 bf and so on.

We had a similar problem recently : binary data was corrupted and bigger when sent through Gateway than with direct access to our backend. It was because a lot of bytes get replaced by Unicode special 'replacement character' aka 'U+FFFD' aka '0xEF 0xBF 0xBD'.

How to fix ? We just stopped using Gateway but if you can afford your data to be bigger, you can base64 encode it.

这篇关于在AWS API网关响应正文上修改的数据的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！