企业官网建设流程全解析

1. 这不是报错，是编码世界的“语言不通”现场

你刚打开一个 Python 脚本，或者读取一个配置文件、日志、网页源码，控制台突然炸出一行红字：UnicodeDecodeError: 'utf-8' codec can't decode byte 0xff in position 0: invalid start byte。别慌——这不是你的代码写错了，也不是 Python 坏了，更不是硬盘出问题了。这是典型的编码协商失败，就像你用普通话跟一位只会粤语的老师傅问路，双方都认真说话，但谁也听不懂对方在说什么。

这个错误的核心关键词非常明确：utf-8、codec、decode、byte、UnicodeDecodeError。它高频出现在 VS Code 编辑器里打开旧项目、用open()读取 Windows 系统生成的文本、解析爬虫抓回来的 HTML 页面、处理 Excel 导出的 CSV、甚至加载.py文件本身时。尤其当你看到position 0（位置0）这个提示，基本可以断定：文件开头就“撞墙”了——比如第一个字节是0xff，而 UTF-8 规则里，0xff根本不合法；再比如0xeb，它单独出现是无效续字节，必须紧跟在某个特定起始字节之后才成立。

我做过上百个 Python 项目，从嵌入式日志分析到金融数据清洗，几乎每个团队都会在入职第一周被这个错误“教育”一次。它不像语法错误那样一眼能改，也不像空指针那样有明确路径可查。它藏在字节底层，游走在操作系统、编辑器、Python 解释器、文件保存习惯之间。很多人试过加encoding='gbk'或'latin-1'临时绕过，结果后续读到中文时又乱码；也有人直接errors='ignore'强行吞掉错误，最后发现关键字段全丢了。这些都不是解法，只是把问题埋得更深。

这篇文章不是讲 Unicode 理论的教科书，而是我十年一线开发中整理出的一套可立即上手、带诊断逻辑、含真实案例、覆盖全场景的实战排查手册。它适用于：刚接触 Python 的学生、用 VS Code 写脚本的运维、处理历史数据的 BI 工程师、调试爬虫的前端转岗者、甚至需要读取客户发来 Excel 的销售支持人员。只要你需要读文件、解析文本、对接 API，你就绕不开字节与字符的转换。下面所有内容，我都用真实项目中的截图、命令、输出和踩坑记录还原，不讲虚的，只给能抄、能改、能验证的方案。

2. 为什么0xff在位置 0 就致命？——UTF-8 编码规则的硬约束

要真正解决这个错误，你必须理解 UTF-8 不是“万能编码”，它是一套有严格字节结构的规则。UnicodeDecodeError: 'utf-8' codec can't decode byte 0xff in position 0这句话里的每一个词，都在告诉你发生了什么：

• 'utf-8' codec：Python 正在用 UTF-8 解码器尝试解读一段字节流；
• can't decode byte 0xff：解码器遇到了一个它完全不认识的字节0xff（即十进制 255）；
• in position 0：这个字节位于整个字节流的最开头，也就是文件第一个字节；
• invalid start byte：0xff不符合 UTF-8 对“起始字节”的任何定义。

那么，UTF-8 允许哪些字节作为“起始字节”？我们不用背标准文档，直接看一张实操级字节分类表（这是我写在笔记本第一页、贴在工位上的速查卡）：

重点来了：0xff就属于最后一行——永久禁止字节。它在 UTF-8 规范里没有任何意义，永远不能出现在合法 UTF-8 文本中。所以当 Python 解码器在 position 0 看到0xff，它连“试试看”都不做，直接抛异常。这不是宽容度问题，是协议层面的拒绝。

那0xff是从哪来的？最常见的三个真实来源：

1. UTF-16 或 UTF-32 的 BOM（字节序标记）：
   Windows 记事本保存为“Unicode”（实际是 UTF-16 LE）时，会在文件开头写入0xff 0xfe；保存为“UTF-8”时，有时会错误地加上0xef 0xbb 0xbf（UTF-8 BOM），但如果你用其他工具（如 Notepad++）误操作，可能残留0xff。我遇到过客户发来的“UTF-8”配置文件，实际是记事本用“Unicode”格式保存的，开头就是0xff 0xfe，Python 一读就崩。

