淘宝网的搜索关键字的编码与解码

lichd 写道

刚刚看到你对淘宝编码的研究,我个人认为淘宝那个编码可能是Base32规范的演化版,只不过淘宝使用0来代替=做末位填充,RFC 3548 (The Base16, Base32, and Base64 Data Encodings)
对这些都有规范

经过证实，lichd 的观点正确，由于我在本文发表之前，除Base64 之外，其他的BaseXX 都没接触过，所以不知道这个正是Base32 的效果。

 

不过看官们请放心，本文的思路也和Base32 符合。当时的乱打乱撞，结果造了一个古人已经造好的轮子，实在惭愧。

 

因此，感谢lichd 的观点，从而稀释了我体内SB细胞的浓度。

 

回头看了一下本文的一个旧实现（codec.zip ），一年前写得代码太糟糕了，不推荐。

现在提供一个相对不错的实现，>>猛击获取<< 。

 

-------------------------- -------------------------- -------------------- ---------------------

------------------------------------------分割线 --------------------------------------------

-------------------------- -------------------------- -------------------- ---------------------

 

 

很久之前发现淘宝网的搜索关键字在编码后有点可爱，小写英文字母+数字的组合。

想去研究一下，但是后面好像没了回事似的。。记性不好

然后这两天不知道为什么，突然间抽起条脑筋，跑去研究。。。。

 

--------------------------开始分割线--------------------------

 

在淘宝网上用关键字“gembler”搜索一下商品，得出以下URL：

 

http://search1.taobao.com/browse/0/n-0-----------------g,m5sw2ytmmvza----------------40--commend-0-all-0.htm?at_topsearch=1

                                                                                           （留意上面这里：“m5sw2ytmmvza” ）

 

经过一轮 天昏地暗、沙尘滚滚 的分析、研究之后，得出以下结论：

 

  在Base64中，码表是由 [A-Z,a-z,0-9,+,/,=(pad)] 组成的。
  然后自己也弄个码表，由 [a-z,2-7（这个2-7是在 淘宝网上搜索了n次而得出的结论） ] 组成的：

 

a	b	c	d	e	f	g	h	i	j	k	l	m	n	o	p	q	r
0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17

 

-------------------------------愚蠢分割线---------------------------------

 

s	t	u	v	w	x	y	z	2	3	4	5	6	7
18	19	20	21	22	23	24	25	26	27	28	29	30	31

 
  在Base64中，是将二进制连成一串，然后再按6位来分割，分割完后在前面补0，这个地球人都知道，不多说了。
  而我呢，哈哈，捣蛋一下，按5位来分割，如果刚好够分，那就爽了，

  但是，世事往往不如人意，位数不够，那咋办呢？看下面 ：）
 
  在Base64中，是用"="来解决的吧。
  现在呢，就是在前面补0，然后在后面再补0，其实就是前后补0，

  但是， 按5位来分 割 ，前面3个0是补定的了，后面的0就看上帝怎么安排了。
 
  举个小例子：字符串 "aaa"，(编码/加密)后是 "mfqwc"
 

二进制：	01100001	01100001	01100001
转换后：	(000 )01100	(000 )00101	(000 )10000	(000 )10110	(000 )0001(0 )
十进制：	12	5	16	22	2
码表对应：	m	f	q	w	c

 
  反过来，(解码/解密)：
 

码表对应：	m	f	q	w	c
十进制：	12	5	16	22	2
二进制：	00001100	00000101	00010000	00010110	00000010
去掉前3个0后：	01100	00101	10000	10110	00010
合并后：	0110000101100001011000010

 
  然后把合并后的串的长度除一下8，发现多了个0：
 

合并后的 二进制码：

01100001

01100001

01100001

