Bash环境下ls与sort命令排序文件结果异常问题

这个异常不是bash、ls或sort的实现缺陷，是当前系统区域设置（locale）的排序规则（collation）导致的，所有观测到的现象都能完全对应规则逻辑：

• 绝大多数Linux桌面发行版默认使用UTF-8编码的对应语言区域设置（比如en_US.UTF-8、zh_CN.UTF-8），这类locale的通用排序规则面向词典文本设计，会将.（句点）、-（连字符）这类标点标记为低权重分隔符，排序比较时直接跳过这类字符，不参与优先级判定。
• 对比Picture 001.jpg和Picture 001b.jpg时，前半段Picture 001完全一致，跳过句点后逐字符比较：
  • 无后缀文件的下一个有效比较字符是.jpg的首字母j（ASCII码值106）
  • 带b后缀文件的下一个有效比较字符是后缀字母b（ASCII码值98）
    由于b的优先级高于j，带b后缀的文件会排在无后缀文件前面，和你看到的异常结果完全一致。
• 你观测到的两个特殊现象完全符合规则逻辑：
  • 当序号后的后缀字母从k开始时，k的ASCII码值为107，大于j的106，因此带这类后缀的文件会排在无后缀文件后面，看起来排序恢复正常。
  • 028序号下的两个带后缀文件使用的后缀是r（ASCII码114）、s（ASCII码115），都大于j，因此排序结果符合预期。
• Bash字符串比较的测试结果也和规则匹配：
  • 不带.jpg后缀比较Picture 001和Picture 001b时，前者匹配完公共前缀就到达字符串末尾，短字符串默认优先级更高，因此返回true。
  • 带上.jpg后缀后，会触发跳过句点的排序规则，比较到b优先级高于j，无后缀字符串反而排序更靠后，因此返回false。
• 你提到的其他同类程序（比如图形界面文件管理器）能正确排序，是因为这类工具内置了专门面向文件名的自然排序逻辑，不会直接复用系统locale面向通用文本的词典排序规则，因此不会出现这类和直觉不符的结果。

执行以下命令临时切换到C locale（按ASCII值逐字节排序）查看文件列表，就能得到你预期的排序结果：

LC_ALL=C ls

C locale的排序规则不对任何字符做特殊权重处理，所有字符直接按ASCII码值比较优先级：句点的ASCII码值为46，远小于小写字母的起始值97，因此Picture 001.jpg中001后面紧跟的句点优先级高于所有字母，自然会排在同序号带字母后缀的文件前面。

根据使用场景选择对应方案即可：

• 单次临时使用预期排序：执行ls时指定C locale排序规则，命令为LC_COLLATE=C ls，该命令不会修改系统全局设置。
• 管道传递给sort处理时：加C locale前缀即可，例如ls | LC_ALL=C sort；如果需要适配未补零的数字序号（避免出现10排在2前面的问题），可以直接使用ls内置的版本自然排序参数ls -v，或者管道给sort时加版本排序参数ls | sort -V，这两种方式都能正确处理带序号、带后缀的文件名排序，更贴合日常文件管理的排序直觉。
• 长期全局生效：将export LC_COLLATE=C写入当前使用的shell配置文件（bash对应~/.bashrc，zsh对应~/.zshrc），执行source对应配置文件后，所有依赖系统排序规则的命令都会默认使用ASCII逐字节排序。

内容的提问来源于stack exchange，提问作者R.30