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

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：不知道淘宝网的思路是不是这样

 

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

评论

40 楼 gembler 2008-12-04  

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

39 楼 gembler 2008-12-04  

sdh5724 写道

这点计算， 跟性能无关， 实际上这个URL增加了处理URL的时间。

跟性能无关也对，从淘宝网上可以看出，以淘宝商城为例：

搜索：gembler

是先post到 - http://list.mall.taobao.com/search_dispatcher.htm

然后分发到 - http://list.mall.taobao.com/search_product.htm?type=p&sort=st&style=g&at_topsearch=1&user_action=initiative&q=gembler

再解析为 - http://list.mall.taobao.com/0/g-st----g,m5sw2ytmmvza-40-0--0.htm - 并redirect。

最后才response

但是这个过程一般是感觉不到

38 楼 sdh5724 2008-12-04  

air82 写道

我觉得，首先，为什么不用普通的参数，我想是这样，淘宝的服务器压力很大，对应用的性能要求应该很苛刻，搜索的时候你看起来你输入只是一个关键字，实际上远远不止，有几十个参数，如果用一组事先约定好位置的数据来表示各种参数，服务器不用解析那么多的字符串，不用处理那么多的参数名=参数，虽然开发维护起来会增加一些工作量，但是服务器压力会小一些，流量会小一些。
至于编码方式，回应楼上某位同学的话，base64编码不是淘宝自己搞出来的，是email刚出现时特殊历史时期的产物，具体的可以google一下，base64编码后数据量比urlencode少60％左右 

这点计算， 跟性能无关， 实际上这个URL增加了处理URL的时间。

37 楼 sdh5724 2008-12-04  

   跟效率没有关系， 还有URL的并不能变短， BASE64编码好处是字符编码范围有限度。这么做完全让复杂的URL看上去好看点， 方便SEO。 其他的没有什么问题。 另外一个是隐藏URL的具体参数的含义。 这个需要有个强大的正则表达规则来解析URL， 开发的时候，还是URL？PARAM＝XX的形式。 这个问题没有好追究的， 一个简易的URL人们总是比较喜欢而已。
  另外， 还有一个开发经验的问题， URL实际上大小写， 在EMAIL中发送， 都存在各种问题， 完全使用ASCII也可以避免汉字编码问题。 反正这个URL都通过一个专用URL生成的工具完成的。 URL的处理经验是通过血的教训得到的， 那些RFC推荐的规范未必适合做应用。
  不是说这个方法是完美的， 可是能解决很多问题。 网站的性能不是在文本处理上， 目前的CPU的计算能力已经超过很多开发人员的想象了。
  对了， 我不是TAOBAO的， 别PM问我了。。。。

36 楼 caiceclb 2008-12-04  

全部看完还是一塌糊涂。。。也算是知道几点：1、有利于缩短url；2、是不是也能屏蔽掉有害字符？！3、为啥不用post？都post了，搜索引擎就不收录了。

35 楼 yangyi 2008-12-04  

yangyi 写道

6位都已经是无奈之举了，还要用5位，那不是对现有资源的浪费吗，在不增加url长度的情况下充分提高效率，6位编码是最佳的。如果可以任意的饿牺牲url长度，可以把0-9全部拿出来当做标记位，0-9不会单独出现，这样一共有10*26 + 26 = 286 种可能还不包括小写字母，此外还有=，+，-什么的至少256可以编码8位的字节了，这样处理效率就提高了

我是完善的这个帖子

34 楼 gembler 2008-12-04  

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%

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

33 楼 Unmi 2008-12-04  

这个贴子要收藏，很好，以后一定能用得上的。
楼主太强了。

32 楼 yangyi 2008-12-04  

现在把问题优化一下，人类可读无歧义的文本码有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%

31 楼 airport 2008-12-04  

还有一个就是对于Cache和CDN来说统一的URL是容易管理的。

30 楼 airport 2008-12-04  

我来给大家剖析一下吧，淘宝的原来一帮人是从阿里出来的。而阿里最强悍的就是SEO。

这样大家是否有点清楚了。

SEO对URL还是非常的看重的，而url中如果包含太多中文等字符的话，对SEO还是不友好。

那么搞一个英文加字符的编码对机器来说还是比较容易好搞的。

至于非要自己搞一个，那其实这也不是什么特别难的东东，增加一些神秘感不是更好。

29 楼 air82 2008-12-04  

楼上有几位提出了url中/和=以及空格这种问题，不写了，引用一段搜索来的：

　　然而，标准的Base64并不适合直接放在URL里传输，因为URL编码器会把标准Base64中的“/”和“+”字符变为形如“%XX”的形式，而这些“%”号在存入数据库时还需要再进行转换，因为ANSI SQL中已将“%”号用作通配符。
　　为解决此问题，可采用一种用于URL的改进Base64编码，它不在末尾填充'='号，并将标准Base64中的“+”和“/”分别改成了“*”和“-”，这样就免去了在URL编解码和数据库存储时所要作的转换，避免了编码信息长度在此过程中的增加，并统一了数据库、表单等处对象标识符的格式。

28 楼 sagah 2008-12-04  

LZ确实很厉害。我觉得TB好像习惯对URL进行BASE64。URL有保密信息的话会再来个BF加密。使用BASE64怕非英文的URL解码后会产生服务器操作的命令。BASE64的编码快，解码也快。

27 楼 yangyi 2008-12-04  

6位都已经是无奈之举了，还要用5位，那不是对现有资源的浪费吗，在不增加url长度的情况下充分提高效率，6位编码是最佳的。如果可以任意的饿牺牲url长度，可以把0-9全部拿出来当做标记位，0-9不会单独出现，这样一共有10*26 + 26 = 286 种可能还不包括小写字母，此外还有=，+，-什么的至少256可以编码8位的字节了，这样处理效率就提高了

26 楼 air82 2008-12-04  

我觉得，首先，为什么不用普通的参数，我想是这样，淘宝的服务器压力很大，对应用的性能要求应该很苛刻，搜索的时候你看起来你输入只是一个关键字，实际上远远不止，有几十个参数，如果用一组事先约定好位置的数据来表示各种参数，服务器不用解析那么多的字符串，不用处理那么多的参数名=参数，虽然开发维护起来会增加一些工作量，但是服务器压力会小一些，流量会小一些。
至于编码方式，回应楼上某位同学的话，base64编码不是淘宝自己搞出来的，是email刚出现时特殊历史时期的产物，具体的可以google一下，base64编码后数据量比urlencode少60％左右 

25 楼 useless 2008-12-04  

-_-# 研究型人才啊,

24 楼 8000 2008-12-04  

敬仰如滔滔江水，你干脆把他们的URl加密规则都研究出来，搞清楚他们的服务器上各种资源存放的规律，搞不好有点意外收获呢。

宁外，小马哥说不定给你打电话，哈哈哈

23 楼 8000 2008-12-04  

TAOBAO的工程师今天估计要开始加班讨论他们各个环节的安全方案是否有问题了，真是好强啊，楼主你。

22 楼 reeze 2008-12-04  

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

21 楼 davidgrubby 2008-12-04  

楼主有意思的。。。强汗