本文主要是介绍formidable上传文件hash不一致，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
1.什么是formidable
formidable是什么？搜一搜大家就知道了，node的form表单上传模块，尤其是处理文件上传。
以下是npm中的优势介绍：
- Fast (~900-2500 mb/sec) & streaming multipart parser
- Automatically writing file uploads to disk (optional, see options.fileWriteStreamHandler)
- Plugins API - allowing custom parsers and plugins
- Low memory footprint
- Graceful error handling
- Very high test coverage
中文：
- 快速（~900-2500 mb/秒）和流式多部分解析器
- 自动将文件上传写入磁盘（可选，请参阅 options.fileWriteStreamHandler）
- 插件 API - 允许自定义解析器和插件
- 内存占用低
- 优雅的错误处理
- 非常高的测试覆盖率
所以：
高写入、低占用、支持GB级上传数据处理，是它被使用的理由。
想具体理解的话，可以移步npm官方地址介绍
npm地址：https://www.npmjs.com/package/formidable
2.问题情景及原因追溯
具体如何使用这个模块，相信大家都能找到。那么，我来说一下，遇到的一个问题。
需求如下：
有一个需求，上传的压缩文件，如果有相同的，则不允许重复上传，如果有改动，则可以更新上传。
问题场景：
之前开发者自测时传过的压缩包，测试没问题，然后发给了产品经理，产品经理手闲，不小心上传到了测试环境，发现，依旧可以上传。所以产品经理有疑问，是不是发给他的不是最新的压缩包？
问题查询：
怎么回事？明明没有修改，为什么能重复上传呢？我陷入了怀疑？难道真的不是最新版？使用的对比工具，发现，并没有修改，就是最新的包，那么？问题在哪里呢？
我去查了formidable对hash的计算逻辑，发现，逻辑是：
crypto.createHash("sha1").update(buffer).digest('hex')
所以：压缩包的buffer不一致。
压缩包文件不一致？一样啊？那么，哪里的问题勒？
会不会是产品经理传成旧版本了？（程序员：我本地没问题啊！）
看了一遍产品经理的操作，发现，不对啊，你的文件名称跟我的不一样？
仔细一看，我通过钉钉给他发了多次，所以导致，我本地压缩包名称是：test1.zip,他下载到本地的压缩包是test1（5）.zip
所以，结论来了。
问题结论：
结论1.压缩包的文件名称修改了
结论2.在他下载后，他的压缩包的创建时间、修改时间是他下载的时间
所以，压缩包的元数据变了，导致，formidable在验证文件信息的时候，hash值不一致，所以，显示不同文件，允许更新。
总结：
formidable的文件hash生成是基于文件的所有信息进行的。即使文件内容相同，文件的元数据（例如修改时间）发生变化也会导致生成的哈希值不同。
哈希算法通常是对输入数据进行处理生成固定长度的输出，如果输入数据有任何变化，哪怕是一点点，生成的哈希值也会完全不同。因此，如果你在同一天内使用相同的文件来生成哈希值，结果是相同的，因为文件内容相同，但在不同的日期，可能是文件元数据的变化导致了不同的哈希值。
之前也有其他开发遇到过这个问题，都以偶现，无法复现，不予解决处理。
但是其实，仔细追溯一下，并不是无迹可寻，用心，再用些技巧，怎么不能解决呢？
出现了，就会有痕迹。你找不到，是你没认真！
这篇关于formidable上传文件hash不一致的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