2. GBK/GB2312 编码的中文文件：
   GBK 中，“啊”的编码是0xb0 0xa1，这两个字节单独看，在 UTF-8 里：0xb0属于0x80–0xBF区间（续字节），0xa1同样是续字节。但它们前面没有合法起始字节，所以 Python 解码器在 position 0 看到0xb0，判定为“invalid continuation byte”——这正是热搜里0xeb in position 0: invalid continuation byte的由来。0xeb是 GBK 中“烟”字的首字节，同样属于续字节区间。

3. 文件被二进制写入污染：
   比如用open('log.txt', 'wb')写日志，但中间混入了struct.pack('i', 123)这样的二进制数据，或用pickle.dump()直接写进文本文件。再比如某些老旧的 C 程序导出日志时，用\x00做分隔符，而\x00在 UTF-8 中虽合法（对应空字符），但若紧邻0xff，就可能触发边界判断异常。

提示：不要靠猜。用xxd或hexdump看真实字节，比任何 IDE 预览都准。在终端执行xxd -g1 -c16 your_file.txt | head -n 3，前两行就能看到开头 32 个字节的十六进制值。这才是诊断的第一步。

我曾帮一个电商团队处理三年前的订单 CSV，他们一直用encoding='utf-8'报错，加errors='replace'后中文全变 。用xxd一看，开头是ff fe 3c 00 68 00 74 00 6d 00 6c 00——典型的 UTF-16 LE BOM + HTML 标签。改成encoding='utf-16'一读就通。没这一步字节检查，你可能花两天调编码参数，却始终绕不开根本原因。

3. 四步定位法：从 VS Code 到服务器，精准锁定编码源头

很多开发者卡在第一步：不知道错误来自哪。VS Code 里打开文件显示正常，但 Python 脚本一读就崩；本地跑得好好的，部署到 Linux 服务器就报0xeb；甚至同一个文件，用pandas.read_csv()没问题，open()就报错。这是因为编码问题从来不是单一环节的问题，而是“生产-传输-消费”整条链路的协同失效。我总结了一套四步定位法，已在 12 个不同技术栈项目中验证有效。

3.1 第一步：确认文件本身的原始字节（脱离编辑器干扰）

VS Code、PyCharm 等编辑器会自动猜测编码并渲染，给你“看起来正常”的假象。但 Python 的open()函数读的是原始字节，不是渲染结果。所以必须绕过编辑器，直面字节。

实操命令（跨平台）：

# macOS / Linux xxd -g1 -c16 your_file.txt | head -n 2 # Windows（PowerShell） Format-Hex -Path your_file.txt -Count 32

看输出的前几个字节。对照上一节的表格，快速归类：

• 若开头是ef bb bf→ UTF-8 BOM（合法，但部分老系统不认）；
• 若开头是ff fe或fe ff→ UTF-16 LE/BE；
• 若开头是ff fe 00 00或00 00 fe ff→ UTF-32；
• 若开头是b0 a1、c4 e3、d2 bb等0x80–0xff范围内成对出现的字节 → 极大概率是 GBK；
• 若开头是00、ff、fe单独出现，且后续字节无规律 → 二进制污染或损坏。

注意：head -n 2只看前两行，因为有些大文件 BOM 在开头，但正文全是中文，xxd输出太长反而干扰判断。我习惯先看前 16 字节，足够定位。

真实案例：某次排查一个settings.json报错，VS Code 显示完美，xxd却显示ff fe 7b 00 0a 00 20 00 20 00 20 00 22 00 6e 00。立刻明白：这是 UTF-16 LE 存储的 JSON，JSON 解析器当然不认识0xff 0xfe。解决方案不是改 Python 代码，而是让运维重新用 UTF-8 保存该文件——源头治理，一劳永逸。

3.2 第二步：检查 Python 脚本的读取方式与上下文

同一个文件，不同读法结果天差地别。常见错误模式：

• open()忘记指定encoding：Python 3 默认用locale.getpreferredencoding()，Windows 上通常是cp936（GBK），Linux/macOS 是UTF-8。所以同一脚本在 Windows 读 GBK 文件不报错，在 Linux 就崩。
• pandas.read_csv()默认encoding='utf-8'，但没设encoding_errors：新版 pandas 支持encoding_errors='replace'，但老版本会直接抛异常。
• requests.get().text自动解码，但response.content是原始字节：爬虫中，r.text用r.encoding解码，而r.encoding可能被<meta charset="gbk">错误设置，导致r.text乱码；但r.content是原始字节，你可以用r.content.decode('gbk')手动指定。

