为什么要尝试大小写不同的MD5？

[void285]

看了下源码，发现会尝试大写、小写、混合大小写的MD5，不太明白为什么要这样做，请赐教。

                switch (tryFlag) {
                  case 0:
                    console.log("use UpperCase md5");
                    file.md5 = file.md5.toUpperCase();
                    break;

                  case 1:
                    console.log("use LowerCase md5");
                    file.md5 = file.md5.toLowerCase();
                    break;

                  case 2:
                    console.log("use randomCase md5");
                    file.md5 = randomStringTransform(file.md5);
                    break;

                  case 3:
                    console.log("use saveFile v2");
                    file.md5 = file.md5.toLowerCase();
                    this.saveFileV2(i);
                    return;

                  default:
                    this.saveFile(i + 1, 0);
                    return;
                }

[mengzonefire]

使用常规接口(saveFile)转存时, md5参数的大小写会影响转存结果, 仅全大写/全小写/混合大小写才能转存的文件均存在, 非常规接口(saveFileV2)则没有这个问题, 百度服务端那边具体是什么毛病未知.

仅混合大小写可转存的文件样本(全大写/全小写均返回{errno: 404}): 4144bcfb491344f9ba58e1047fc80433#7ab86bc540bd643b795960450e8a57a3#185822989#test

仅全大写/全小写的文件样本未保留, 就不提供了

[void285]

多谢解惑，测试发现确实如此，这个样本要三次请求才成功，百度这个问题很诡异。 另外，我测试的一批160来个样本中，有10个都是全大写失败后，全小写成功。不知全大写失败、全小写失败的概率是否有参考数据？

[mengzonefire]

多谢解惑，测试发现确实如此，这个样本要三次请求才成功，百度这个问题很诡异。 另外，我测试的一批160来个样本中，有10个都是全大写失败后，全小写成功。不知全大写失败、全小写失败的概率是否有参考数据？

不知道也不在乎这个问题, saveFileV2接口可用的情况下完全推荐使用该接口, 不会受大小写影响, 甚至可转存某些常规接口完全无法转存的文件, 再甚至, 我测试过删除云端唯一源文件, 常规接口转存立即失效, 而saveFileV2依旧有效

[void285]

关于概率的问题纯属好奇，的确没啥意义。saveFileV2很省事，sliceMD5都不需要。

可惜文件列表获取请求拿到的MD5经常有问题，有些还是9位[a-f0-9]+[g-z]+22位[a-f0-9]的错误格式的MD5，不然获取秒传链接只需要请求文件列表就可以了。

就上句中表述的意见，再请教两个问题： 1、来自列表请求的9位[a-f0-9]+[g-z]+22位[a-f0-9]的格式的MD5，算是bug吗，还是一种设计？ 2、另外有些文件从列表请求中拿到的MD5（格式没问题）与妙传链接中拿到的不一样，实际上秒传链接的才是真实MD5，那么请求中获取到错误的MD5也是一种bug吗？

[mengzonefire]

包含[g-z]的字符串不符合md5格式, 所以根本就不是md5, 猜测是由于使用分片上传, 上传完成时, 服务端未来得及计算完整文件md5, 就直接使用自定义算法对block_list运算生成了那串含[g-z]的假md5临时使用. 所以meta接口返回的md5参数是完全不可信的, 就算不包含[g-z]也有可能是假的, 仅block_list参数内的md5可信

[void285]

所以meta接口返回的md5参数是完全不可信的, 就算不包含[g-z]也有可能是假的

对，我找了一个包含几千文件的文件夹验证过，有些meta中的md5字段是[a-f0-9]{9}[g-z][a-f0-9]{22}，即伪md5，有些meta中的md5字段是[a-f0-9]{32}，但与秒传生成的Content-MD5不同，大部分（约六七成）文件meta中md5字段与秒传生成的Content-MD5相同。

仅block_list参数内的md5可信

这个字段之前没太注意，获取文件列表的响应中不包含此字段，好像只有分享相关的请求中有。我分享了几个文件看了下，有些block_list与md5相同，有些不同，不过不论文件大小，block_list.length都=1