/** * 按COS要求从数组中获取 Signature 中 [HttpString] 内容 * 标准格式 key=value&key=value&... * 数组元素按键字典排序 * * key转换为小写 * value进行UrlEncode转换 * 转换为key=value格式 * 多对key=value之间用连接符连接 * */ function get_http_header_string($headers){ if(!is_array($headers)){ return false; } try{ $tmpArray = array(); foreach($headers as $key => $value){ $tmpKey = strtolower($key); $tmpArray[$tmpKey] = urlencode($value); } ksort($tmpArray); $headerArray = array(); foreach( $tmpArray as $key => $value){ array_push($headerArray, "$key=$value"); } return implode('&', $headerArray); } catch(Exception $error){ return false; } }
为什么要小心？
HTTP原始请求头和请求参数用在了四个地方，分别是请求签名里的 q-header-list 和 Signature 里的 HttpHeaders——两者都用到了HTTP原始请求头；请求签名里的 q-url-param-list 和 Signature 里的 HttpParameters——两者都用到了HTTP请求参数。一定要保证HTTP请求头和请求参数所选用的数量和对象一致
相同：生成 q-header-list 的HTTP请求头数量和成员要和生成 HttpHeaders 的相同，生成 q-url-param-list 的HTTP请求参数数量和成员要和生成 HttpParameters 的相同
不同：q-header-list 和 q-url-param-list 只取 key 部分，HttpHeaders 和 HttpParameters 取 key 和 value 部分
输出结果和校验
至此，请求签名中7个值都有了，有的是来自用户信息，有的需要计算，需要计算的上面也给出了所有的计算方法和为什么如此计算的个人理解。最后只需要按照官方要求进行输出即可。看一下🌰，在PostMan中选择Post方法，选择form-data方式提交数据，在Body中给出所有用户参数（这个地方为了测试算法是否与官方一直，所以几乎所有的值都是Post提交上去的，实际时间、Host都可以在算法中创建）
提交后，返回结果
字很小，单独把结果提取出来
{ "Authorization": "q-sign-algorithm=sha1&q-ak=AKIDQjz3ltompVjBni5LitkWHFlFpwkn9U5q&q-sign-time=1417773892;1417853898&q-key-time=1417773892;1417853898&q-header-list=host;x-cos-content-sha1;x-cos-storage-class&q-url-param-list=&q-signature=14e6ebd7955b0c6da532151bf97045e2c5a64e10", "Host": "bucket1-1254000000.cos.ap-beijing.myqcloud.com", "Content-Length": "12000" }
Host和Content-Length是我自定义输出，主要是看Authorization部分，和官方文档给出的结果值完全一致，说明算法逻辑正确。
吐槽和反思
version 0.2
昨天基于对腾讯云API的“愤慨”和怕忘记而急于记下思路的原因，写的很是潦草，发觉吐槽人家官方文档顺序不同自己的更不同，今天重写
version 0.1
之前 C# 做过一次对接口的研究，死活不行，最后通过腾讯技术支持提供的AWS的SDK调用成功，真是心累。本次需要用PHP做项目，必须要攻克，本来不应该多难，必须要为自己的智力和年龄讨个说法。不过还是想再次吐槽官方文档，看似详尽，顺序前后不够一致，示例代码细节比如参数不够统一，造成新手容易误解怎么前后对不上，对一些细节和前后逻辑不能第一时间融汇贯通。比如我自己，就是再次研究接口时，才理解里边关于[SignHeaderList]等和计算[Signature]有什么关联。