pan.baidu.com/s/后面的好像是 md5，那么问题来了

[henglinli]

md5 冲突了，会出现什么情况？
有没有人试过了？

[2pang]

你先做了一个假设 然后基于假设提出问题 不是应该先验证一下自己的假设对不对么

[henglinli]

据我发现 d.pcs.baidu.com/file/后面的这串，某些文件是 md5，某些又不是。
不想上传的原因是：尽量不用需要实名的服务。

[freed]

说不定加用户名和分享时间来计算.用户名肯定不会重复..这样这一串也就不会重复了

[zsdroid]

@henglinli #2 说的好像你不买火车票似得

[peterpei]

1:有没有这样一种可能:若是第一次分享文件，直接使用 md5 文件，若有其它用户再次分享，则可以加上 uid 或者百度有个分享顺序 ，比如 a 用户第一次分享，就是 md5，而 b 用户第二次分享，就可能是 md5 加次数
2:发 linux 版好像不对啊。。

[springmarker]

谷歌不是发布过两个一样的 pdf 吗

[t6attack]

测试了一下教科书级样本文件：
http://www.win.tue.nl/hashclash/SoftIntCodeSign/HelloWorld-colliding.exe
http://www.win.tue.nl/hashclash/SoftIntCodeSign/GoodbyeWorld-colliding.exe
离线下载跪了。两个文件分别离线到网盘，再下载到本地。发现都是第一个。

[huluhulu]

只有分享的才有这个链接，而且链接是区分大小写的，应该不是 md5，楼主想多了

[henglinli]

@t6attack lice ！之前腾讯云丢过数据，按照你的说法，百度盘也能丢数据了。

[henglinli]

@zsroid 远离百度总没错吧。国内这环境，不实名都不能发言了。

[passerbytiny]

国内网盘，多用户用特征码共享同一个文件，难道不是常识吗，为什么会有冲突的疑问。

但 md5 做特征码很 low，直接用特征码当链接更 low

[yushiro]

从逻辑上来讲，不可能是 md5。
同一个文件，特征码是一致的，如果用 md5 哈希后分享出去，打开的 web 页面显示这个文件的 owner 是谁？你好友分享给你的文件，结果你看到 owner 是陌生人？

[Showfom]

@springmarker 那个是 sha-1

[lscho]

@yushiro 从逻辑上来讲，可能是 md5，因为每次分享都存入数据库了，既然存入数据库，就有了唯一的 md5，之后就没有“打开的 web 页面显示这个文件的 owner 是谁？你好友分享给你的文件，结果你看到 owner 是陌生人？”这个问题了。

但是从实际数据来看，不是 md5。

[KevZhi]

不是 md5
md5 冲突了就会出出很大的问题
好了 解答完毕

[babytomas]

有可能只是担心自己的伪随机字符串太短、又嫌 UUID 太长且不好看，于是乎算字符串的 MD5 来作为链接名。

存链接名之前查重，这样就生成了伪随机的 MD5 且不会重复了。

[zhzer]

md5 很 low 吗，我都用的 md5 当做 session id ……

[crab]

@t6attack
@passerbytiny 应该是用 md5+文件大小 做特征的。md5 匹配大小不对不行。 腾讯的离线就是 sha1+文件大小。

[Biwood]

@t6attack 你跟楼主说的根本不是一个问题。

楼主胡乱猜测是 md5，其实只是一种 url 生成规则而已，不一定跟 md5 有关，url 不重复这是常识，不存在冲突问题。
而你测试的是云存储的机制，大部分云存储都有这种防止重复存储的解决方案，百度在这方其实做的比较一般。

[kernel]

楼上说的很清楚了，共享网址里的那一串几乎不可能是 md5，你自己写过共享链接的就知道了，直接用了文件的 md5 你要取消共享怎么办？一般就是数据库里面共享记录的 id。 至于百度是不是用 md5 来文件查重，楼上的一个实验已经很说明问题了。