Twitter / X 字符计数器

按照 X 实际计算帖子长度的方式计算帖子长度

280 个字符的限制听起来很简单，直到您开始编写并意识到表情符号、链接和某些重音字符并不按您期望的方式计数。该计数器与浏览器工具一样接近地反映了 X（以前称为 Twitter）的实际计数规则，包括该平台对 URL 的独特处理，因此您在此处看到的数字与您在撰写框中看到的数字相匹配，而不是天真的字符计数，让您猜测帖子是否真正适合。

如何使用

在框中输入或粘贴您的帖子，字符数将立即显示在下方，并根据 280 个字符的限制显示，并带有一个颜色编码条，当您接近并超出限制时，颜色编码条会从绿色变为琥珀色、橙色到红色。您包含的任何 URL 都会自动检测并计为 23 个字符，与平台的链接缩短行为相匹配，无论实际链接有多长。剩余的字符限额会在您键入时实时更新，因此您可以在观看数字的同时修剪或扩展您的措辞，而不是盲目写作并仅在最后检查。

为什么 URL 总是计为 23 个字符

X 使用自己的 t.co 缩短服务自动包装通过其系统发布的每个链接，并且每个链接，无论原始地址多长或多短，都会成为完全相同的固定长度的 t.co 链接。这就是为什么一篇包含指向简短、干净地址的链接的帖子和一篇包含指向包含跟踪参数的巨大 URL 的链接的帖子，与 280 个字符的预算相比，作者花费的字符数完全相同（目前为 23 个）。该工具通过检测文本中的 URL 并将每个 URL 计算为 23 个字符而不是其字面长度来复制这一行为，因此您在此处看到的计数与您发布时实际发生的情况相符。

表情符号和代理对怪癖

表情符号给字符计数带来了真正的麻烦，因为它们的内部存储方式。大多数现代表情符号，尤其是较新或更复杂的表情符号，都使用所谓的代理对（两个底层代码单元而不是一个）来表示，这意味着它们经常被视为两个字符，而不是像 JavaScript 和许多其他语言那样测量字符串长度的系统中的一个字符。 X 自己的计数系统有自己的特定规则，对于不寻常的表情符号组合、标志序列或带有修饰符（例如肤色选择器）的表情符号，有时可能与浏览器的本机字符串长度计算略有不同。对于绝大多数日常帖子来说，这种差异是看不见的，但如果您正处于限制的边缘并使用多个表情符号，那么值得留下一个小缓冲区，而不是相信倒计时到确切的最终字符。

字符限制的演变

Twitter 推出时设置了 140 个字符的限制，这一数字是特意选择的，旨在将一条推文加上一个用户名限制在一条 SMS 文本消息的 160 个字符的限制之内，因为该服务最初设计的目的是像在网络上一样通过文本消息传递。 2017 年，数据显示，许多用户，尤其是那些使用需要更多字符来表达相同想法的语言的用户，一直面临空间不足的问题，之后该限制增加了一倍，达到 280 个字符。后来对付费订阅者提出了更高的字符限制，但该对策所针对的免费 280 个字符限制仍然是大多数帖子的撰写标准。

书写紧凑，控制在 280 个字符以内

由于每个字符都有严格的限制，定期发帖的作者会养成在不失去意义的情况下进行修剪的习惯：仅当语气适合时，将“because”替换为“bc”，或将“&”替换为“and”，删除不会添加任何内容的填充词，并将链接或主题标签移动到最后，以便在需要最终修剪时首先删除它。在写作时观看实时计数，而不是先写出整个想法，然后才发现它太长了四十个字符，这样可以使这种严格的编辑不那么令人沮丧，因为你可以在提交之前准确地看到重写实际上节省了多少空间。

主题和多帖子草稿

当一个想法无法容纳 280 个字符时，通常的方法是将其拆分为一系列相互关联的帖子，而不是将所有内容强行整合到一个帖子中。首先在其他地方起草一个线程，然后通过这个计数器单独运行每个计划的帖子，这是一种可靠的方法，可以检查线程的每一个部分是否合适，包括一些备用字符，用于“1/”样式编号前缀（如果您使用一个线程），然后再开始一个接一个地发布它们，而不是在您已经开始发布较早的帖子后，在线程中发现一个帖子需要尴尬的最后一秒修剪。

私密且即时

当您键入时，所有内容都会在您自己的浏览器中运行，因此您的草稿帖子永远不会上传、记录或与任何人共享，一旦您离开页面，也不会保存任何内容。一旦加载，它就可以离线工作，只要您在发帖前需要快速、准确的字符检查，它就可以随时使用。