安全读取模板（推荐直接复制）：

# 方案1：明确指定编码，带 fallback def safe_read_text(filepath, primary_encoding='utf-8', fallback_encodings=['gbk', 'latin-1']): for enc in [primary_encoding] + fallback_encodings: try: with open(filepath, 'r', encoding=enc) as f: return f.read() except UnicodeDecodeError: continue raise ValueError(f"Cannot decode {filepath} with any of { [primary_encoding] + fallback_encodings }") # 方案2：先读字节，再尝试解码（更可控） def read_with_detection(filepath): with open(filepath, 'rb') as f: raw = f.read(1000) # 读前1KB足够检测 # 用 chardet 检测（需 pip install chardet） import chardet detected = chardet.detect(raw) encoding = detected['encoding'] or 'utf-8' confidence = detected['confidence'] if confidence < 0.6: print(f"Low confidence ({confidence:.2f}) for {encoding}, using utf-8 fallback") encoding = 'utf-8' with open(filepath, 'r', encoding=encoding) as f: return f.read()

实操心得：chardet在短文本（<100 字）上准确率暴跌，所以read_with_detection里我限制读1000字节，而非全文。另外，latin-1是终极 fallback——它能解码任意字节（0x00–0xff 映射到 Unicode 0x0000–0x00ff），不会抛错，但中文会变成方块。适合先保流程，再人工校验。

3.3 第三步：检查编辑器与 IDE 的默认编码设置

VS Code 是重灾区。它的设置项分散在三处，且相互影响：

• 全局设置：Files: Encoding（默认utf8）；
• 工作区设置：.vscode/settings.json中的"files.encoding"；
• 文件关联设置："files.encoding": "gbk"写在"*.csv"下，只对 CSV 生效。

更隐蔽的是：VS Code 会根据文件内容自动猜测编码。如果你用 GBK 保存了一个文件，VS Code 可能识别为GBK并用它渲染；但当你右键“Reopen with Encoding”选UTF-8，它会强制用 UTF-8 渲染——此时你看到的“乱码”，其实是正确解码结果，而之前“正常”的显示，反而是错误的。

VS Code 终极修复步骤：

1. 打开报错文件；
2. 右下角状态栏点击当前编码（如UTF-8）；
3. 选择Reopen with Encoding→GBK（或GB2312）；
4. 如果中文显示正常，说明文件确实是 GBK；
5. 再点击编码 →Save with Encoding→UTF-8；
6. 保存后，Python 就能用encoding='utf-8'读了。

注意：第 5 步“Save with Encoding”是转码保存，不是另存为。它会把 GBK 字节流，按 GBK 规则解码成 Unicode 字符，再用 UTF-8 规则编码回字节流。这是最干净的解决方案，避免在代码里硬编码gbk。

3.4 第四步：检查运行环境与系统 locale

Linux 服务器上，locale设置直接影响 Python 默认编码：

# 查看当前 locale locale # 典型输出： # LANG=en_US.UTF-8 # LC_CTYPE="en_US.UTF-8" # ... # 如果是： # LANG=zh_CN.GBK # 则 Python open() 默认用 GBK，读 UTF-8 文件就崩

解决方案不是改服务器 locale（可能影响其他服务），而是在 Python 脚本开头强制指定：

import sys import locale # 强制 Python 使用 UTF-8（推荐放在脚本最顶部） if sys.platform == "linux": locale.setlocale(locale.LC_ALL, 'C.UTF-8') # 或更简单：确保 open() 默认用 utf-8 import io io.TextIOWrapper = lambda *args, **kwargs: io.TextIOWrapper(*args, encoding='utf-8', **kwargs)

但更推荐在启动脚本中设置环境变量：

# 启动前 export PYTHONIOENCODING=utf-8 export LANG=C.UTF-8 python your_script.py

