今天在看书的时候，看到一句话觉得很有道理：“尽量通过读取协议头来获取有用的信息”，就萌生了一个想法，BAT公司提供的服务接口，有哪些信息是放到头部的？
百度
- OCR接口：appkey放header里面，没有参数校验码；
- 百度钱包支付接口：商户号、编码字符集、加密算法、接口版本、sign都放post中；
没有使用的参数不参与加密，且不需要传；
阿里
- 支付宝接口：商户号、编码字符集、加密算法、sign都放post中；
没有值的参数无需传递，也无需包含到待签名数据中； - MNS通知接口：消息ID放header中，md5加密校验码在post里面；
支持json和xml两种格式；
微信
- 微信支付接口：公众号ID、商户号、sign都放post中；
编码只支持UTF-8；xml格式；
总结
- 签名(sign)规则基本都一样，对这个有兴趣的可以参考后面的附录；
- 商户号、签名都是放到post消息体中；
- 基本上没有往header里面放数据的
附录-签名规则(微信为例)
a.对所有传入参数按照字段名的 ASCII 码从小到大排序（字典序）后，使用 URL 键值对的
格式（即 key1=value1&key2=value2…）拼接成字符串 string1，注意：值为空的参数丌参不
签名；
b.在 string1 最后拼接上 key=Key(商户支付密钥)得到 stringSignTemp 字符串，幵对
stringSignTemp 进行 md5 运算，再将得到的字符串所有字符转换为大写，得到 sign 值
signValue。
假设以下为 package 传入参数：
appid=wxd930ea5d5a258f4f
auth_code=123456
body=test
device_info=123
mch_id=1900000109
nonce_str=960f228109051b9969f76c82bde183ac
out_trade_no=1400755861
spbill_create_ip=127.0.0.1
total_fee=1
key=8934e7d15453e97507ef794cf7b0519d
i：经过 a 过程 URL 键值对字典序排序后的字符串 string1 为：
appid=wxd930ea5d5a258f4f&auth_code=123456&body=test&device_info=123&mch_id=1900000109&nonce_str=960f228109051b9969f76c82bde183ac&out_trade_no=1400755861&spbill_create_ip=127.0.0.1&total_fee=1
ii：经过 b 过程后得到 sign 为：
sign
=md5(string1&key=8934e7d15453e97507ef794cf7b0519d).toUpperCase
=md5(appid=wxd930ea5d5a258f4f&auth_code=123456&body=test&device_info=123&mch_id=1900000109&nonce_str=960f228109051b9969f76c82bde183ac&out_trade_no=1400755861&spbill_create_ip=127.0.0.1&total_fee=1&key=8934e7d15453e97507ef794cf7b0519d).toUpperCase()
="c380bec2bfd727a4b6845133519f3ad6".toUpperCase()
="C380BEC2BFD727A4B6845133519F3AD6"
