不知道下一步该怎么解决这个问题。
我的node.js azure 函数接受一个表示为base64 的文件。它对文件进行一些处理并在响应中返回处理后的文件:
module.exports = async function (context, req) {
const buf = Buffer.from(req.body.file, 'base64')
/// do processing
const file = filebuf.toString('base64')
context.res.status(200).json({ file })
}
因此,在我个人的 Azure 租户中,这工作得很好。在我的客户 azure 租户中,文件已损坏。这与输入的文件完全相同。
不确定它是否有趣,但不同租户处理的文件的前几个字节是这样的:
{
"file": "UEsDBAoAAAAAAGh+r1SoFh7uRAwAAEQMAAA..."
}
{
"file": "UEsDBAoAAAAAANh8r1SoFh7uRAwAAEQMAAA..."
}
由于某种原因,第 14 个字符左右是不同的,我不明白为什么会这样。两个函数应用都在 Linux 上运行,并且应用的运行时版本相同。
谢谢
编辑:
根据第一个答案和我对不同字节是预期的新理解,我仍然没有更接近于理解为什么一个文件已损坏而另一个文件没有。
我现在注意到正文的内容长度不同:
廉洁:
"headers":{"Transfer-Encoding":"chunked","Vary":"Accept-Encoding","Strict-Transport-Security":"max-age=31536000; includeSubDomains","x-ms-apihub-cached-response":"true","x-ms-apihub-obo":"true","Cache-Control":"private","Date":"Mon, 16 May 2022 08:25:38 GMT","Content-Type":"application/json; charset=utf-8","Content-Length":"2926356"}
损坏:
"headers":{"Transfer-Encoding":"chunked","Request-Context":"appId=cid-v1:XXX","x-ms-apihub-cached-response":"true","x-ms-apihub-obo":"true","Date":"Mon, 16 May 2022 08:24:48 GMT","Content-Type":"application/json; charset=utf-8","Content-Length":"2926368"}
这些额外的字节是从哪里来的?我想知道它是否可能存在于不同版本的 Node 之间,但我会感到惊讶。
最佳答案
这 2 个不同的字节是 ZIP 文件头的一部分,描述修改时间。
让我们看一下第一个部分的base64字符串
base64
UEsDBAoAAAAAAGh+r1SoFh7uRAwAAEQMAAA
hex
50 4b 03 04 0a 00 00 00 00 00 68 7e af 54 a8 16 1e ee 44 0c 00 00 44 0c 00 00
前 4 个字节 50 4b 03 04
是 ZIP 文件签名,0a 00
版本,00 00
标志,00 00
压缩方法,最后68 7e
文件修改时间。这是 MS-DOS 格式,可转换为 13:03:15。不用说,其中不同的时间值并不表示文件已损坏。
有关 ZIP 格式的更多信息:https://users.cs.jmu.edu/buchhofp/forensics/formats/pkzip.html
关于node.js - 相同的Azure功能,相同的输入,不同的租户,不同的输出,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/72249963/