发布之前,如何把文本清理干净

发布一样东西——一篇帖子、一个页面、一封营销邮件——牵扯到十几个没人愿意做的细小文本决策。它们大多有正确答案,而做错与做对的差别,就是文案读起来是“经过考虑”还是“随手一写”。

这是一份检查清单。

字数,以及真正生效的那些限制

每个平台都有限制,而多数写作者是靠撞上去才知道的。

位置 限制 说明
SEO 标题标签 约 60 字符 搜索引擎按像素宽度截断,不是按字符数——宽字符会更早被切
Meta description 约 155–160 字符 不是排名因素,但它是你在搜索结果里的广告词
X / Twitter 帖子 280 字符 链接无论实际多长都按 23 字符计
LinkedIn 帖子 3000 字符 只有前约 210 字符会显示,之后是“展开”
Instagram 配文 2200 字符 同样的截断机制
邮件主题行 约 40–50 字符 移动端比桌面端更早截断

真正会咬人的是字符数,因为在你编辑器里放得下的标题,到了展示位置未必放得下。字数统计工具会同时给出“含空格”和“不含空格”两种字符数——有些平台只算其中一种。

阅读时长是另一个估算,而且数字随语言变。 英文散文的舒适阅读速度大约是每分钟 200–250 词。中文通常按每分钟 300–500 字。一篇 1000 词的英文文章约 4 分钟;一篇 1000 字的中文接近 3 分钟。如果你同时面向两种读者,不要假设“长度一样、阅读时间就一样”。

还有一点:中英文的“字数”根本不是同一种统计。 英文按空格切词,中文词与词之间没有空格,惯例是把每个汉字算作一个单位。一个把英文规则套到中文上的计数器,报出来的数字会差一个数量级。混排文本需要对各自的片段用各自的规则。

大小写,以及为什么标题大小写是个烂摊子

大小写转换看着是小问题,直到你想把它自动化——因为“正确”取决于你遵循哪本风格手册。

标题大小写有三套互相打架的标准。 美联社(AP)风格把四个字母以上的词首字母大写。《芝加哥手册》用另一个阈值,还有它自己的一串例外。现在很多出版物干脆改用句子式大小写,理由是更好读、而且不可能写错。没有普适答案——选你所在出版物用的那一套,然后一致地执行。

自动化标题大小写工具一贯会搞错的是:它们会把本该保持小写的介词和连词首字母大写。如果你在遵循某本风格手册,检查输出,别信它。

代码世界里的命名约定规则更清楚,因为机器得解析它们:

  • camelCase —— JavaScript 和 Java 变量
  • PascalCase —— 类名、React 组件
  • snake_case —— Python、Ruby、SQL 列名
  • kebab-case —— URL、CSS 类名、HTML 属性
  • CONSTANT_CASE —— 多数语言里的常量

大小写转换工具会一次性生成全部,这正是它有用的地方——你很少只需要一种。

有一条警告值得直说:全大写会降低阅读速度。 它抹掉了读者依赖的词形轮廓,而且读起来像在吼。短标签或需要冲击力的标题可以用。段落里不能用,更长的东西尤其不能用。

Slug:短、稳定、只定一次

slug 是 URL 里人能读的那部分——链接里的 how-to-clean-up-text。三条规则几乎覆盖所有情况。

小写、用连字符分隔。 不要用下划线:搜索引擎历来把连字符当词分隔符、把下划线当连接符,所以 text-case 读作两个词,text_case 读作一个。

去掉重音和符号。 café 变成 cafe。这不是审美偏好——URL 里的百分号编码既难看又难分享。slug 生成工具会自动剥掉它们。

要不要去停用词,定了就别纠结。 去掉 the、a、of 能让 slug 更短。现代搜索引擎基本忽略停用词,所以这是个可读性决策,不是 SEO 决策。短一点通常更好分享,也更好让人手打。

而比上面三条都重要的一条:slug 一旦发布就不该再改。 它是页面的地址。改掉它会断掉所有已有链接、书签和分享——除非你配了重定向,而多数静态站默认没有。第一次就选好。

占位文本,以及它什么时候骗你

Lorem ipsum 是从西塞罗《论至善与至恶》里打乱的拉丁文,原文写于公元前 45 年。它从 16 世纪起就被当填充文本用,原因很具体:它的字母分布看起来像自然语言,所以用填满它的版面,能大致看出真实文字填进去后的样子。

这也正是它的局限。Lorem ipsum 没有重要的长词和短词、没有专有名词、没有数字、也没有真实段落会出现的那种断行位置。 一个用填充文本看着很平衡的设计,真实内容一到就可能崩——你以为 12 个字符的位置来了个 40 字符的产品名,你以为两行的标题折成了三行。

早期做版面时用 lorem ipsum 生成工具,然后尽早换成真实内容。最贵的设计错误,都是在设计定稿之后才被发现的。

编码:为什么 URL 装不下你以为能装的东西

把空格或一个汉字粘进 URL,它就坏了——因为 URL 定义在一个受限字符集上。集合之外的一切都必须做百分号编码:% 加两位十六进制。空格变成 %20,汉字“中”变成 %E4%B8%AD。

两个函数、两种活,搞混就是常见 bug:

  • encodeURIComponent 会把所有在 URL 里不安全的字符都转义,包括 :/?#&。用它处理你要塞进查询字符串里的值。
  • encodeURI 保留结构字符不动。用它处理你想变安全、但不想破坏结构的整个 URL。

用 encodeURIComponent 去编码一个完整 URL,你会得到 https%3A%2F%2Fexample.com——一个不再是 URL 的字符串。URL 编码工具会把两种结果并排显示,这是看清它们差别最快的办法。

常见问题

一篇博客该写多少字? 没有正确答案,“最少 1500 词”是民间传说。长度应该跟着要回答的问题走。重要的是内容完整,而不是凑字数。

标题该用标题式大小写还是句子式? 都行,只要一致。句子式更不容易写错。如果你用标题式,请遵循一本具名的风格手册,而不是凭感觉。

发布之后还能改 URL slug 吗? 能,但除非对旧地址做重定向,所有已有链接都会断。把 slug 当作永久的,第一次就写对。

字数统计含空格吗? 两种都有用。平台限的“字符数”通常指含空格。计数器两种都给,省得你猜。

1000 个词要读多久? 按舒适速度,英文散文约 4 分钟。中文按每分钟字数衡量,所以同样的阅读时间对应大得多的字数。

为什么我的 slug 里有 %20? 因为在拼 URL 之前那个空格没被替换掉。先生成 slug,再使用它——永远不要把原始文本直接粘进 URL。

本文提到的工具

← 全部指南