Tag Archives: Telegram

Telegram bot 可以是一个HTTPS服务（Webhook模式：被动push Update）或者daemon（getUpdates模式：主动pull Update），不断的从bot API server获得Update，进行处理，做出动作，而实现一些功能。 Update解析 Telegram bot收到的Update对象有个不好的地方，就是它没有自带type属性。为了判断该Update到底是什么类型，需要先试探性的检查几个特定属性是否在Update内，然后再dispatch给各个type特定的处理函数。 输入控制 考虑到bot需要处理用户私聊和群聊两种场景，在获得update之后马上进行分类是必须的。 chat id == from id的情况下，bot收到的消息是私聊的。这种情况下一般消息上不会带有at bot的标志，不过偶尔也有人手贱非要输入，建议先无脑过滤掉，再进一步处理。此类bot大部分都是查询/控制类功能的bot，需要判断：发消息的人是否有权限对我发消息进行查询和控制 chat id != from id的情况下，bot收到的消息是群聊，chat id是群的ID号，from id是发消息人的ID号。如果bot被设计为处理群里的消息，在此时需要进行进一步判断： 响应 虽然Telegram在webhook模式提供了Making requests when getting updates 功能，但似乎一次只能返回一个动作。考虑到业务的复杂性，有时候需要做出多个动作，比如群管机器人的删除/封禁动作，既要做出删除封禁动作，还要给管理员回复一个消息，甚至有时候需要延迟一段时间再做动作等等……还是建议直接调用bot API实现功能，而不要使用在返回体中调用API的方法。这玩意，也就聊胜于无吧。 限制：forwardMessage处理多图 一个经常遇到的需求就是：监听群，收到某种消息之后就自动转发到另一处。但是一旦遇到这个消息含有多个图，情况就会变得糟糕，人类看来是一个消息带了多个图，但在bot API里会被分拆成多个Update，其中第一个图和文字组成第一个Update，其它的每个图分别一个Update，它们拥有相同的media_group_id号码，似乎可以相互关联； 单从Updates的角度来看，你需要等到下一个不带media_group_id号码的消息，或者拥有不同的media_group_id号码的消息，才能确定上次的一组media已经收集齐全了，然后才能用forwardMessages一次性转发把这堆内容转发过去，这样它在目标chat里才会正确的粘连起来；如果还没有凑齐就调用forwardMessages，则多次forwardMessages转发过去的消息之间并不会自动粘连。 但问题是：并没有一个字段声明这个media group里到底有多少个内容，也没有任何情报指出Telegram保证把这一堆Update放在同一个Updates里，尤其是：Webhook模式一次只能收到一个Update、getUpdates模式你指定的limit说不定会小于拆分的瓣数，甚至拆出来的好多瓣有可能是bot的不同实例分别处理的。 再加上绝大多数bot的写作方式都是循环一圈仅处理一条Update，导致：凑齐media … Continue reading →