【发布时间】：2020-09-19 10:43:15
【问题描述】：
后端：我正在使用 AWS Lambda Project .NET Core C#
在后端，我返回如下代码：
var response = new APIGatewayProxyResponse
{
StatusCode = (int)HttpStatusCode.OK,
Body = Convert.ToBase64String(fooByteArray),
IsBase64Encoded = true,
Headers = new Dictionary<string, string> { { "Content-Type", 'application/pdf' }, { "Access-Control-Allow-Origin", "*" } },
};
return response;
当我在 Mock Lambda 测试工具中进行测试时，它返回的值是正确的（我可以将字符串复制粘贴到前端，它会返回正确的 PDF 值）。
但是，当我在 AWS lambda 中部署它时，响应值发生了变化（变小）并且在 PDF 中有一些奇怪的数据（例如，假设值是 12.00 美元，它现在返回 12.000 美元）
我什么都试过了，比如我常用的：
Body = JsonConvert.SerializeObject(fooBytesWrappedInModelClass, new JsonSerializerSettings() { ReferenceLoopHandling = ReferenceLoopHandling.Ignore }),
最后，它总是返回奇怪的 12.000 美元。我不想在前端进行 hack 修复来处理多余的零，因为 PDF 是一个巨大的文件，并且可能缺少其他文本。
附加说明：我尝试了以下方法
- 字节数组直接转换为Json序列化对象
- 转换字节 数组转换为十六进制（lambda 仍然缺少响应值）
- 问题出在 Lambda 本身（因为那里的值已经不同），而不是 Api 网关
- PDF 字节数组响应的范围为 200K 到 320K
- 从 320K 中丢失的响应数量为 12K 个字符
【问题讨论】：
-
fooByteArray来自哪里？它是由您的应用程序创建的吗？您是否考虑过在 AWS Lambda 中运行的代码可能会遵循与本地不同的文化？我发现沿途的网络元素会修改请求内容（例如 base-64 中的 PDF）以更改货币数据的格式是非常不合理的。 -
是的文化是我的直接想法。我玩得很开心，在 windows 中开发和测试，然后在 linux 上部署。
-
作为一个实验，您可以生成字节数组值的哈希值并在返回响应之前记录它（注意：不要直接使用
Array.GetHashCode，it does not consider the array's contents）。我希望您在 AWS Lambda 与您的开发环境中看到不同的哈希值，这表明实际的 PDF 在您发送之前有所不同。 -
我在后端使用 3rd 方库来生成 PDF 字节，所以它可能是 3rd 方库将小数转换为 3 位。我只关注为什么 320K 字符数缺少 12K 字符作为回应，并没有真正考虑文化......我将尝试看看我是否可以设置文化（我的 AWS 指向新加坡地区）
-
我不完全确定如何概括这个问题的答案，以便它可以帮助其他人，但我尝试了一些东西。不管怎样，很高兴能帮到你。
标签： c# arrays json aws-lambda response