Slug 生成器

把任意标题转换成干净的 URL slug。自动去除重音、可选分隔符、控制大小写与长度,支持去停用词和保留 Unicode。

把标题转换成干净、URL 安全的 slug。 重音字符会折叠为纯 ASCII,标点被去除,单词用你选择的分隔符连接。通过选项可以控制大小写、限制最大长度或去掉常见停用词。

什么才算一个好的 URL slug

slug 的意义

slug 是 URL 中用来标识页面、且人类可读的那一段:/blog/how-to-cache-resumes-in-redis 里的 how-to-cache-resumes-in-redis。它用一段人能读懂、能记住、点击前就能判断内容的文字,取代了不透明的数字 ID。搜索引擎会在结果中展示 URL,因此一个描述性强的 slug 既让读者安心,也强化了页面的主题信号。

slug 应遵守的规则

只使用小写 ASCII 字母、数字和一种分隔符。这一条同时避开了三类问题:多数服务器上 URL 的路径部分区分大小写,/About/about 是两个不同资源,大小写混用等于给自己制造重复内容;百分号编码会让任何非 ASCII 字符变长三倍,复制成纯文本后极难阅读;而空格根本不被允许,只会变成 %20+

短横线是约定俗成的分隔符。Google 多年来明确表示它把短横线当作词分隔符、把下划线当作词连接符,也就是说 cache_redis 可能被当成一个词,而 cache-redis 明确是两个词。除非有特殊理由,就选短横线。

音译还是保留 Unicode

默认情况下本工具会把带重音的字符折叠为最接近的 ASCII 形式:éeßssłl。实现方式是先用 Unicode NFD 规范化分解文本、去掉组合标记,再用一张查找表处理分解无法覆盖的连字和特殊字母。

保留 Unicode 也是完全正当的选择。国际化 URL 在所有现代浏览器里都能正常工作,对使用该语言的读者可读性高得多 —— 中文或俄文标题被音译成 ASCII 后往往毫无意义。代价是原始 URL 里会出现百分号编码的字节,粘进邮件或终端时看起来相当吓人,而且部分老旧工具仍会处理出错。如果你的受众读得懂该文字,就打开「保留 Unicode 字母」;如果 slug 必须在各种未知系统间流转,就保持关闭。

长度与停用词

技术上没有值得担心的长度限制,但超过大约 60 个字符的 slug 会在搜索结果里被截断,分享起来也不方便。截断最好落在词边界上而不是词中间,本工具的长度选项就是这么做的。

去掉停用词(theaofand)能在几乎不损失含义的前提下缩短 slug。这是风格选择而非排名因素,现代搜索引擎完全有能力忽略它们。但要小心那些停用词本身承载意义的标题 —— 把 "The Who" 或 "To Be or Not to Be" 的停用词去掉,整个短语就毁了。

稳定性比完美更重要

slug 一旦发布并被链接,改动它就会打断所有入站链接,除非你配置重定向。一个上线一年、略有瑕疵的 slug,几乎总是好过一个更干净但会让你丢掉外链的新 slug。上线前定好格式,之后就别动了。

开源说明:音译基于 Unicode NFD 规范化加一张小型连字表,直接实现,未使用第三方库。

常见问题

用短横线还是下划线?
用短横线。搜索引擎把短横线当作词分隔符、把下划线当作词连接符,所以短横线 slug 会被拆成独立单词。而且下划线在链接默认的下划线样式下几乎看不见。
slug 一定要小写吗?
是的。多数服务器上 URL 的路径部分区分大小写,/About 和 /about 可能指向两个不同页面,从而分散排名信号。强制小写能彻底消除这类问题。
可以用中文等非英文字符吗?
可以,现代浏览器完全支持,而且对母语读者可读性高得多。代价是原始 URL 会变成百分号编码,在浏览器之外显示时比较杂乱。如果这个取舍适合你的受众,就打开「保留 Unicode 字母」。
slug 多长合适?
长到能说明内容,短到一眼能读完。大约三到六个词、或 60 个字符以内,能在多数搜索结果里完整显示。
要不要去掉停用词?
通常无害,还能让 slug 更清爽,但这只是外观选择,对排名没有帮助。当停用词是关键成分时(如乐队名或引语)就别去。
以后还能改 slug 吗?
只有配上从旧 URL 到新 URL 的 301 重定向才安全。否则你会失去所有已有链接和收藏,以及积累的排名信号。尽早确定格式并保持不变。