实操心得：我在阿里云 ECS 上部署一个日志分析服务，客户环境LANG=zh_CN.GB18030，导致subprocess.run(['cat', 'log.txt'])的stdout默认用 GB18030 解码，而日志是 UTF-8。加encoding='utf-8'参数后解决。记住：环境变量 > Python 设置 > 代码参数，优先级要清楚。

4. 全场景解决方案库：从 HTML 到 Redis，覆盖 95% 的报错现场

光知道原理和定位不够，你还需要一套“开箱即用”的解决方案库。我把过去十年遇到的真实场景，按发生频率排序，给出每种场景的根因、验证方法、一行修复代码、以及为什么这么修。不讲废话，直接上干货。

4.1 场景1：VS Code 打开.py文件报错0xff in position 0

根因：该.py文件是用 Windows 记事本“另存为”→“编码”选了“Unicode”（即 UTF-16 LE）保存的。

验证：xxd your_script.py | head -n 1→ 输出00000000: ff fe 23 00 21 00 2f 00 75 00 73 00 72 00 2f 00 ..#.!./.u.s.r./.

修复：

# Linux/macOS（用 iconv 转码） iconv -f UTF-16LE -t UTF-8 your_script.py -o your_script_fixed.py # Windows（PowerShell） Get-Content your_script.py -Encoding Unicode | Set-Content your_script_fixed.py -Encoding UTF8

为什么：iconv是 Unix 系统编码转换的黄金标准，-f UTF-16LE明确告诉它输入是小端 UTF-16，-t UTF-8指定输出目标。比任何 Python 脚本都快、都稳。PowerShell 的Get-Content-Encoding Unicode等价于 UTF-16，Set-Content-Encoding UTF8是 UTF-8。

4.2 场景2：读取爬虫抓取的 HTML，报0xeb in position 0: invalid continuation byte

根因：目标网站<meta charset="gbk">，但requests未正确识别，r.text用 UTF-8 解码失败；或r.content直接传给BeautifulSoup时未指定from_encoding。

验证：print(r.content[:20])→ 输出b'\xeb\xed\xc0\xf6...'（GBK 中文的典型字节）；print(r.encoding)→utf-8（错误）。

修复：

# 方案A：强制用 GBK 解码 content from bs4 import BeautifulSoup soup = BeautifulSoup(r.content, 'html.parser', from_encoding='gbk') # 方案B：手动解码再传 html_text = r.content.decode('gbk') soup = BeautifulSoup(html_text, 'html.parser') # 方案C：让 requests 正确识别（推荐） r = requests.get(url) r.encoding = r.apparent_encoding # chardet 检测结果，通常为 gbk soup = BeautifulSoup(r.text, 'html.parser')

为什么：r.apparent_encoding调用chardet分析r.content，比r.encoding（来自 HTTP header 或 meta）更可靠。from_encoding参数是BeautifulSoup的专属机制，专为content（字节）设计，比先解码再传更高效。

4.3 场景3：Pandas 读 CSV 报错0xff in position 0

根因：CSV 文件由 Excel 保存，选择了“UTF-8 with BOM”（Windows Excel 默认），开头0xef 0xbb 0xbf被 pandas 当作普通字符读入。

验证：xxd your_data.csv | head -n 1→00000000: ef bb bf ...

修复：

# pandas 1.3+ 支持 encoding='utf-8-sig'，自动 strip BOM df = pd.read_csv('your_data.csv', encoding='utf-8-sig') # 老版本 pandas（<1.3） with open('your_data.csv', 'r', encoding='utf-8-sig') as f: df = pd.read_csv(f)

为什么：utf-8-sig是 Python 的特殊编码名，它在解码时自动跳过开头的0xef 0xbb 0xbf，且编码时自动加上。比encoding='utf-8'+skiprows=1更安全，因为 BOM 只在开头，不会影响数据行。

4.4 场景4：Redisson（Java）连接报codec can't decode byte，但 Python 客户端正常

根因：Redisson 默认使用StringCodec，其decode方法假设 value 是 UTF-8 字符串；但 Python 客户端用redis-py存入时用了encoding='latin-1'或未指定 encoding，导致 value 是二进制字节。

验证：用redis-cli查看 key：get your_key→ 返回"\\xff\\xfe..."或乱码；type your_key→string。

修复：

