perl 使用RSA/RSA2 加密方式，实现自行签名和验签。
当开发支付宝支付的时候，由于支付宝方面需要进行数据的加签和验签。所以我们需要用到一个模块Crypt::PK::RSA\
实现加签和验签需要使用该模块下的sign_message和verify_message 这两个方法。
详细地址如下：http://search.cpan.org/~mik/CryptX-0.044/lib/Crypt/PK/RSA.pm \
一、如何调用加签方法：\
支付宝有两种加签方式：RSA 和 RSA2 对应文档中的属性应该为 "SHA1" 和 "SHA256" 这里支付宝推荐使用RSA2加密参数\
调用示例：
my $pk = Crypt::PK::RSA->new($priv_key_filename);
my $signature = $priv->sign_message($message, $hash_name, $padding);
1、"$priv_key_filename" 是一个应用私钥，其格式为 "-----BEGIN PRIVATE KEY-----" 和 "-----END PRIVATE KEY-----" 开头和结束的文件，中间内容为应用私钥
2、"$message"为需要加签的字符串，需要将'sign'除去将剩余的数据以字典排序
3、"$hash_name"为加签方式，"$padding"在这里理解为版本号只有v1.5和none两种
注：1>、其中$padding参数必须为"v1.5"。经过实验发现，如果不传v1.5则此方法中会默认带一个时间戳，否则导致每次加签得到的签名都是无法被验证的。\
2>、加签方法返回的是一个签名字符串。
\ \
二、如何调用验签方法：\
1、支付宝的验签需要在回调方法里使用。\
2、验签需要注意的地方：付款成功之后，支付宝会对商户提供的回调url进行通知，这里需要注意回调url地址中不能带有任何参数，类似于方法名，时间戳等。此时需要将接收到的通知进行除去'sing'和'sign_type' 进行字典排序，当作验签的字符串。
调用实例
my $pk = Crypt::PK::RSA->new($pub_key_filename);
my $valid = $pub->verify_message($signature, $message, $hash_name, $padding);
1、"$pub_key_filename" 为支付宝公钥，其格式为："-----BEGIN PUBLIC KEY-----" 和 "-----END PUBLIC KEY-----" 开头和结尾的文件，中间内容为支付宝的公钥
2、"$message"为需要加签的字符串，需要将'sign'和'sign_type'除去将剩余的数据以字典排序
3、"$hash_name"为加签方式，"$padding"在这里理解为版本号只有v1.5和none两种，"$signature"为支付宝回调通知中带有的签名。
注：1>、其中$padding参数必须为"v1.5"。经过实验发现，如果不传v1.5则此方法中会默认带一个时间戳，否则导致每次加签得到的签名都是无法被验证的。\
2>、验签方法返回的是0和1，0为失败，1为成功
=====关于微信手机端支付时的注意事项=====
- 与支付宝手机端支付不同的是，微信在加签验签方面使用的是MD5加密。商户需要通过自己的订单信息MD5加密之后当作签名拼接订单信息与微信回调url中的数据对比签名和订单信息，用来验证数据是否正确。
- 具体方式见微信API文档：https://pay.weixin.qq.com/wiki/doc/api/app/app.php?chapter=4_3
- 需要注意的地方：
- 签名之后的数据需要为xml格式的数据，使用Perl模块XML::Simple将加签之后的数据进行xml格式化，发送给微信端。
- 微信接收到数据之后，会将结果异步通知到商家客户端的回调url内。同样，需要需要使用XML::Simple将xml格式的回调数据转化为JSON格式进行商家后台判断。
- 对后台通知交互时，如果微信收到商户的应答不是成功或超时，微信认为通知失败，微信会通过一定的策略定期重新发起通知，尽可能提高通知的成功率，但微信不保证通知最终能成功。 （通知频率为15/15/30/180/1800/1800/1800/1800/3600，单位：秒）
1、通知url必须为直接可访问的url，不能携带参数。示例：notify_url：“https://pay.weixin.qq.com/wxpay/pay.action”
2、特别提醒：商户系统对于支付结果通知的内容一定要做签名验证,并校验返回的订单金额是否与商户侧的订单金额一致，
防止数据泄漏导致出现“假通知”，造成资金损失。
3、同样的通知可能会多次发送给商户系统。商户系统必须能够正确处理重复的通知。