0

  多了就算了，不要了（其实是在{编码/加密}的分割时候，在分剩的余数的后面补的0）。
  然后再将 byte[] 转回字符串

 

  OK！又见回"aaa"了。    ：）
 
  *有一点值得注意的是：UTF-8、GBK、GB18030 一般都没什么问题，但是 GB2312 可能字符集不够丰富，繁体字在decode的时候成问号了。

 

搞了半天，“可视化编辑器”的 Java Code不好使，骨干代码在回帖里贴出................（完整的代码，有兴趣的同志们请见附件！ ）

 

--------------------------结束分割线--------------------------

 

。。。整理好了，整个人都铺满了灰尘.......

 

PS：不知道淘宝网的思路是不是这样

 

（补：另外一篇讨论 - “ 拍拍网的搜索关键字的编码与解码 ”）

评论

60 楼 libra 2008-12-05  

应该和seo无关，和性能有关吧！
为了性能，taobao,paipai应该有很多服务器处理用户的搜索请求
如taobao先将搜索请求提交到相应的页面(http://search1.taobao.com/browse/search_auction.htm?at_topsearch=1)，然后处理页面解析数据并组成相应的URL，再根据当前查询机器的负载情况redirect相应的机器？

59 楼 gembler 2008-12-05  

sdh5724 写道

ＵＲＬ的选择编码方式是有血的教训的。

sdh5724 写道

跟大家说点故事
   如果你的URL放在邮件里， 很多MAIL SERVER会修改的你的URL ，比如修改你的大小写， 修改你的编码， 这个很常见的情形。那么这个时候， 用户会非常的讨厌。 一些特殊的字符可能导致， MAIL SERVER在安全处理上， 把URL硬生生的拆散了。另外， 为了保持和不同的HTTP SERVER兼容， 不让HTTP SERVER按编码规则修改你的URL。 使用ASCII是最好的选择。 做个网站， 要考虑的细节很多， URL是一个非常重要的东西， 虽然不是技术上的难度， 但是需要细节上的实现。 URL生成工具是非常重要的东西， 甚至某种程度上，到了比较BT的程度， 特定的URL形式甚至有时候是营运的需要。

这个故事（可以在哄孩子睡觉的时候用的上）告诉大家，要珍惜生命
sdh5724也是用心良苦啊

58 楼 hama 2008-12-05  

终于解了我的千年疑惑！谢谢哦！

57 楼 sdh5724 2008-12-05  

crazy.j 写道

xiaoyu 写道

为什么google不用呢？

人家不已经说了么
一种是urlencode(url, enc)
一种是自己写程序编码
目的是一个！
GET访问的前提下，保证服务器接到的URL编码是一致的。
至于你想用urlencode也好或者自己编个火星码也好，个人爱好问题！

血的教训指得也就是，URL里别出现不该出现的东西～！

跟大家说点故事
   如果你的URL放在邮件里， 很多MAIL SERVER会修改的你的URL ，比如修改你的大小写， 修改你的编码， 这个很常见的情形。那么这个时候， 用户会非常的讨厌。 一些特殊的字符可能导致， MAIL SERVER在安全处理上， 把URL硬生生的拆散了。另外， 为了保持和不同的HTTP SERVER兼容， 不让HTTP SERVER按编码规则修改你的URL。 使用ASCII是最好的选择。 做个网站， 要考虑的细节很多， URL是一个非常重要的东西， 虽然不是技术上的难度， 但是需要细节上的实现。 URL生成工具是非常重要的东西， 甚至某种程度上，到了比较BT的程度， 特定的URL形式甚至有时候是营运的需要。

再次声明， 我不是TAOABO的。 我只是知道这些细节而已。

56 楼 crazy.j 2008-12-05  

xiaoyu 写道

为什么google不用呢？

人家不已经说了么
一种是urlencode(url, enc)
一种是自己写程序编码
目的是一个！
GET访问的前提下，保证服务器接到的URL编码是一致的。
至于你想用urlencode也好或者自己编个火星码也好，个人爱好问题！

血的教训指得也就是，URL里别出现不该出现的东西～！

55 楼 xiaoyu 2008-12-04  

为什么google不用呢？

54 楼 sdh5724 2008-12-04  

楼上对技术上是正解，完全正确。　我刚才回复的时候，　居然没有人理会。　　ＵＲＬ的选择编码方式是有血的教训的。

53 楼 dogstar 2008-12-04  

http://domain/中文.html?q=中文.

1.第一个中文为pathinfo
2.第二个是queryString

这个url在get请求,也就是说直接拷贝到浏览器上敲回车执行的时候动作如下:
浏览器会对这个url中的分ascii字符集进行url encode.
中文ie:pathinfo 会用utf-8字符集进行url encode.queryString 会用gbk
中文firefoxpathinfo 会用gbk字符集进行url encode.queryString 会用gbk:

http://search1.taobao.com/browse/0/n-0-----------------g,m5sw2ytmmvza----------------40--commend-0-all-0.htm?at_topsearch=1 

n-0-----------------g,m5sw2ytmmvza----------------40--commend-0-all-0.htm
这段是pathinfo.也就是单单中文ie,和中文firefox 进行url encode时,采用的字符集都不一致.一种是utf-8,一种是gbk.那么传到后台程序如何decode呢?


怎么做?做法就是程序把pathinfo用一定的方式转换成ascii码,这样浏览器就不自己来做了.做法有很多.下面举两种:

一种,使用urlEncode(stirng,编码格式).因为这个编码格式是自己制定的.所以后台知道如何decode.
一种:base64.甚至是base32.其实道理都是一样的.把pathinfo用程序转换成ascii码.不让浏览器自己瞎转.


大体如上.这块我遇到过.blog中也有一些整理.可以自行查看.

52 楼 8000 2008-12-04  

sdh5724 写道

gembler 写道

它这样跳法，加上每天这么大的访问量，速度同样这么好，可想背后的庞大架构。。。

 

谁说URL解释就要跳转的， 中间加上一个URL解释层， 就不需要跳转的， 这个在WEBX框架层次解决的。

你是淘宝的吧，小子。

51 楼 reeze 2008-12-04  

gembler 写道

sdh5724 写道

几乎是为了seo.

看来，淘宝网为什么要这么做，已经有答案了。

跟SEO没有关系吧。
这样根本就不SEO。

50 楼 lazy 2008-12-04  

http://search1.taobao.com/browse/0/n-g,zhm3z65w4c45nnoez3fnfo564sr3vtguwgtm5kwkwlb3juvkw3khk4tmxx4nbuccmfzwknruwhqmf25quhe5tph3w3qltvvvythmvuv3x3skhowm2sy2ntvkzkzmhngsvk3ni5lsns67rugqijqxgzjwgsy6bqxlwcq4twn47o3oboowwxcm5swsxo7oji52ztkldjwovlflfq5u2kvlnvdvojwl36gq2bbgc43fgy2ldygc5oykdsozxt53nyfz2224jtwk2k535zfdxlgnjmngz2vmvmwdwtjkvnwuovzgzppyzhm3z65w4c45nnoez3fnfo564sr3vtguwgtm5kwkwlb3juvkw3khk4tmxx4nbuccmfzwknruwhqmf25quhinaqtbonstmnfr4dboxmfb----------------40--commend-0-all-0.htm?at_topsearch=1

我搜索这样的url，长度超过500字节也是可以的

49 楼 gembler 2008-12-04  

sdh5724 写道

几乎是为了seo.

看来，淘宝网为什么要这么做，已经有答案了。

48 楼 sdh5724 2008-12-04  

我怎么觉得你象在做压缩学问啊。
这个URL跟编码效率没有任何关系。 也用不着这样的效率， 几乎是为了seo.

yangyi 写道

续前文...

这种5位的转换会产生更多多余的字节，6位的转码充分利用了现今的可读文本，可是5位却没有，因为5和8的最小公倍数是40，所以当每转换40位即5个字节的二进制数据需要8个字节来表示，这样就多产生3个字节，浪费的效率是3/5, 而6位转码浪费的效率是1/3。而且随着字节增多，转化效率也在下降。可见采用5位转码是一种既浪费空间，又浪费效率的解决方案。

gembler 写道

yangyi 写道

现在把问题优化一下，人类可读无歧义的文本码有0-9，A-Z,a-z共62个
设取出x个作为标志位则(62-x) * x + (62 - x) >= 256
解这个二元一次方程得到:
3.366<=X<=57.634
考虑到编码的文本长度，取x的最小值，即 4
最优解：
用0, 1, 2, 3做为标志位
4-9，A-Z, a-z参与编码并与标志位配合实现8位字节的文本化

这种编码的冗余度为80%

不好意思·没看懂，能详细点吗？

47 楼 yangyi 2008-12-04  

续前文...

这种5位的转换会产生更多多余的字节，6位的转码充分利用了现今的可读文本，可是5位却没有，因为5和8的最小公倍数是40，所以当每转换40位即5个字节的二进制数据需要8个字节来表示，这样就多产生3个字节，浪费的效率是3/5, 而6位转码浪费的效率是1/3。而且随着字节增多，转化效率也在下降。可见采用5位转码是一种既浪费空间，又浪费效率的解决方案。

gembler 写道

yangyi 写道

现在把问题优化一下，人类可读无歧义的文本码有0-9，A-Z,a-z共62个
设取出x个作为标志位则(62-x) * x + (62 - x) >= 256
解这个二元一次方程得到:
3.366<=X<=57.634
考虑到编码的文本长度，取x的最小值，即 4
最优解：
用0, 1, 2, 3做为标志位
4-9，A-Z, a-z参与编码并与标志位配合实现8位字节的文本化

这种编码的冗余度为80%

不好意思·没看懂，能详细点吗？

46 楼 gembler 2008-12-04  

reeze 写道

这样有什么意义呢。。
不过那一堆的------------是干嘛的。。不也很影响url的美观啊。
每次加密加密的不也浪费么。。
谁解释下这个到底什么意图呢。不就是一个搜索关键字。

他是把问号后面的参数都夹进去"-"里，其实都是rewrite rule，夹在里面的东西就非常丰富了，分页啊、类目啊、属性啊、显示方式啊等等等等好多东西。里面还有","，应该是参数太多，需要分块管理一下。（纯粹个人猜想）

45 楼 flyfan 2008-12-04  

很佩服楼主的研究精神，这样都研究出来了

44 楼 gembler 2008-12-04  

sdh5724 写道

gembler 写道

它这样跳法，加上每天这么大的访问量，速度同样这么好，可想背后的庞大架构。。。

 

谁说URL解释就要跳转的， 中间加上一个URL解释层， 就不需要跳转的， 这个在WEBX框架层次解决的。

看来你是淘宝网的吧，要不就是阿里的。

43 楼 sdh5724 2008-12-04  

gembler 写道

它这样跳法，加上每天这么大的访问量，速度同样这么好，可想背后的庞大架构。。。

 

谁说URL解释就要跳转的， 中间加上一个URL解释层， 就不需要跳转的， 这个在WEBX框架层次解决的。

42 楼 fins 2008-12-04  

我觉得还有一个原因:

避免直接通过URL 来调用淘宝的相关服务.

举个例子:  你要买搜索苹果.

通常需要进入搜索页面 进行搜索.
而搜索页面有大量的广告  图片 flash之类的.

如果这时候 你突然发现 使用  

引用

www.taobao.com/search?key=apple

也能够达到同样效果, 那么很有可能你就不会通过搜索页面去搜索了.
那些广告的价值就低了

===============

当然 这只是我个人分析 而且这个也许不是主要原因.

41 楼 raydian 2008-12-04  

不错，很佩服LZ的专研精神。