// Java 端：改用 ByteArrayCodec，或自定义 Codec Config config = new Config(); config.useSingleServer().setAddress("redis://127.0.0.1:6379"); // 方案A：用 ByteArrayCodec（推荐，通用） config.setCodec(new ByteArrayCodec()); // 方案B：自定义 StringCodec，容错解码 config.setCodec(new StringCodec() { @Override public String decode(ByteBuf buf) { try { return super.decode(buf); } catch (Exception e) { // fallback to latin-1 byte[] bytes = new byte[buf.readableBytes()]; buf.getBytes(buf.readerIndex(), bytes); return new String(bytes, StandardCharsets.ISO_8859_1); } } });

为什么：ByteArrayCodec把所有 value 当作byte[]处理，不尝试解码，彻底规避问题。StringCodec的decode是强契约，必须返回String，一旦字节非法就崩。而ISO_8859_1（即latin-1）能映射任意字节，是二进制兼容的兜底方案。

4.5 场景5：Docker 容器内 Python 读文件报错，宿主机正常

根因：Docker 镜像基础镜像（如python:3.9-slim）的locale是C，不支持 UTF-8；或挂载卷时文件权限/编码被修改。

验证：容器内执行locale→LANG=C；xxd /mounted/file.txt | head -n 1→ 字节与宿主机一致，但open()崩。

修复：

# Dockerfile 中添加 FROM python:3.9-slim ENV LANG=C.UTF-8 ENV LC_ALL=C.UTF-8 # 或更彻底 RUN apt-get update && apt-get install -y locales && \ locale-gen C.UTF-8 && \ update-locale LANG=C.UTF-8 LC_ALL=C.UTF-8

为什么：C.UTF-8是 glibc 提供的轻量级 UTF-8 locale，比en_US.UTF-8依赖少，启动快。slim镜像默认不装 locales 包，locale-gen是必须步骤。单纯ENV不生效，必须locale-gen。

5. 常见问题与排查技巧实录：那些年我们踩过的坑

理论和方案都给了，但真实世界永远比文档复杂。以下是我在客户现场、Code Review、深夜 on-call 时，反复遇到的“经典陷阱”，附带我的排查笔记和一句忠告。

5.1 问题：errors='ignore'后中文全变 ，但程序不报错，上线后才发现数据丢失

排查过程：
客户说“加了errors='ignore'就不报错了”，我让他们print(repr(text[:50]))，输出'\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd'。`` 的 Unicode 码位是U+FFFD，errors='ignore'实际是errors='replace'的别名（Python 文档有说明），它把非法字节替换成U+FFFD。

根治方案：
永远不要用errors='ignore'处理业务数据。改用errors='surrogateescape'：

# 它把非法字节转成 surrogate code points（U+DC00–U+DCFF），可逆！ text = open('file.txt', 'r', encoding='utf-8', errors='surrogateescape').read() # 后续要写回时： with open('fixed.txt', 'w', encoding='utf-8', errors='surrogateescape') as f: f.write(text)

这样，0xff会被转成\udcff，写回时再转回0xff，全程无损。适合做编码清洗管道。

忠告：errors='ignore'是“假装看不见”，errors='replace'是“画个叉”，只有surrogateescape是“记下来，以后还”。生产环境请用后者。

5.2 问题：VS Code 显示正常，但git diff显示一堆^@和乱码

排查过程：
git diff输出^@是0x00字节的显示形式。xxd一看，文件里真有0x00。根源是：该文件被二进制程序（如sqlite3导出）写入，混入了0x00。VS Code 渲染时跳过0x00，所以“看起来正常”；但git按纯文本处理，0x00是非法字符，diff 就崩。

根治方案：
这不是编码问题，是文件类型错误。.txt后缀不代表它是文本文件。用file命令确认：

file your_file.txt # 输出：your_file.txt: data ← 不是 text！ # 输出：your_file.txt: UTF-8 Unicode text ← 才是 text

如果是data，立刻停止用文本编辑器打开，改用hexedit或xxd -r处理。

忠告：file命令是 Linux/macOS 的瑞士军刀，比任何 IDE 的“文件类型识别”都准。养成file xxx习惯，省去 80% 的误判。

5.3 问题：<!doctype html><html lang="zh-cn">开头的文件，Python 读取报0xff错误

