打开VS Code，编辑右下角状态栏显示“UTF-8”。器编你敲下“你好”，编辑保存，器编关闭。编辑第二天用记事本打开，器编乱码。编辑这种事我遇到过不下十次，器编每次都想砸键盘。编辑

问题不在你，器编在编辑器怎么“理解”你敲下的编辑每个字符。计算机只认数字，器编字符得先编码成数字才能存进硬盘。编辑UTF-8、器编GBK、编辑Latin-1，这些名字背后是一套套映射规则。编辑器打开文件时，它得猜——或者你告诉它——这个文件用的是哪套规则。猜错了，乱码就来了。

VS Code默认UTF-8，这没什么好说的，现代开发环境基本都这样。但Windows上的记事本，直到2019年之前，默认编码还是ANSI（中文系统下就是GBK）。你用记事本存一个“你好”，它按GBK编码，两个字节。VS Code按UTF-8去读，发现这两个字节不符合UTF-8的编码规则，直接给你显示成“浣犲ソ”——典型的UTF-8误读GBK。

反过来更常见。你在VS Code里写了个Python脚本，文件头有中文注释，存成UTF-8。发给同事，他用PyCharm打开，没问题。但要是发给一个用Windows记事本的人，他打开就是乱码。因为记事本老版本会按系统默认编码去猜，猜错了就乱。

我自己的习惯是：所有文件一律UTF-8，不带BOM。BOM是字节顺序标记，Windows上有些编辑器喜欢在UTF-8文件开头加三个字节EF BB BF。这三个字节在Linux下跑脚本会直接报错，Python解释器不认。所以跨平台项目里，带BOM的UTF-8是个坑。

那怎么判断一个文件到底是什么编码？Linux下用file -i filename，输出里会写charset。Windows下可以用Notepad++，右下角直接显示。VS Code底部状态栏也能点，点一下会弹出“通过编码重新打开”，你选GBK试试，乱码可能就正常了。反过来，如果文件本来就是UTF-8，你误选了GBK，正常文字也会变乱码。

有个细节很多人没注意：VS Code的“通过编码保存”和“通过编码重新打开”是两回事。前者改变文件实际存储的编码，后者只是改变当前视图的解读方式。你要是选错了保存，文件就真变了，撤销不回来。我有次手贱，把一个UTF-8的配置文件用GBK保存，结果整个项目启动报错，排查了半小时才想起来是编码问题。

再讲个具体的。Python 3源码文件默认UTF-8，你不需要在文件头写# -*- coding: utf-8 -*-，写了也不报错，但没必要。Python 2才需要那行声明。现在还有人从老项目复制粘贴，把声明带进Python 3文件里，看着别扭，删掉就行。

HTML文件里，<meta charset="UTF-8">要放在<head>最前面。浏览器解析到这一行之前，如果已经遇到了中文，它可能按默认编码（通常是Windows-1252或GBK）去猜，猜错了页面就乱。我见过有人把meta标签放在<title>后面，结果标题栏中文乱码，页面内容却正常——就是因为浏览器先解析了标题，那时候还没看到charset声明。

数据库连接也有编码问题。MySQL的character_set_server如果是latin1，你往表里插中文，存进去就是问号。得改成utf8mb4，注意不是utf8——MySQL的“utf8”只支持最多3字节，emoji是4字节，存不进去。utf8mb4才是完整的UTF-8。这个坑我踩过，一个用户昵称里带了个emoji，插入直接报错，查了半天才定位到字符集。

编辑器编码这事，说大不大，说小不小。平时写代码没事，一到跨平台、跨语言、跨工具协作，乱码就冒出来。最稳妥的做法：项目根目录放一个.editorconfig文件，写上charset = utf-8，大部分编辑器都认。再配合Git的core.autocrlf设置，基本能避免绝大多数编码事故。

最后说个观察：很多人遇到乱码第一反应是“文件坏了”，其实文件没坏，只是读的方式不对。换个编码重新打开，内容原封不动。编码不是加密，它只是翻译规则。你换本字典，同一个词就认识了。