sublime text 在 gbk/euc-kr 编码下光标错位、列选择偏移等问题，根本原因是其默认按 utf-8 解析字节流，将多字节字符误拆为多个伪字符；需正确识别编码、禁用干扰插件、关闭软换行、使用支持 gbk 的等宽字体，并避免 utf-8 正则引擎与 gbk 字节不匹配。
Sublime Text 在 GBK 或 EUC-KR 编码下光标不跟随、列选择错位、Ctrl+Shift+L 拆行后光标歪斜——根本不是编码本身的问题，而是 Sublime 默认按 UTF-8 解析字节流，导致多字节字符被拆成多个“伪字符”，光标定位失准。
为什么 GBK 文件里 Alt+拖拽列选会横向偏移
Sublime 的列编辑（Alt+拖拽）底层按 Unicode 码点数定位，但 GBK 中一个汉字占 2 字节、对应 1 个码点；而 Sublime 若未正确识别编码，会把这 2 字节当作两个独立 Latin-1 字符处理，结果光标在视觉第 3 列的位置，实际落在第 6 字节处。
- 确认当前文件编码：状态栏右下角显示
GBK或EUC-KR，而非UTF-8；若显示Undefined，先用File → Reopen with Encoding → GBK强制重载 - 禁用可能导致解析混乱的插件：如
IMESupport在非 UTF-8 文件中常引发光标抖动，临时禁用可验证是否改善 - 避免混用软换行：
View → Word Wrap必须关闭，否则逻辑行与物理行错位，Alt+拖拽会跨行断裂
Ctrl+Shift+L 拆行后光标停在汉字中间怎么办
这不是光标“卡住”，而是 Sublime 把 GBK 双字节字符误判为两个可停靠位置。例如“你好”被当成 \xB7\xC3\xC4\xE3 四个字节，Ctrl+Shift+L 在每个换行符前加光标时，若选区末尾含未闭合的 GBK 字节（如只选了“你好”的前一个字节），光标就会落在非法字节边界上。
- 操作前先确保选区完整：用
Ctrl+L逐行选中（而非鼠标拖选），再按Ctrl+Shift+L——Ctrl+L基于行号而非字节，不受编码影响 - 慎用双击选词：
Ctrl+D在 GBK 下可能因word_separators配置错乱匹配失败，优先用Ctrl+Shift+P → Split Selection into Lines替代 - 如果已出现错位光标，按
Esc清除所有光标，再用Ctrl+→（而非鼠标）跳过整个汉字，避免停在字节缝里
字体设置对 GBK 排版的影响比想象中更大
即使编码识别正确，若字体不支持 GBK 字符集或非等宽，Sublime 仍会按 ASCII 宽度渲染汉字，导致缩进线偏移、列选择视觉错位。这不是主题问题，是字体度量（font metrics）失效。
- 必须使用明确声明 GBK 支持的等宽字体，例如
"font_face": "YaHei Consolas Hybrid"或"font_face": "Source Code Pro"（后者需额外安装 GBK 补丁版本） - 禁止使用系统 UI 字体（如
"Segoe UI"、"PingFang SC"），它们虽能显示汉字，但字符宽度不一致，Alt+拖拽必然错位 - 检查
"font_options"是否含["no_round"] 或"subpixel_antialias"，这些选项在 GBK 下易放大渲染误差，建议清空该配置项
正则替换在 GBK 文件中失效的隐藏原因
在 GBK 编码下启用正则（Alt+R）时，如果模式含中文字符（如 函数），Sublime 实际按 UTF-8 字节序列编译正则引擎——而 GBK 的“函数”是 \xBA\xAF\xCA\xFD，UTF-8 是 \xE5\x87\xBD\xE6\x95\xB0，两者完全不匹配。
- 解决方案只有两个：要么将文件转为 UTF-8（
File → Save with Encoding → UTF-8），要么在正则中用十六进制字节匹配，例如写\xBA\xAF\xCA\xFD替代函数 - 批量处理前务必执行
Ctrl+Shift+P → Convert Line Endings → Unix，Windows 的\r\n在 GBK 下可能被截断为孤立\r字节，干扰正则锚点^/$ - 不要依赖
Alt+F3全文匹配中文——它底层调用的是 UTF-8 正则引擎，GBK 下命中率极低；改用Ctrl+F → In Selection → Find All，先人工框定范围再操作
最易被忽略的一点：Sublime 的编码识别是“一次性快照”，文件在外部被其他程序修改并保存为不同编码（比如用记事本另存为 ANSI），Sublime 不会自动重检测——此时状态栏仍显示旧编码，但实际内容已损坏，所有光标操作都会不可预测地偏移。遇到异常，第一反应不是调设置，而是 File → Reopen with Encoding 重新指定。
