文本乱码与换行错误怎么修：先辨认编码，再另存副本
一份中文配置文件在甲电脑正常、乙电脑乱码，或者一个脚本在 Windows 编辑后无法在 Linux 运行，不一定是文件内容写错。编码和换行是两个不同层面：前者决定字节如何解释成文字，后者决定每行在哪里结束。
本文处理普通文本和源码，不适用于 Word、PDF、图片或数据库文件。先复制原件，再操作副本；不要对整个资料目录盲目批量转换。
先区分乱码、缺字和换行异常
如果只有少数字符显示方框，可能是字体缺少字形；换一种支持该文字的字体再判断。如果大量中文变成不相关字符，才重点检查编码。如果文字正常，但脚本提示解释器路径包含奇怪的 ^M，则应检查行尾。
UTF-8 是字符编码，LF 与 CRLF 是换行方式。把 CRLF 改成 LF 不会自动恢复乱码，把文件另存为 UTF-8 也不保证解决脚本行尾问题。把两个变量分别检查，才能看出是哪一步产生了变化。
乱码时先“用编码重新打开”
以 VS Code 为例，可以从状态栏的编码入口选择重新打开或另存编码。二者方向不同：重新打开是换一种方式解释已有字节；另存则会按当前理解把文字写回文件。VS Code 基本编辑文档
推荐顺序是：
- 保留只读原件，给副本改一个明确的文件名。
- 询问文件生成程序使用的编码，不要只靠自动猜测。
- 在副本中尝试“使用编码重新打开”，检查标题、正文、标点及生僻字。
- 确认显示正确后，再另存为目标程序要求的编码。
- 关闭并重新打开新文件，同时用实际消费它的程序验证。
如果已经在乱码状态下覆盖保存，某些信息可能不可逆地丢失。连续切换编码并不能凭空恢复缺失字节，应优先找原件、版本历史或备份。
UTF-8 是否带 BOM，要看接收程序
BOM 是文件开头的一种标记，不是“高清版 UTF-8”。现代跨平台工具经常使用不带 BOM 的 UTF-8，但旧软件可能依靠标记识别编码，部分程序又会把标记误当成正文。
特别注意 Windows PowerShell 5.1 与较新 PowerShell 的默认编码行为并不相同。不能因为命令名一样，就认为重定向生成的文件字节也一样。Microsoft 编码说明
因此，给工具准备配置文件时应遵循该工具文档，而不是在整个电脑上统一强制某种设置。对有签名或校验值的文件，任何转换都会改变字节，应重新验证，不能沿用旧校验结论。
跨平台项目把换行规则写清楚
对于自己维护的 Git 项目，可在审查已有规则后用 .gitattributes 表达文件类型的行尾需求。例如：
*.sh text eol=lf
*.bat text eol=crlf
这是项目规则示例，不是让你覆盖现有文件。Git 的文本属性会影响检入和检出时的换行处理；已有文件若需要规范化，应在干净工作区单独处理，检查差异后再提交，不与功能修改混在一起。Git 属性文档
怎样判断修复真的完成
不要只看编辑器“终于不乱码”。还要确认：原件没有被覆盖；新文件关闭重开后仍正确；接收程序能够读入；内容差异只有预期变更；脚本在目标平台的测试环境运行正常。
处理一份文件成功后，再决定是否推广到同类文件。批量操作前抽取不同年代、不同来源的样本，避免把同一个猜测应用到所有历史资料。真正省时间的做法，是保留回退路线，而不是一次转换得越多越好。