一、访问入口

http://wiki.open.qq.com/wiki/%E8%85%BE%E8%AE%AF%E5%BC%80%E6%94%BE%E5%B9%B3%E5%8F%B0%E7%AC%AC%E4%B8%89%E6%96%B9%E5%BA%94%E7%94%A8%E7%AD%BE%E5%90%8D%E5%8F%82%E6%95%B0sig%E7%9A%84%E8%AF%B4%E6%98%8E

Step 1. 构造源串

源串是由3部分内容用“&”拼接起来的： HTTP请求方式 & urlencode(uri) & urlencode(a=x&b=y&...)

源串构造步骤如下：

第1步：将请求的URI路径进行URL编码（URI不含host，URI示例：/v3/user/get_info）。
请开发者关注：URL编码注意事项，否则容易导致后面签名不能通过验证。

第2步：将除“sig”外的所有参数按key进行字典升序排列。 
注：除非OpenAPI文档中特别标注了某参数不参与签名，否则除sig外的所有参数都要参与签名。

第3步：将第2步中排序后的参数(key=value)用&拼接起来，并进行URL编码。
请开发者关注：URL编码注意事项，否则容易导致后面签名不能通过验证。

第4步：将HTTP请求方式（GET或者POST）以及第1步和第3步中的字符串用&拼接起来。
注：Java_SDK_V3.0.6仅支持POST方式，如果用GET可能导致一直计算sig不正确。

源串构造示例如下
（由于是通用说明，这里以/v3/user/get_info作为示例，且示例中的请求串不可直接复制访问）

Step 2. 构造密钥

得到密钥的方式：在应用的appkey末尾加上一个字节的“&”，即appkey&，例如：

Step 3. 生成签名值

1. 使用HMAC-SHA1签名算法，使用Step2中得到的密钥对Step1中得到的源串签名。 
（注：一般程序语言中会内置HMAC-SHA1加密算法的函数，例如PHP5.1.2之后的版本可直接调用hash_hmac函数。）

2. 然后将加密后的字符串经过Base64编码。 
（注：一般程序语言中会内置Base64编码函数，例如PHP中可直接调用 base64_encode() 函数。）

3. 得到的签名值结果如下：

常见错误排障

为什么总是返回“-5：signature verification failed”？

签名校验失败分为以下两种情况：
1. sig参数生成错误
有可能由下列原因引起：
（1）构造源串时注意URI不含host，如/v3/user/get_info，而不是http://113.108.20.23/v3/user/get_info；
（2）构造源串时，没有将key排序后，再将(key=value)用&拼接起来。
（3）构造密钥时，没有将appkey后加“&”。
（4）某些语言的URLEncode系统方法在进行URL编码时，并没有按照现行的URL编码规则进行。详见下文的：URL编码注意事项。

对于支付和营销类接口，除了以上问题外，还有一些特别容易出错的地方：
（1）支付和营销相关回调协议中规定参数值都为string型，开发商出于本地记账等目的，对接收到的某些参数值先转为数值型再转为string型，导致字符串部分被截断（例如：字符串“13.14”转为整形再转为string 就会变成13），从而导致签名出错。
如果要进行本地记账等逻辑，建议用另外的变量来保存数值，传参时必须用原始接收到的string型值。 
（2）支付和营销相关回调协议中，在进行签名生成时多加了一个步骤： 
在构造源串的第3步“将排序后的参数(key=value)用&拼接起来，并进行URL编码”之前，需对value先进行一次编码 （编码规则为：除了 0~9 a~z A~Z !*() 之外其他字符按其ASCII码的十六进制加%进行表示，例如“-”编码为“%2D”）。
（3）支付和营销接口中的goodmeta参数，必须是UTF8格式，参与签名前要进行Base64编码。
（4）支付和营销接口中的payitem参数，含有*号字符，在进行URL编码时要注意观察是否进行了编码。

2. sig参数生成正确，但是参数传输前没有进行URL编码。
所有参数传输时都要进行URL编码，包括sig。如果没有进行URL编码，则即使sig是正确的，但是校验sig时不能匹配。

建议的解决方案：
（1）开发者可以使用平台提供的签名验证工具来计算签名：http://open.qq.com/tools ， 通过工具吐出的签名生成过程，来排查具体是哪一步出了问题。
（2）如果您是PHP开发者，可以使用PHP SDK中的签名生成函数来生成签名，避免自己去进行复杂的签名生成逻辑的开发。

URL编码注意事项

注意事项：
1. 某些系统方法，例如.NET系统方法HttpUtility.UrlEncode会将‘=’编码成‘%3d’，而不是%3D，导致加密签名通不过验证，请开发者注意检查。

2.Java 1.3和早期版本中，调用java.net.URLEncoder下的方法进行URL编码时，某些特殊字符并不会被编码，例如星号(*)。
由于URL编码规则中规定了星号(*)必须编码，因此在请求字符串中含星号(*)的情况下如果使用了上述方法，会导致生成的签名不能通过验证。
例如调用v3/pay/buy_goods接口时， payitem参数值中一定会含有* ，在使用类java.net.URLEncoder下的方法进行编码后，需开发人员手动将星号字符“*”替换为“%2A”，否则将导致加密签名一直通不过验证，请开发者注意检查。

3. 某些语言的urlencode方法会把“空格”编码为“+”，实际上应该编码为“%2B”。这也将生成错误的签名，导致签名通不过验证。 
请开发者注意检查，手动将“+”替换为“%2B”。
在PHP中，推荐用rawurlencode方法进行URL编码。

二、鉴权方式分析

这里用的是签名算法！

开发者事先申请appId和appKey，访问时带上appId，使用appKey签名请求

服务端使用appId找到服务端的appKey，重新签名请求，进行比对。

算法：HMAC-SHA1签名算法

三、分解结论