Sublime Text 中匹配整行恰好5个字符应使用 ^[^\r\n]{5}$，而非 .{5} 或 ^.{5}$，以避免换行符干扰和跨行匹配；Unicode字符、空格、制表符均计入长度，需注意行尾符和空白处理。
匹配固定长度的字符串（如 5 个字符）
Sublime Text 的正则引擎基于 PCRE，支持 {n} 量词，直接用 ^.{5}$ 即可匹配整行恰好 5 个字符（不含换行符）。注意：默认情况下 . 不匹配换行符，所以这个模式只对单行有效。
常见错误是写成 .{5}（缺边界锚点），结果会匹配任意位置连续的 5 个字符，比如在 hello world 中匹配到 hello 和 world 两处，而非整行判定。
- 要严格限定整行长度，必须加
^和$ - 如果目标含中文、emoji 或其他 Unicode 字符，
.仍能正常计数（Sublime 默认启用 UTF-8 模式） - 空格和制表符也被计入长度，需确认是否属于“有效字符”范围
排除换行符和不可见字符的干扰
实际文本中常混有尾部空格、BOM、或 CRLF 行结束符，导致看似“5 字符”的行实际长度超标。此时不能只依赖 ^.{5}$，得先清理或显式排除。
推荐用 ^[^\r\n]{5}$ 替代 ^.{5}$，明确禁止匹配回车 \r 和换行 \n —— 这能防止 Windows 行尾 \r\n 被误算进长度，也避免跨行匹配。
-
[^\r\n]比.更安全，尤其处理混合换行符（CRLF/LF）的文件时 - 若需忽略行首/行尾空白，改用
^\s*(\S{5})\s*$并开启「match whole line」再替换为$1 - Sublime 的「Find → Find in Files」不自动识别
\R（通用换行符），别用它
匹配长度在范围内的字符串（如 3–7 个字符）
用 {m,n} 即可，例如 ^[^\r\n]{3,7}$ 匹配整行 3 到 7 个非换行字符。注意：这不是“至少 3 且至多 7”，而是“恰好落在该区间”，仍需 ^ 和 $ 锚定。
容易踩的坑是混淆贪婪与边界——比如 .{3,7} 在 abcdefgh 中会匹配前 7 个字符（贪婪），但你可能只想找那些“整行就这么多”的内容。
- 范围量词默认贪婪，但加锚点后效果等同于精确约束
- 若需排除纯空白行，组合使用
^\s*[^\s\r\n]\S{2,6}\s*$（即非空白字符打头，总长 3–7） - Sublime 不支持
\X（Unicode 字形单元），所以 emoji 组合如 ?? 会被当作多个码点计数
替换时保留原始长度的场景（如补零、截断）
正则本身不计算长度，但可通过捕获组 + 替换逻辑间接实现。例如把不足 5 位的数字左补零：^(\d{1,4})$ → 0000$1，再用列选或正则二次替换删多余前导零。
更稳妥的做法是分两步：先匹配目标行，再用 Sublime 的「Edit → Permute Lines → Reverse」等辅助操作，或借助 Python 插件执行 str.zfill(5)。纯正则无法动态补零，因为缺乏算术能力。
- 不要试图用
(? 类断言做长度判断——Sublime 对可变宽度 lookbehind 支持有限，易报错lookbehind assertion is not fixed length - 批量处理时，优先考虑「Find All → Copy as Results」导出后再用脚本处理，比硬套正则更可靠
- 真正需要长度感知逻辑时，正则只是第一道筛选，后续一定得靠外部工具或插件兜底
Sublime 的正则强大但有边界：它适合快速筛选和简单替换，一旦涉及动态长度计算、Unicode 字形计数或上下文感知，就得切换思路——不是正则写得不够巧，而是设计上就不该让它干这事。
