2009年5月2日
谷歌推出了酝酿良久的音乐搜索，业界十分关注，报道不断，评论也很多。这件事也已经过去了一段时间了，今天想起来再提，想谈谈它们的区别。
百度MP3和谷歌音乐搜索的本质区别不在于盗版盗版的问题，所谓的盗版不过是利益的分配不均而已；只是一个“名份”，得一个名正言顺罢了。百度和谷歌的真正区别在于“搜索”二字，在我看来（至少是现在的）谷歌音乐不能称为搜索，顶多算是一个“音乐频道”，因为其音乐的资源全部来自于巨鲸音乐网。而搜索引擎的任务是：对全网络资源进行整合，为用户提取有用信息。谷歌音乐只是限定于一个巨鲸网络，完全没有搜索的概念，既然如此，谷歌音乐搜索和直接在巨鲸音乐网找音乐有何区别？而百度音乐搜索则是面向全网的音乐搜索，任何网站的音乐资源都可以被收录，虽然这种方式被各大唱片公司深恶痛绝，但是这不是“音乐搜索”讨论的范畴。
归根结底，搜索只是整合内容，而不是提供内容，从某种角度来说，搜索引擎对这个网络的信息量增长没有直接作用；同时，产生信息也不是搜索引擎的任务。如果说，正版化阻碍了谷歌音乐的脚步，那么我们不应该在此停住，不应因为这个原因而放弃了对整网络资源的整合。其实更好的办法是不计较局部的“盗版”，而从整体上调整音乐搜索的利益分配问题，这样于用户、于音乐提供商、于搜索引擎都是好事，毕竟在这件事上，三者是相互作用的，缺一不可，只要处理的得当，所有人的利益都可以最大化。
原文：
百度MP3与谷歌音乐搜索的本质区别
最近在做一个网站定时生成页面的功能，其中出现了一个问题是生成页文件名重名的问题。刚开始，我通过时间来命名，就是说什么时间生成，它的名字就是那一刻的时间，而且精确到了毫秒级，通常这样做已经足够了，不会出现差错，但是很不幸，我发现页面生成的效率要远比我想象的要高，我测试了一下，20个页面竟然可以在一毫秒内生成，这样就导致了后来的页面覆盖掉前面的，最后只剩下最后一个页面而已了。
有一种解决办法就是判断重名，如果文件名已经存在，那么就换一个名字，但是，这样每次都要判断。更要紧的是，随着时间的推移，现有的页面必然越来越多，每次生成都要遍历一下目录，岂不是很麻烦？虽然可能有比较好的搜索算法来提高效率，但是我想还不如从根本上解决这个问题更好。
这样就是产生了使用GUID的想法，GUID的全拼是globally unique identifier，即全球唯一标识符。GUID是微软使用的一个术语，通过特定的算法，给某一个实体创建一个唯一的标识，此标识符可以保证全球唯一。
一个 GUID 共128位长（16字节），形如 xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx。其中每个 x 是 0-9 或 a-f 范围内的一个十六进制的数字，前4个字节为随机数；5-8字节为时间戳，记录了该GUID的生成时间（低16位字在前，以分钟为单位），保证了时间上的唯一；9-10字节与机器重启次数有关；最后6字节一般为该机器的网卡地址（如果这台机器没有网卡，则使用另一常数），从而保证了空间上的唯一。因此几乎不可能生成两个相同的GUID，从而保证了名字的唯一性。
GUID 在 .NET 中的使用很广泛，同时.NET Framework 提供了专门 Guid 类，用户可以很容易的产生GUID。比如在asp.net中就可以想这样产生一个GUID：System.GUID.NewGUID()。基于这样的原理，我就可以使用这个类为我生成的文件命名了，从根本上解决了重名的问题。不仅如此，这个方法还可以应用到上传文件的命名上。
进一步了解，发现GUID使用很广泛，其实我们平时也经常看到。如注册表、类及接口标识、数据库、以及自动生成的机器名、目录名等。你可以打开你的系统盘下\WINDOWS\Installer目录，可以看到很多类似{0EFDF2F9-836D-4EB7-A32D-038BD3F1FB2A}的文件夹，这就是系统自动生成的目录名。注册表中也可以发现这样的数字串，以前也不知道是什么，现在明白了，都是系统为了避免重名生成的GUID。
更多详细参考：http://blog.mm-share.cn/post/139.html
