上接 怎么爬Twitter

目前常用 Twitter 接口状态

Twitter 混用 Graphql api（以下简称graphql） 和 Restful（以下简称 restful 或 rest） 有很长一段时间了，虽然我写这篇文章的时候只是启用了时间线，但是现在又逐渐在主题帖、用户信息以及…… NFT 头像信息上面动手脚，我觉得这玩意迟早会替代掉 restful ，而最近重爬了 Twitter Monitor 的所有推文数据，修理了不少以前留下来的bug，顺便 restful 时间线开始无限429，翻各种 issue 都没人解答，我觉得是时候准备迁移了

于是开始整理这边的文章

RATE LIMIT

UserInfo

由于这边的函数自带 multi_curl，所以我写得轻松一点

TimeLine

由于Graphql接口比较慢（估计是生成过程的优化实在顶不住大量数据的混合），单线程循环跑起来很耗时间，我写了一个脚本，以10并发请求100条最新推文尝试找到这个极限。

最后发现998是最后一次能显示cursor，到999就没了，但这个现实是从0开始的，所以暂且认为 Timeline的极限是 999 次，再多就需要更换guest-token了，频繁更换guest-token可能会导致429，这时需要考虑用 代理池/多IP/分布式 等方法

Token 池

由于一个guest-token有使用次数和有效期（10800s）的限制，所以制作一个token池是可行的，我正在尝试制作一个 Token 池，做完将会补充此段

queryId

这些id还是存在于 main文件，可以参考以下脚本获取：

之前的脚本已经失效，新的获取方式请参考 BANKA2017/twitter-monitor ~/apps/scripts/updateQueryIdList.mjs，如果要用其他语言重构需要注意以下几点：

• 必须要设置合理的 User-Agent，直接用curl或者axios这种会返回错误的信息
• 这个脚本不稳定，未来可能会再次失效，需要持续关注

列表挺长的，我只列出 Twitter Monitor 需要用到的几个，其他请自行寻找用处

链接拼接的格式就是

let url = `https://twitter.com/i/api/graphql/${queryId}/${operationName}/?variables=` + encodeURIComponent(JSON.stringify(Variables))

这些queryId可能会被更新或者删除，但暂时没发现使用旧queryId会造成什么不良影响

2022.09.06 更新

这些 queryId 与请求时的 features 参数相关，如无必要请务必要不要随意更新，更新后请及时补充相关请求的 features 所需要的参数，若缺少相关参数会返回如下内容

{  "errors": [    {      "message": "The following features cannot be null: responsive_web_enhance_cards_enabled",      "extensions": {        "name": "BadRequestError",        "source": "Client",        "code": 336,        "kind": "Validation",        "tracing": {          "trace_id": "eeeeeeeeeeeeeeee"        }      },      "code": 336,      "kind": "Validation",      "name": "BadRequestError",      "source": "Client",      "tracing": {        "trace_id": "eeeeeeeeeeeeeeee"      }    }  ]}

Guest Token & Cookie

标注 * 的是非必须

* csrf-token

首先这玩意我真不知道什么环境下才会强制启用，估计是登录以后才会需要，不是必须的，本地生成

//ct0 in cookie//x-csrf-token in headerconst t = (() => {  const e = window.crypto || window.msCrypto;  if (!e) return;  const t = new Uint8Array(32);  e.getRandomValues(t);  let n = "";  for (let e = 0; e < t.length; e++) n +=    t[e].toString(16).substr(-1);  return n})();

从最后生成的结果来看……不就是32位随机字符串嘛，我就直接

echo md5(time());

* 首次访问的set-cookie

是的，首次访问会设置，但都不是必须的，我先摆个 pattern 在这里 /set-cookie: ([^;]+);/

guest_id_marketing: v1%3A164301325110776087guest_id_ads: v1%3A164301325110776087personalization_id: "v1_FBBNMaLDB1sdu2yWcCdHIQ=="guest_id: v1%3A164301325110776087

guest-token

