我在百度云盘上传了几部X片（你懂的），我不会公开只是自己看，这会被查水表不？懂关于网络信息法之类的大神来解答一下，或者有被查水表经历的也可以来说一下。
我在百度云盘上传了几部X片（你懂的），我不会公开只是自己看，这会被查水表不？懂关于网络信息法之类的大神来解答一下，或者有被查水表经历的也可以来说一下。
想看吗.我给你个.在百度上复制上（cszebt）点第一个直接不用播放器直接云点播.1000多个x片供你欣赏.兄弟懂得把.
额，兄弟你没看清我问题吧，我不缺X片，是说把X片上传到百度云盘保存会不会被查水表，。，
估计你的问题已经沉了.沉了 沉了...
提问者 的感言：没人回答就把分给你好了。。。。。。 相关知识略懂社热议
相关知识略懂社热议等待您来回答
通信网络领域专家
& &SOGOU - 京ICP证050897号百度云盘资源搜索你懂的_百度网盘搜索引擎搜索种子_90网盘
已收录6015244位分享达人
个分享文件帐号:密码:下次自动登录{url:/nForum/slist.json?uid=guest&root=list-section}{url:/nForum/nlist.json?uid=guest&root=list-section}
贴数:15&分页:startx发信人: startx (startx), 信区: NewSoftware
标&&题: 搞不懂百度云上传个大文件为什么要“读取”这么久
发信站: 水木社区 (Thu Apr 10 12:16:50 2014), 站内 && 比如一个20G的文件，它貌似要一直读，读完了以后，和什么特征值比较，确定是不是已
经被人上传过了，如果是的话，就直接极速秒传，不是的话，真正上传。 && 这本身没什么。 && 关键是，难道不能用用优选法什么的么？选取一定偏移量的某些文件段计算特征值，和
它的特征值库进行对比，没有的话，肯定说明文件没有被上传过，就直接上传不就行了
？如果有相同的，再把余下的都hash完了，确定是不是真的上传过。 && 现在上传一个大文件慢死，看那意思，貌似是把整个文件都给hash了，然后再确定是不
是上传。 &&&&&&&& -- && ※ 来源:·水木社区 newsmth.net·[FROM: 124.205.76.*]
cyy发信人: cyy98 (cyy), 信区: NewSoftware
标&&题: Re: 搞不懂百度云上传个大文件为什么要“读取”这么久
发信站: 水木社区 (Thu Apr 10 15:09:15 2014), 站内 && 我觉得吧，如果用偏移量计算，可能会产生冲突的，就是正好一样吧。
我也很讨厌这样，慢死了，读一个大文件
孤单的手，紧抱着你的腰，象昨日正相爱的时候，你说今天以后，不必再见也不必问候，
曾经拥有，不要泪流。温馨的手，终放下我的手，默默合上双眼忍受，你已轻轻吻别，
心中只想这一刻停留，曾经拥有，不管多久。若果真心不可接受，或者不方便拥有，
为何又等今天最后， 乘早一点分手，若果是你真的贪心厌旧，伪装悲苦梦湿透，
为何你想讲的情话，藏于落寞眼光背后。依依不舍的看着你走，木立在最失意的时候，
一声今天以后，不讲再见也不肯回头，曾经拥有，不要泪流。
&&&& ※ 来源:·水木社区 ·[FROM: 222.92.189.*]
startx发信人: startx (startx), 信区: NewSoftware
标&&题: Re: 搞不懂百度云上传个大文件为什么要“读取”这么久
发信站: 水木社区 (Thu Apr 10 15:19:15 2014), 站内 &&&& 我想你没看懂我的意思，这不管冲突的事儿吧，这只不过是一种检验策略，而且是很靠
谱的策略。 && 就像给你任意两个数字序列让你比较它们是不是相同。 && 假如你的策略是，必须从头到尾每个数字全部比较过来，再给出答案，这效率就太低了
。 && 如果你的策略是，无论给我什么序列，我首先去截取每个序列的第五到第八个数字，看
看这两个是不是一样。一样的话，我再把其他的部分比较完，如果不一样，剩下的根本
就不需要比较了，就知道两个序列不一样啊。 && 如果序列只有一百个数字组成，可能都无所谓策略；可是如果序列是一万亿个数字组成
的呢？明明就是两个不同的序列，你一定要从第一个数字比较到最后一个数字？那对不
起，你可能要人工比较两年，我只需要三秒钟。 &&&&&& 【 在 cyy98 (cyy) 的大作中提到: 】
: 我觉得吧，如果用偏移量计算，可能会产生冲突的，就是正好一样吧。
: 我也很讨厌这样，慢死了，读一个大文件
&&&& -- && ※ 来源:·水木社区 newsmth.net·[FROM: 124.205.76.*]
ae175b1bf388发信人: ae175b1bf388 (ae175b1bf388), 信区: NewSoftware
标&&题: Re: 搞不懂百度云上传个大文件为什么要“读取”这么久
发信站: 水木社区 (Thu Apr 10 15:33:03 2014), 站内 && 整个文件hash, 百度假设不会冲突, 这种索引好维护
前N字节hash, 可能很多不同文件大小相同,前N字节也相同,索引代价太大,
而且读一遍的时间相对于上传时间,占用时间应该可以忽略
【 在 startx (startx) 的大作中提到: 】
: 比如一个20G的文件，它貌似要一直读，读完了以后，和什么特征值比较，确定是不是已
: 经被人上传过了，如果是的话，就直接极速秒传，不是的话，真正上传。
: 这本身没什么。
: ...................
&& -- && ※ 来源:·水木社区 newsmth.net·[FROM: 124.127.61.*]
startx发信人: startx (startx), 信区: NewSoftware
标&&题: Re: 搞不懂百度云上传个大文件为什么要“读取”这么久
发信站: 水木社区 (Thu Apr 10 15:49:35 2014), 站内 &&&& 用若干个文件片段的hash值，以较小的代价来高效确定“未上传过”的文件，从而最短
时间开始上传这些文件，这个开销还是值得的。 && 另外，到底检测哪些文件段，检测多少文件段，每段的长度多少，可以最大限度更容易
确定文件是否已在服务器上存在，肯定是可以有数学模型来指导的。而上来全盘开始ha
sh，我从直觉上讲，认为这肯定不是最合适的。 &&&& 另外，为啥hash大文件时间这么长？按说hash的过程都应该是在本地完成的，同样大小
的文件，我用软件计算sha1sum的值，也没这么久啊..... &&&& 【 在 ae175b1bf388 (ae175b1bf388) 的大作中提到: 】
: 整个文件hash, 百度假设不会冲突, 这种索引好维护
: 前N字节hash, 可能很多不同文件大小相同,前N字节也相同,索引代价太大,
: 而且读一遍的时间相对于上传时间,占用时间应该可以忽略
: ...................
&& -- && ※ 来源:·水木社区 newsmth.net·[FROM: 124.205.76.*]
肥了，又肥了 &&&_&&&发信人: milksea (肥了，又肥了 &&&_&&&), 信区: NewSoftware
标&&题: Re: 搞不懂百度云上传个大文件为什么要“读取”这么久
发信站: 水木社区 (Thu Apr 10 16:27:57 2014), 站内 && 硬盘读一个大文件就挺费时的。如果实现得好 hash 时间基本上就是 IO 时间。
【 在 startx (startx) 的大作中提到: 】
: 用若干个文件片段的hash值，以较小的代价来高效确定“未上传过”的文件，从而最短
: 时间开始上传这些文件，这个开销还是值得的。
: 另外，到底检测哪些文件段，检测多少文件段，每段的长度多少，可以最大限度更容易
: ...................
世界上有 10 种人：懂 10 进制的和不懂 10 进制的。 &&&& ※ 来源:·水木社区 newsmth.net·[FROM: 124.205.77.*]
泥人发信人: cosix (泥人), 信区: NewSoftware
标&&题: Re: 搞不懂百度云上传个大文件为什么要“读取”这么久
发信站: 水木社区 (Fri Apr 11 11:41:22 2014), 站内 && 从程序设计角度来说，你的设想虽然好，但是工作量多很多，会有很多额外的处理。 && 再从实际角度来看，上传大于2G文件的人多不多？每天上传大于2G文件的次数多不多？
你也就是20G的文件更、极端了点，如果低于4G，全文件hash都用不了多少时间。 && 很多软件都可以做得更好，只要投入更多的成本，问题是这个功能可能只有少数的人会
去用，80%的人用20%的功能你应该听过吧，这个值不值得就看公司怎么去谋划了。 &&&&&&&& 【 在 startx (startx) 的大作中提到: 】
: 我想你没看懂我的意思，这不管冲突的事儿吧，这只不过是一种检验策略，而且是很靠
: 谱的策略。
: 就像给你任意两个数字序列让你比较它们是不是相同。
: ...................
&& -- && ※ 来源:·水木社区 newsmth.net·[FROM: 221.5.5.*]
肥了，又肥了 &&&_&&&发信人: milksea (肥了，又肥了 &&&_&&&), 信区: NewSoftware
标&&题: Re: 搞不懂百度云上传个大文件为什么要“读取”这么久
发信站: 水木社区 (Fri Apr 11 11:48:41 2014), 站内 && 实际上竞争对手（比如迅雷）在这点上确实更好，这个差异造成用户体验不同，积累起来就不好了。何况大家都清楚，这实在不算是什么大的改动。
【 在 cosix (泥人) 的大作中提到: 】
: 从程序设计角度来说，你的设想虽然好，但是工作量多很多，会有很多额外的处理。
: 再从实际角度来看，上传大于2G文件的人多不多？每天上传大于2G文件的次数多不多？
: 你也就是20G的文件更、极端了点，如果低于4G，全文件hash都用不了多少时间。
: ...................
世界上有 10 种人：懂 10 进制的和不懂 10 进制的。 &&&& ※ 来源:·水木社区 newsmth.net·[FROM: 124.205.77.*]
泥人发信人: cosix (泥人), 信区: NewSoftware
标&&题: Re: 搞不懂百度云上传个大文件为什么要“读取”这么久
发信站: 水木社区 (Fri Apr 11 15:32:34 2014), 站内 && 那看别的竞争对手连离线下载都还只支持http呢。 && 其实就是看项目经理觉得有没有必要投入，不算大的改动也是改动，代码越少不就意味
着问题越少，越稳定么。 &&&&&& 【 在 milksea (肥了，又肥了 &&&_&&&) 的大作中提到: 】
: 实际上竞争对手（比如迅雷）在这点上确实更好，这个差异造成用户体验不同，积累起来就不好了。何况大家都清楚，这实在不算是什么大的改动。
&&&& -- && ※ 来源:·水木社区 newsmth.net·[FROM: 221.5.5.*]
发信人: jcz (AYAYA), 信区: NewSoftware
标&&题: Re: 搞不懂百度云上传个大文件为什么要“读取”这么久
发信站: 水木社区 (Fri Apr 11 23:38:26 2014), 站内 && 楼主思路很赞。 && 总结起来就是，在云端不存在待上传文件的情况下，这个方案需只需要花“很短”的时间就发现这个结论。相对于大文件来说，计算完整的HASH的时间要长的多。所以，这个用户体验提升是明显的。 && 而在云端存在待上传文件的情况下，这个“很短”的时间是额外的。但，由于“很短”，所以用户几乎没有察觉。所以，对用户体验牺牲比较小。 && 1）这个很短，最多应该在1至最多3秒钟以内；
2）只在传大文件时候启用；
3）而“部分HASH”的算法要好好设计，考验技术能力。最终效果好不好，还是要看这个“部分HASH”的代表性够不够强，适不适合大多数文件。 &&&& 如果我是产品经理，一定会采纳的。 && -- && ※ 来源:·水木社区 ·[FROM: 159.226.78.*]
文章数:15&分页:
抽奖到手软！将狂欢进行到底！明星达人都在玩