最大 Twitter ID?

发布于 2024-10-06 19:36:35 字数 224 浏览 1 评论 0原文

有人知道 Twitter 上的最大用户 ID 是多少吗?也就是说现在有大约 2 亿用户,那么 id 的范围是 1 - 2 亿吗?我发现在这个范围内一些 id 没有被使用。

我有一个基本上访问以下网址的 python 脚本:

"/1/statuses/user_timeline/" + str(user_id) + ".json?count=200"

谢谢,

Would anyone happen to know what the maximum user ID is on Twitter? That is by now there are about 200mil users, so would the id's range from 1 - 200million? I am finding that in that range some of the id's are not used.

I have a python script that is basically accessing the following url:

"/1/statuses/user_timeline/" + str(user_id) + ".json?count=200"

Thanks,

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

偏爱你一生 2024-10-13 19:36:35

Twitter API 表示 id 是一个整数 < em>“大于 53 位”,并且 64 位整数可以安全地保存该值。

尽管如此,还是建议使用字符串表示形式id_str“为了安全起见”!?!

The Twitter API says that id is an integer "greater than 53 bits", and that a 64 bit integer is safe to hold this value.

Nonetheless, it is recommended to use the string representation id_str "to stay on the safe side"!?!

寒江雪… 2024-10-13 19:36:35

Twitter API 不保证 user_id 是单调递增的值。它只是一个“引用对象的永久唯一 ID”(来自 API docs< /a>)。这意味着他们将来可能会重用(已删除用户的)ID,甚至以半随机方式分配这些值。 ID 甚至可能不是按顺序分配的。

过多地解读这个值,例如表示注册用户的数量,可能不太可靠。

The Twitter API doesn't guarantee that the user_id is a monotonically increasing value. It is simply a "a permanent unique id referencing an object" (from the API docs). This means they might in the future reuse IDs (of deleted users) or even allocate the values in a semi-random fashion. The IDs might not be even assigned sequentially.

Reading too much into this value, such as signifying the number of signed up users is probably not very reliable.

指尖上得阳光 2024-10-13 19:36:35

没有人知道这一点。

有人讨论过 Twitter 到底有多少用户。

有很多测试以及对 id 范围等的探测。

结果是 id 在很长一段时间内连续递增,但随后它们之间有大约 10 的规则间隙,有时似乎也是完全随机的。

我不知道这些信息收集的准确性如何,而且目标是其他的,但我认为你明白了。

从技术角度来看,我不希望在 Twitter 这样大的网络中出现任何其他东西。
我非常确定这些 ID 是分片的,这意味着它们被分配到特殊的区域或服务器中。
例如,如果您的 ID 等于 mudolo 17,我知道我必须在该服务器上查看。或者在那个国家。或者什么。

或者,服务器可能只有自己的前缀或残基类,用于在新用户注册时分配 id,以避免复制问题。

在大多数情况下,像这样泄露信息并不常见,或者说“不太酷”。
不要问我为什么,这只是我的经验,公司希望向外界展示尽可能少的信息。

这包括没有可复制的透明 ID 增量系统。

它还容易受到某种有害攻击、不必要的爬行等类似的攻击。

所以我的观点是。

没有办法给你一个可靠的答案。这应该是没有必要的。
您应该设计您的应用程序来处理每种可能的情况。

如果您想知道数据库字段应该设置多大以避免发生任何冲突。

我认为现在整数应该没问题。 (即使在 32 位系统上)

但请始终做好升级准备。

特别是不要假设它将保持数字状态。它只是一个独特的字符串!

No one knows that.

There were discussions on that in relation of how many users twitter really has.

There were a lot of tests as well as probing of id ranges etc.

The results were that the ids were sequentially incrementing a long time, but then had regular gaps of about 10 between them, and sometimes also seemed to be complelety random.

I don't know how accurately this information was collected, and the goal was something else, but I think you get the point.

From a technical point of view I would expect nothing else in a network as big as twitter.
I am pretty sure the IDs are sharded, which means they are assigned in special reagions or servers.
So that for example if your ID equals mudolo 17 I know I have to look on that very server. Or in that very country. Or something.

Or maby the server just have their own prefix or residue class for assigning ids when a new user signs up to avoid replication problems.

It is also in most cases uncommon, or "not so cool" to leak information as this.
Don't ask me why, its just my esperience that comapnies want to show as least information to the outside as possible.

This includes not having an reproduceable transparanet id incremention system.

It is also vulnerable for some sort of harmful attacks, unwanted crawling, stuff like that.

So my point is.

There is no way of giving you a reliable answer. And it should not be necessary.
You should design your application do deal with eveyr possible situation.

If you want to know how big you should make your database field not to get any conflicts.

I think integer should be fine for now. (even on 32 bit systems)

But always be prepared to upgrade.

Especially don't assume that it will stay numeric. Its just a unique string!

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文