是否应该用文件 MD5 作为文件名？

• 資深大佬 : killergun

  文件名再加个用户信息区分？

• 資深大佬 : maichael

  看有没有删除文件和剪切文件的需求

• 資深大佬 : Licsber

  都用 md5 了 为啥不用 uuid ？

• 主 資深大佬 : imdong

  @killergun 如果要考虑 MD5 冲突的话，可能加用户信息不如加时间戳？

  @maichael 暂时计划软删除，而且图片多为 UGC 内容，连带删除可能性不大，数据库有记录文件被使用信息。

• 資深大佬 : 3dwelcome

  强迫症患者表示，写个 VFS 不香吗？服务器一堆小文件，等到要异地备份的时候，完全受不了。

• 資深大佬 : imn1

  这个其实看需求，用 md5 命名，我觉得最主要是，不需要另外搞个数据库保存文件 md5 值
  怕不同文件但 md5 冲突，就加个字段呗，例如字节数、抽固定几个字节 base64/md5 作为二步校验
  我觉得在出现冲突时才考虑加上就够了，不必所有文件预先加上

• 資深大佬 : huobazi

  用对象存储

• 資深大佬 : lxilu

  不要 MD5，实现碰撞很多年了 /t/169241

• 資深大佬 : Vegetable

  你这个可能不如另一个问题明显：
  用户把同一个文件用两个不同的名字传上来，咋办呢

• 資深大佬 : rimutuyuan

  如果能做到可能哈希冲突的数量级，直接用第三方对象存储就行了，不会差钱的。

• 資深大佬 : vance123

  不考虑攻击的话, 百亿级的文件数量, md5 冲突概率小于 1e-18

• 主 資深大佬 : imdong

  @Licsber 用 md5 实际上是想避免相同的文件存多份的。

  @3dwelcome

• 資深大佬 : Mithril

  摘要其实是不靠谱的，他的作用是在一定可靠程度下去验证两个东西是不是同一个，而这可靠程度只要你碰到了就是确定的。
  所以你不能靠摘要去给用户文件去重，只能后台完全比较。不然很容易就像之前 SHA 那样两个 PDF 一样。这东西人为制造一个碰撞很难，但是你没法保证用户上传的不碰撞。到时候没法跟用户解释你就是那 1%。你自己上传的照片为什么变成了冠希。
  个人建议，上传直接 UUID，同时另存一份摘要。然后后台跑个程序定期对摘要相同的文件做完整比较，如果完全一样那么直接把另一个文件在数据库里记录的 UUID 替掉。
  当然这是不考虑删除的情况。

• 資深大佬 : msg7086

  不考虑攻击的话，MD5 碰撞概率真的太小了。
  如果真的不放心，可以补一个别的 Hash 算法，比如说 MD5+XXH128，那要是能被攻破了，就能写论文发表了。

• 資深大佬 : msg7086

  @Mithril 1%是不是有点过分了，128bit Hash 的空间，0.000000001%还差不多，几千亿个文件能撞上一次的概率都微不足道。如果是淘宝这个体量，是要考虑碰撞的，但是普通人连下辈子转生了都不一定能遇上一次随机 MD5 碰撞。
  现在的 MD5 碰撞，也是密码学攻击碰撞而不是随机 Hash 空间内碰撞。

• 資深大佬 : lxilu

  MD5 已知能构造碰撞，肯定有人攻击啊！你也不是非 MD5 不可吧