排查过程：
这个 HTML 片段本身是纯 ASCII，不可能有0xff。xxd一看，开头是ff fe 3c 00 21 00 64 00 6f 00 63 00 74 00 79 00——又是 UTF-16 LE！根源是：前端工程师用 Windows 记事本保存 HTML，选了“Unicode”而非“UTF-8”。

根治方案：
在 CI/CD 流水线加一步检查：

# .gitlab-ci.yml 或 GitHub Actions - name: Check HTML encoding run: | if xxd -g1 index.html | head -n1 | grep -q "ff fe"; then echo "ERROR: index.html is UTF-16, not UTF-8" exit 1 fi

或用iconv -f UTF-16 -t UTF-8 index.html -o index_fixed.html自动修复。

忠告：HTML 文件必须是 UTF-8 无 BOM。W3C 标准明文规定，<meta charset="utf-8">的前提是文件本身是 UTF-8。编辑器设置比代码更重要。

5.4 问题：同一份 CSV，Excel 打开正常，pandas 读取报0xeb

排查过程：
Excel 能打开，说明它用了自己的编码探测逻辑（通常很准）；pandas 默认utf-8失败。xxd发现开头是b0 a1 c4 e3（GBK “啊你好”）。但chardet.detect()返回{'encoding': 'utf-8', 'confidence': 0.99}——因为前几个字节b0 a1在 UTF-8 中是非法，但chardet可能采样了后面纯 ASCII 的 header 行。

根治方案：
强制指定encoding，或用pd.read_csv(..., encoding='gbk', encoding_errors='replace')。更优解是：让数据源统一用 UTF-8。

# 读取后转存为标准 UTF-8 df = pd.read_csv('old.csv', encoding='gbk') df.to_csv('new.csv', encoding='utf-8-sig', index=False)

utf-8-sig确保 Excel 能正确识别。

忠告：数据管道的编码标准，应该写在团队 Wiki 第一页：“所有文本文件，必须 UTF-8 无 BOM”。技术债，越早清理，成本越低。

5.5 问题：eclipse pom.xml <?xml version="1.0" encoding="utf-8"?>报错

排查过程：
XML 声明encoding="utf-8"是提示解析器用 UTF-8 解码，但文件实际是 GBK。Eclipse 的 XML 解析器严格遵守声明，一读就崩。xxd确认开头是b0 a1。

根治方案：
两种选择：

1. 改文件：用iconv -f gbk -t utf-8 pom.xml -o pom_fixed.xml；
2. 改声明：把encoding="utf-8"改成encoding="gbk"（不推荐，违背标准）。

忠告：XML 的encoding属性是契约，不是建议。它必须与文件实际编码一致。宁可改文件，勿改声明。

6. 预防胜于治疗：建立团队级编码规范与自动化检查

解决了眼前问题，更要防止它再次发生。我在三个不同规模的团队（10人初创、200人 SaaS、500人金融）推行过以下实践，效果显著：编码相关 bug 下降 70%，新人 onboarding 时间缩短 40%。

6.1 编辑器强制配置（VS Code）

在团队.vscode/settings.json中统一配置：

{ "files.encoding": "utf8", "files.autoGuessEncoding": false, "files.trimTrailingWhitespace": true, "files.insertFinalNewline": true, "editor.formatOnSave": true, "[python]": { "files.encoding": "utf8" }, "[html]": { "files.encoding": "utf8" } }

关键点："files.autoGuessEncoding": false是核心。自动猜测是混乱之源，强制utf8让所有人起点一致。

6.2 Git 预提交钩子（pre-commit）

用pre-commit检查文件编码：

# .pre-commit-config.yaml - repo: https://github.com/pre-commit/pre-commit-hooks rev: v4.4.0 hooks: - id: check-byte-order-marker # 拒绝 UTF-8 BOM - id: end-of-file-fixer - id: trailing-whitespace - repo: local hooks: - id: check-utf8 name: Check UTF-8 encoding entry: bash -c 'xxd "$1" | head -n1 | grep -q "ff fe\\|fe ff\\|ff fe 00 00" && echo "ERROR: $1 is not UTF-8" && exit 1 || true' language: system files: \.(py|txt|csv|json|html|xml|md)$

效果：git commit时自动扫描