使用Linux/Unix/BSD的regex库
Python: 汉字转拼音（带声调）
Nov
27
mmsdk: 微信公众平台SDK - php版 
昨天关注了下 微信公众平台，的确是个好东西，赞一下tx近来的开放。
它的api 乍一看还是挺简单的，于是就写了个小东西玩玩。
但是在开发的过程中遇到了多个坑，通过有故事王国的@ctqmumu同学把问题转了过去。实际开发的过程中遇到了好几个问题，但是其他问题（包括发一条消息请求我两次）都莫名其妙消失了，只有一个问题（具体见后文）通过被喷的方式解决了。
总之最后是可以用了，于是多花了点时间，把代码完善了下，写好了注释和样例，放在了Google Code上面，有需要的同学可以拿去用。
下载地址：http://code.google.com/p/mmsdk/downloads/list
注：目前callback url仅支持80端口(@2012.11.27)
#UPDATE 2012.11.29 添加了对图片消息的支持（样例）、对调试的支持（DUMP请求/回复的xml文件），测试SAE可用（调试功能除外）
== 分割线，下面是纯吐槽 ==
=== 首先是态度问题。
他们没有sdk。
他们只有一页不那么详细的说明文档，和一个能运行的demo。
他们也没有技术支持，只有一个开发者交流群，里头有一个不说话的pm，和一群偶尔各说各话的开发者。
幸好里面还有一些热心的朋友。
=== 其次是接口问题。
这个接口真是烂得可以。
0. 知道程序员最讨厌的两件事是什么吗？
A：写文档 B：别人的代码没文档。
被喷的问题，是接口里的fromUser和toUser的问题。请求和回复的xml里头都有这两个字段，请求的fromUser应当是回复的toUser。文档没有任何说明（demo有具体实现，没有细看是我的问题）。但是这个接口有必要给两个user么？给用户的id不就够了吗？
1. 接口是同步的。
平台POST请求过来，然后等待我回复数据。同步的确是使得api更简单了，但是也带来的其他问题。对于开发者，我不知道我的数据是不是被正确接收了。如果不是，我没有任何地方可以查到为什么错了（如果是异步的话，可以检查后返回状态码）。对于平台，如果开发者处理慢了，平台需要等待，会导致吞吐量下降。
2. 签名校验几乎白做了。
接口里的签名，仅针对POST请求url里的三个参数签名，完全不管POST过来的xml。同样的，对于api的回复，平台也不做任何验证。也就是说，只要有一个中间人，伪造数据太容易了。反正只要post过来的url不变，请求和回复随便编。
3. 其他各种奇怪。
除了前面提到的fromUser/toUser之外：
A. 只有userId没有userName，而很多微信用户其实没有设置id，微信默认的id可能是类似于 "ogALVjjZmS3X8rHEmd4”，也就是说，开发者只能用来标识，不能用到回复里。 [UPDATE: 这个userId实际上是fakeid，坑爹啊]
B. 用户关注的时候，会发送一个消息过来。这个消息和用户发送一条"Hello2BizUser"的效果是一样的，无法区分（除非你再开个kv数据记录这个用户是不是第一次关注）。
C. 接口用的是xml格式，里头的数据只是简单用 <!CDATA[xxx]]> 这样的方式包起来。如果用户发送个 "]]>"，收到的xml文档就没法解析了。顺便提一下，其他开放平台的接口，通常同时提供xml和json格式。
=== 总结：很难想象微信居然发布了这样的一个api出来，步子大了容易扯着蛋啊。
转载请注明出自 ，如是转载文则注明原出处，谢谢:)
RSS订阅地址: https://www.felix021.com/blog/feed.php 。
它的api 乍一看还是挺简单的，于是就写了个小东西玩玩。
但是在开发的过程中遇到了多个坑，通过有故事王国的@ctqmumu同学把问题转了过去。实际开发的过程中遇到了好几个问题，但是其他问题（包括发一条消息请求我两次）都莫名其妙消失了，只有一个问题（具体见后文）通过被喷的方式解决了。
总之最后是可以用了，于是多花了点时间，把代码完善了下，写好了注释和样例，放在了Google Code上面，有需要的同学可以拿去用。
下载地址：http://code.google.com/p/mmsdk/downloads/list
注：目前callback url仅支持80端口(@2012.11.27)
#UPDATE 2012.11.29 添加了对图片消息的支持（样例）、对调试的支持（DUMP请求/回复的xml文件），测试SAE可用（调试功能除外）
== 分割线，下面是纯吐槽 ==
=== 首先是态度问题。
他们没有sdk。
他们只有一页不那么详细的说明文档，和一个能运行的demo。
他们也没有技术支持，只有一个开发者交流群，里头有一个不说话的pm，和一群偶尔各说各话的开发者。
幸好里面还有一些热心的朋友。
=== 其次是接口问题。
这个接口真是烂得可以。
0. 知道程序员最讨厌的两件事是什么吗？
A：写文档 B：别人的代码没文档。
被喷的问题，是接口里的fromUser和toUser的问题。请求和回复的xml里头都有这两个字段，请求的fromUser应当是回复的toUser。文档没有任何说明（demo有具体实现，没有细看是我的问题）。但是这个接口有必要给两个user么？给用户的id不就够了吗？
1. 接口是同步的。
平台POST请求过来，然后等待我回复数据。同步的确是使得api更简单了，但是也带来的其他问题。对于开发者，我不知道我的数据是不是被正确接收了。如果不是，我没有任何地方可以查到为什么错了（如果是异步的话，可以检查后返回状态码）。对于平台，如果开发者处理慢了，平台需要等待，会导致吞吐量下降。
2. 签名校验几乎白做了。
接口里的签名，仅针对POST请求url里的三个参数签名，完全不管POST过来的xml。同样的，对于api的回复，平台也不做任何验证。也就是说，只要有一个中间人，伪造数据太容易了。反正只要post过来的url不变，请求和回复随便编。
3. 其他各种奇怪。
除了前面提到的fromUser/toUser之外：
A. 只有userId没有userName，而很多微信用户其实没有设置id，微信默认的id可能是类似于 "ogALVjjZmS3X8rHEmd4”，也就是说，开发者只能用来标识，不能用到回复里。 [UPDATE: 这个userId实际上是fakeid，坑爹啊]
B. 用户关注的时候，会发送一个消息过来。这个消息和用户发送一条"Hello2BizUser"的效果是一样的，无法区分（除非你再开个kv数据记录这个用户是不是第一次关注）。
C. 接口用的是xml格式，里头的数据只是简单用 <!CDATA[xxx]]> 这样的方式包起来。如果用户发送个 "]]>"，收到的xml文档就没法解析了。顺便提一下，其他开放平台的接口，通常同时提供xml和json格式。
=== 总结：很难想象微信居然发布了这样的一个api出来，步子大了容易扯着蛋啊。
欢迎扫码关注：
转载请注明出自 ，如是转载文则注明原出处，谢谢:)
RSS订阅地址: https://www.felix021.com/blog/feed.php 。
