推文线程分割器
粘贴长帖子并使用实际加权字符计数规则将其拆分为真正的 X/Twitter 线程 - 每个 URL 都算作固定的 23 个字符,并且星体平面表情符号正确计数 - 具有智能段落/句子/单词边界和保留其自己空间的线程编号。
结果
一条推文的 280 个字符限制不是简单的“text.length”检查,大多数天真的字符计数器都会以重要的方式犯这个错误。该工具实现了真正的 X/Twitter 加权长度算法:每个代码点都会根据平台自己的 Twitter 文本库使用的相同加权范围表进行查找,其中大多数拉丁文、西里尔文、希腊文和常见标点符号字符计为 1 个字符,但这些范围之外的所有字符(CJK 表意文字、大多数表情符号、许多符号)计为 2。同样重要的是,通过真正的 Unicode 代码点(不是原始 UTF-16 单位)迭代文本意味着像替代对脸或旗帜这样的星界表情符号会被正确计数一次,而不是像天真的“.length”检查那样意外地重复计数。
该工具诚实地实现了另一个容易错过的真实规则:每个 http(s):// 或 www。无论文字链接是 20 个字符还是 200 个字符,文本中的 URL 都被计为 23 个字符。这是 t.co 缩短的长度 X 替代任何链接的真实长度,这意味着包含长跟踪 URL 的推文为实际单词留下的空间比简单的字符计数所建议的要多得多 - 拆分器在决定推文结束位置时会考虑到这一点。
将一篇长帖子分成一条线索不仅仅是每 280 个字符就被剪掉那么简单。该工具按优先顺序处理三层边界:它首先尝试将整个段落保持在一起,当段落太长时,回退到真正的句子边界启发式(基于正则表达式的分割器,它知道句子结尾句点和缩写(如“Dr.”或“e.g.”)或十进制数字(如“3.14”)之间的区别),并且仅在单个句子超出限制时才将单个单词中断作为最后的手段 -在每一层,URL 都被视为一个不可分割的令牌,并且永远不会在中间分割。
线程编号(“1/7”、“2/7”...)有一个非常容易错过的边缘情况:编号文本本身会用完它所附加的推文中的字符,并且编号的宽度取决于推文总数,而在拆分完成之前您是不知道的。该工具通过迭代地重新分割来解决这个问题,在每次传递之前保留编号的实际加权长度,直到保留的预算与实际生成的推文计数相匹配。默认情况下使用标准的 280 个字符限制,但诚实地说,对于不需要作为公共线程工作的帖子,X Premium 订阅者可以获得更高的长格式限制(最多大约 25,000 个字符)——如果您的目标是自定义限制,则可以通过切换开关切换到自定义限制。