sublime text 的 sort_lines 命令按每行首个非空白字符的 ascii 值排序,非整行语义排序;需选中完整多行(含换行符)、注意大小写敏感及数字字典序问题。

Sublime Text 按字母顺序排序行,本质是调用 sort_lines 命令,但它**不按“整行语义”排,只比每行第一个非空白字符的 ASCII 值**——理解这点,才能避开 90% 的错排。
Ctrl+F9 排出来不是 A-Z?先确认你真在排“行”
这个快捷键(Windows/Linux)或 Cmd+F9(macOS)只对「完整选中的多行」生效,且要求选区包含换行符。常见失效场景:
- 只点了一下光标,没做任何选择 →
sort_lines作用于整个文件,极易误操作 - 用鼠标框选中间几列(比如只选中
log两个字母)→ 不被识别为多行,命令静默失败 - 选区末尾没包含最后一行的换行符 → 该行完全被跳过
- 某行开头全是空格或
\t→ 它跳过空白,拿后面第一个可见字符比较;整行只有空格 → 被排到最前面
验证是否选对:右下角状态栏必须显示类似 5 lines,不能只写 5 selections。
大小写敏感导致 Banana 排在 apple 前面?这是设计,不是 bug
sort_lines 默认大小写敏感,因为大写字母 A–Z 的 ASCII 值(65–90)小于小写字母 a–z(97–122)。所以 Banana 一定排在 apple 前面。
- 临时解法:先全选目标行,按
Ctrl+K, Ctrl+L(Windows/Linux)转小写,再按Ctrl+F9 - 更稳路径:打开命令面板
Ctrl+Shift+P,输入Sort Lines (case insensitive)并执行(2026 年主流版本仍可用) - 别依赖
Sort Lines (case sensitive)菜单项——它和普通Sort Lines在 v4.4+ 中行为一致,无需刻意避开
数字行(如 1.txt、10.txt)排成 10.txt、1.txt?补零或装插件
纯数字字符串走 sort_lines 是字典序,10.txt 的首字符 '1'(ASCII 49)比 2.txt 的 '2'(50)小,所以前者排前面。
- 手动补零(无插件):选中数字行 →
Ctrl+H打开替换 → 勾选Regular Expression→ 查找^(\d+)$,替换为0000000000$1(补够位数)→Replace All→Ctrl+F9→ 再用^0+(\d+)$替换为$1去前导零 - 推荐插件:
Sort Numbers(通过 Package Control 安装),命令面板输入Sort Numbers: Sort Ascending即可自然序排序 - 注意:补零法依赖你预估最大位数;若数字跨度极大(如同时含
7和1234567890),补 10 个零比补 5 个更稳妥
整理常用快捷键与配置建议
原生快捷键有限,高频操作建议靠命令面板 + 自定义键位补足:
-
Ctrl+F9/Cmd+F9:升序排序(仅对已选中完整行生效) -
Ctrl+Alt+R/Cmd+Option+R:反转当前顺序(不是重新降序,必须先升序再反转) -
Ctrl+Shift+U:去重(等价于 Unixuniq,只删连续重复行,**必须先排序再执行**) - 自定义降序快捷键(推荐):进入
Preferences → Key Bindings,添加:[{"keys": ["ctrl+shift+f9"], "command": "sort_lines", "args": {"reverse": true}}] - 忽略大小写排序没有原生快捷键,但可绑定:
[{"keys": ["ctrl+alt+f9"], "command": "sort_lines", "args": {"case_sensitive": false}}]
真正容易被忽略的是:所有排序结果都取决于你选中的那几行、它们的首字符是否干净、大小写是否统一——sort_lines 不会帮你判断逻辑边界,它只忠实地比 ASCII 值。











