Lirian Su
Lirian Su
FAQ的话大概还是放在readthedocs上？ 我们可以先记一些样板问题， 比如 * Access Token要怎么管理? #185 #224 等等
你可以看一下是不是在处理 `ComponentVerityTicket` 的地方调用了 `wechatpy.parser.parse_message` （不能这么调用） `wechatpy.parser.parse_message` 这个方法是用来处理一般的事件推送的，微信的 ComponentVerifyTicket 是在开放平台中额外配置的回调地址，得单独处理才行
TL;DR: 不要用 `wechatpy.parser.parse_message`，要用 `wechatpy.component.WeChatComponent.cache_component_verify_ticket` 解释： [微信推送的样例数据](https://developers.weixin.qq.com/doc/oplatform/Third-party_Platforms/api/component_verify_ticket.html)应该是这样子的（与普通的公众号推送不一样）： ``` some_appid 1413192605 component_verify_ticket some_verify_ticket ``` [对应文档上](https://docs.wechatpy.org/zh_CN/stable/component.html)标准写法是 ``` from wechatpy import WeChatComponent component = WeChatComponent('app_id', 'app_secret', 'component_token', 'encoding_aes_key') component.cache_component_verify_ticket(self, msg, signature, timestamp, nonce) ```
十分科学的问题。 目前我们的解决方案，要求调用方要明白自己是公众号还是小程序。 假如公众号调用了小程序的接口， 会在微信API层面报48001无授权的错。 但是大部分情况可以一视同仁，做归一化的处理。 （比如刷新access token，之类之类的操作） 假如说我们拆分了`wechatpy.wxa`， 优势是见文知意，拆分了不同的对象，调用方便于管理。 麻烦的地方在于比较难做归一化处理， 而且分散了地方。 集成在`wechatpy.client`的话， 其实我们默设了一个前提， 就是一个公众号对应一个小程序。 这三种处理方式都各有优点， 就我个人而言，倾向现有的处理方式。 库提供归一化的对象， 让业务代码来控制小程序、公众号的API。😃
@cloverstd 嗯，科学， 拆分以后 api 调用的权限区分也会更加明显。
update: 微信现在的接口调用，直接返回长链了，相当于他们做了个向前兼容
目前仅返回英文名，可以考虑假如简单的 if 判断自行处理中文 常量参考 https://github.com/LKI/chinese-calendar/blob/master/chinese_calendar/constants.py
是个好需求，我标记一下
更新一下版本到最新即可 `pip install -U 'chinese-calendar>=1.8.0'`
> 没想到一年就是大半年。 > 这不对吧 😂“一念”就是大半年。 感谢捉虫~