我遇到了使用API网关作为S3代理（用于自定义身份验证）的问题，因为它不能很好地处理二进制数据（这是一个已知问题）。
我通常上传.gz或.Z（Unix压缩实用程序）文件。据我了解，由于编码问题，数据无法维护。我似乎无法找到将数据解码回二进制的方法。
原始前导字节：\x1f\x8b\x08\x08\xb99\xbeW\x00\x03
通过API GW后：��9�W�
...后跟文件名和其他数据。
“解决这个问题”的一种方法是将API GW的PUT请求标头中的Content-Encoding指定为“gzip”。这似乎迫使API GW在将文件转发到S3之前对其进行解压缩。
对于使用Unix压缩实用程序压缩的.Z文件，这同样不起作用。你应该在哪里指定Content-Encoding为'compress'。
有没有人对数据发生了什么有任何见解，以帮助阐明我的问题？另外，有没有人知道任何可能的解决方法是在通过API GW时维护我的数据编码（或者在S3中解码它）？
显然我可以直接访问S3 API（或者让API GW返回一个用于访问S3 API的预签名URL），但有几个原因我不想这样做。
我应该提一下，我对编码一点也不太了解 - 对不起，如果对我的一些问题有一些明显的答案，那就很抱歉。
答案 0 :(得分：2)
这不完全是一个“编码问题” - 事实上，API网关只是doesn't support binary data ("yet") ...因此它可能会破坏二进制数据，具体取决于相关数据的具体情况。
上传为Content-Encoding: gzip可能会触发前端组件中的解码， 能够处理二进制数据（gzip，毕竟是标准编码并且是二进制的），然后才能通过核心基础设施的请求主体...但您几乎肯定会发现这是一种不能始终如一地提供正确结果的解决方法，具体取决于具体的有效负载。它完全有效的事实看起来更像是一个错误，而不是一个功能。
目前，唯一一致可行的选项是base64编码你的有效载荷，它在线上增加了33％（base64编码为每3个字节的输入产生4个字节的输出）所以它不是很多一个办法。 Base64 + gzip与相应的Content-Encoding: gzip也应该有效，这似乎是一个非常愚蠢的建议（将压缩文件转换为base64然后gzipping结果以尝试减少其在线上的大小）但应该与API网关一致目前可以提供。