• 通过

  curl 'https://twitter.com' --compressed

  
  此时得到的网页会有以下几行赋予 guest-token，就是那个 gt

  <script nonce="MDRjZmJlNWItYWNmOC00MTdiLWIxYjUtYTFhZTUyYTc2ODg4">  document.cookie = decodeURIComponent("gt=1232704521454999999; Max-Age=10800;  Domain=.twitter.com; Path=/; Secure");</script>

• 或

  curl 'https://api.twitter.com/1.1/guest/activate.json' \-X 'POST' \-H 'authorization: Bearer   AAAAAAAAAAAAAAAAAAAAANRILgAAAAAAnNwIzUejRCOuH5E6I8xnZz4puTs%3D1Zv7ttfk8LF81IUq16cHjh  LTvJu4FA33AGWWjCpTnA' \--compressed

  
  使用这种方式可以顺便取得上面那几个cookie

authorization

Bearer AAAAAAAAAAAAAAAAAAAAANRILgAAAAAAnNwIzUejRCOuH5E6I8xnZz4puTs%3D1Zv7ttfk8LF81IUq16cHjhLTvJu4FA33AGWWjCpTnA

这玩意我就没见它变过

用户信息

Request

• Method: GET
• URL:
  • by screen name https://twitter.com/i/api/graphql/7mjxD3-C6BxitPMVQ6w0-Q/UserByScreenName?variables={VARIABLES}
  • by user id https://twitter.com/i/api/graphql/I5nvpI91ljifos1Y3Lltyg/UserByRestId?variables={VARIABLES}
    • VARIABLES:

        {    "screen_name": "USER_SCREEN_NAME",//by screen name    "withSafetyModeUserFields": true,    "withSuperFollowsUserFields": true  }

        {    "userId": "USER_ID",//by user id    "withSafetyModeUserFields": true,    "withSuperFollowsUserFields": true  }

• Headers:
  • Content-Type: application/json
  • x-guest-token: 1232704521454999999
  • authorization: Bearer AAAAAAAAAAAAAAAAAAAAANRILgAAAAAAnNwIzUejRCOuH5E6I8xnZz4puTs%3D1Zv7ttfk8LF81IUq16cHjhLTvJu4FA33AGWWjCpTnA

Response

• Body
  • success
  • failure
    • 被封禁的 @realDonaldTrump
    • 不存在的帐号，脸滚键盘打的就不说是谁了

      { "data": {}}//不存在的用户啥都不返回了

• 与旧版相比基本没有什么改变，只需要修改两点，下面是前后对比：

  //rest apiconst userInfo = ...//取得信息let id_str = user_info.id_strlet user_info = user_info//GraphQLconst userInfo = ...//通过上述手段取得信息let id_str = user_info.data.user.result.rest_idlet user_info = user_info.data.user.result.legacy

关注者和正在关注

关注者

• Method: GET
• URL: https://twitter.com/i/api/graphql/neVf0YKN1h09TFZr4D43MA/Followers?variables={VARIABLES}
  • VARIABLES:

    {  "userId": "USER_ID",  "count": 20,  "includePromotedContent": false,  "withSuperFollowsUserFields": true,  "withDownvotePerspective": false,  "withReactionsMetadata": false,  "withReactionsPerspective": false,  "withSuperFollowsTweetFields": true,  "__fs_interactive_text": false,  "__fs_responsive_web_uc_gql_enabled": false,  "__fs_dont_mention_me_view_api_enabled": false}

• Headers:
  • Content-Type: application/json
  • x-guest-token: 1232704521454999999
  • authorization: Bearer AAAAAAAAAAAAAAAAAAAAANRILgAAAAAAnNwIzUejRCOuH5E6I8xnZz4puTs%3D1Zv7ttfk8LF81IUq16cHjhLTvJu4FA33AGWWjCpTnA

Verified 用户验证

Verified 原本指的是那些在用户名（name）后面带有小蓝勾的用户，一般为政企或名人，需要由Twitter验证

2022 年马斯克收购 Twitter 后开始为 Twitter Blue 用户提供小蓝勾，这种方式在 Twitter 中被称作 Blue Verified，用于校验的字段被写作is_blue_verified，可以从JSON.data.user.result.is_blue_verified验证

至此，只要用户符合Blue Verified或者原版Verified其中一种就可以获得小蓝勾

Twitter 又加了一种小金标，只要字段 ext_verified_type 值为 Business 即可展示小金标，在此以前 Twitter 借用了为各国官媒添加标记的位置来标识此类账号。目前暂时还不知道这个字段还能有什么值

同时，使用了新的 GrapHQL QueryID 查询 UsersVerifiedAvatars 接口即可批量查询用户是否取得Blue Verified，这个接口原本用于查询用户是否拥有 NFT 头像

另外有人写了浏览器插件用于快速查成分

• Method: GET
• URL: https://twitter.com/i/api/graphql/AkfLpq1RURPtDOcd56qyCg/UsersVerifiedAvatars?variables={VARIABLES}&features={FEATURES}
  • VARIABLES:

      {    "userIds": ["uid1", "uid2", "uid3"]//and more...  }

  • FEATURES:

      {    "responsive_web_twitter_blue_verified_badge_is_enabled": true  }

• Headers:
  • Content-Type: application/json
  • x-guest-token: 1232704521454999999
  • authorization: Bearer AAAAAAAAAAAAAAAAAAAAANRILgAAAAAAnNwIzUejRCOuH5E6I8xnZz4puTs%3D1Zv7ttfk8LF81IUq16cHjhLTvJu4FA33AGWWjCpTnA

Response

• Body
  • success

   {    "result": {      "__typename": "User",      "is_blue_verified": true,      "has_nft_avatar": false,      "rest_id": "1511811738076856322"    }  }

  • failure

  { "code": 366, "message": "NumericString value expected. Received " }

推文内容

时间线

• Method: GET
• URL: https://twitter.com/i/api/graphql/LNhjy8t3XpIrBYM-ms7sPQ/UserTweets?variables={VARIABLES}&features={FEATURES}
  • VARIABLES:

      {    "userId": "USER_ID",    "count": 20,//这个值不宜过大，会导致503，Twitter Monitor 默认最大配置为500    "withHighlightedLabel": true,    "withTweetQuoteCount": true,    "includePromotedContent": true,    "withTweetResult": false,    "withReactions": false,    "withUserResults": false,    "withVoice": false,    "withNonLegacyCard": true,    "withBirdwatchPivots": false,    "cursor": "CURSOR"  }//TODO timeline_v2

  • FEATURES:

      {    "dont_mention_me_view_api_enabled": true,    "interactive_text_enabled": true,    "responsive_web_uc_gql_enabled": false,    "vibe_tweet_context_enabled": false,    "responsive_web_edit_tweet_api_enabled": false,    "standardized_nudges_misinfo": false,    "responsive_web_enhance_cards_enabled": false  }

• Headers:
  • Content-Type: application/json
  • x-guest-token: 1232704521454999999
  • authorization: Bearer AAAAAAAAAAAAAAAAAAAAANRILgAAAAAAnNwIzUejRCOuH5E6I8xnZz4puTs%3D1Zv7ttfk8LF81IUq16cHjhLTvJu4FA33AGWWjCpTnA

Response

• Body
  • success

  //太长了我不想放了

  • failure

  {  "data": {    "user": {      "result": {        "__typename": "UserUnavailable"      }    }  }}

• count 默认值为 20，上限为100
• cursor 后面会提及获取方式，可不填，不填则获取最近的 count 条
• userId 为用户的数字 UID，就是上面的 rest_id
• 请求里面的 features 其实存在很久了，直到最新的接口不加上就不返回内容了……
• 最终可获取推文量为850

Tweets

此处出现大量的结构变化，虽然初次处理很烦，但一劳永逸

上面那句话就是扯淡，实际上暗改更多了

这次更新最明显的特征就是合并了 globalObjects 和 timeline

在新版全部timeline信息都在 JSON.data.user.result.timeline.timeline.instructions[0].entries或者JSON.data.user.result.timeline.timeline.instructions[1].entries，主要取决于TimelineClearCache有无出现

{  "instructions": [    { "type": "TimelineClearCache" },    { "type": "TimelineAddEntities", "entries": [...] },  ]}

• *TimelineClearCache 估计是拿来清理不需要的节点，比如删推就可以通过此处清理，我猜的，因为没实践过
• TimelineAddEntities 时间线上的所有信息都在这个节点的 entries 节点内

以下以 NODE 代称 JSON.data.user.result.timeline.timeline.instructions[1].entries 的一个节点

cursor

向上向下刷新用的cursor仍然位于最后两个NODE节点。

tweets

因为合并了全部内容，所以每个节点内不再是纯粹的推文，需要判断 NODE.content.entryType 的值是否为 TimelineTimelineItem ，如不是则可能是各种乱七八糟的用户推荐或者广告

下面是一些常用组件的迁移方向

• 所有原本在 globalObjects.tweets 内节点的内容都被移至 NODE.content.itemContent.tweet_results.result.legacy，但tweet_id被转移到 NODE.content.itemContent.tweet_results.result.rest_id
• 以前需要到 globalObjects.users 寻找到用户信息也被移到 NODE.content.itemContent.tweet.core.user_results.result.legacy但tweet_id被转移到 NODE.content.itemContent.tweet.core.user_results.result.rest_id
• 以前被视为独立的转推推文（位于 globalObjects.tweets ）被移到 NODE.content.itemContent.tweet_results.result.legacy.retweeted_status_result.result
• 被引用的推文从 globalObjects.tweets 转移到 NODE.content.itemContent.tweet.quoted_status_result.result
• 转推的原始推文信息被移动到了 NODE.content.itemContent.tweet.legacy.retweeted_status.legacy，不使用原始推文会丢失所有 extended_entities 的内容，同时各种 hashtag、url 等文字的替换会出现位置错误的问题（这个等一等，等我买个老花镜来比较它跟上面那个是什么关系）
• 转推的媒体被转移到 NODE.content.itemContent.tweet.legacy.retweeted_status.legacy.extended_entities.media（好乱啊，让我捋捋）

Cards

卡片转移到 NODE.content.itemContent.tweet_results.result.card.legacy

原本我以为会很复杂，其实还是不需要做大量变动，如果以前有写过这部分处理就会发现卡片的内容被移到 legacy，所以可以重新将binding_values改为以前的kv对模式：

//重新将 Array 改回 Object$tmpBindingValueList = [];foreach ($cardInfo["binding_values"] as $bindingValue) {    $tmpBindingValueList[$bindingValue["key"]] = $bindingValue["value"];}$cardInfo["binding_values"] = $tmpBindingValueList;//这是改成 graphql 的代码//$tmpList = [];//foreach ($cardInfo["binding_values"] as $key => $value) {//    $tmpList[] = ["key" => $key, "value" => $value];//}//$cardInfo["binding_values"] = $tmpList;

NSFW

这个一般只会在图片处提醒一下，但也在一些地区（比如日本）某些推文整篇都被限制，根据 Notices on Twitter and what they mean，被标记成成人内容的推文会被限制，但不同地区为什么会有不同的标准，我暂且不明白，先放一个例子，这类推文一般无法在非登录状态下取得

2022-11-11 更新

得到这些信息的共同点是使用了新的Bearer Token，关于新旧Bearer Token的异同请看我的另一篇文章

而媒体资源上的NSFW内容由上传者自行标记，可选的类型包括 裸体、暴力和敏感内容

Errors

TODO 本节待更新

以前判断挺轻松的，只需要判断有没有errors就行了，现在需要判断不存在data.user.result.timeline，错误原因出现在data.user.result.__typename

twitter会偷懒，现在错误原因基本都是 Something went wrong……

致谢

• Juicpt 指出不少新的变动
• 评论区的大家

参考

• https://help.twitter.com/en/rules-and-policies/notices-on-twitter Notices on Twitter and what they mean
• https://help.twitter.com/en/managing-your-account/about-twitter-verified-accounts How to get verified on Twitter