文件编码与换行符：UTF-8/CRLF/BOM诊断与转换

生信数据和脚本经常在 Windows/Mac/Linux 之间流转、从外网数据库下载、从合作者处接收——编码和换行符问题防不胜防。典型场景：Windows 编辑的样本列表上传到 Linux 服务器，报 Error: sample name not found: "Sample_1\r"——那个 \r 是 CRLF 里的回车符。本文梳理常见编码与换行符问题的诊断和解决方案。

实测环境：Debian 12，所有工具系统自带或 apt 安装。

1. 换行符——CRLF vs LF vs CR#

1.1 三种换行符#

系统	换行符	转义符	ASCII码
Windows (DOS)	CR+LF	`\r\n`	0x0D 0x0A
Linux / macOS (新)	LF	`\n`	0x0A
macOS (旧版, OS 9及以前)	CR	`\r`	0x0D

当前主流的冲突只发生在 Windows (CRLF) 和 Linux (LF) 之间。生信服务器几乎全是 Linux，而从 Windows 来的文件默认都是 CRLF——这就是问题根源。

1.2 诊断换行符#

1
# 方法1：file 命令（最直接）
2
file sample_list.txt
3
# 输出：sample_list.txt: ASCII text, with CRLF line terminators
4
#       ↑ 注意 "with CRLF" → Windows换行符
5

6
file gene_anno.gff3
7
# 输出：gene_anno.gff3: ASCII text
8
#       ↑ 没有 "CRLF" → 正常LF
9

10
# 方法2：cat -A 显示不可见字符
11
cat -A sample_list.txt
12
# sample1$
13
# sample2$
14
# 如果 $ 前面还有 ^M（即 \r），就是 CRLF：
15
# sample1^M$
16

17
# 方法3：xxd / od 十六进制查看
18
xxd sample_list.txt | head -5
19
# 0d 0a = CRLF, 0a = LF
20

21
# 方法4：统计 CR 字符数量
22
grep -c $'\r' sample_list.txt
23
# 正数说明文件里有CR

1.3 转换换行符#

1
# 安装 dos2unix
2
sudo apt install dos2unix -y
3

4
# CRLF → LF（Windows → Linux）
5
dos2unix sample_list.txt
6

7
# LF → CRLF（Linux → Windows，给同事用）
8
unix2dos sample_list.txt
9

10
# 批量转换
11
find . -name "*.txt" -exec dos2unix {} \;
12
find . -name "*.csv" -exec dos2unix {} \;
13
find . -name "*.sh"  -exec dos2unix {} \;
14

15
# 预览模式（只显示会转换什么，不实际修改）
16
dos2unix -i sample_list.txt
17

18
# 强制转换（即使文件已标记为二进制也转）
19
dos2unix -f some_file.txt

1.4 生信流程中的换行符灾难#

1
# 场景：Windows编辑的样本名列表
2
# samples.txt 内容：
3
# Sample_1\r\n
4
# Sample_2\r\n
5
# Sample_3\r\n

读取时如果不去掉 \r：

1
# Shell 里遍历——莫名其妙匹配不到文件
2
while read sample; do
3
    ls "${sample}_R1.fastq.gz"
4
    # 实际找的是 "Sample_1\r_R1.fastq.gz"——当然找不到！
5
done < samples.txt
6

7
# 正确做法：不依赖 dos2unix，在读取时也做清理
8
while IFS= read -r sample || [ -n "$sample" ]; do
9
    sample="${sample%$'\r'}"    # 去掉末尾的 \r
10
    ls "${sample}_R1.fastq.gz"
11
done < samples.txt

或者在流程入口统一转换：

1
# 流程脚本第一行
2
dos2unix -q samples.txt design.csv groups.tsv 2>/dev/null || true

2. 文件编码——UTF-8 vs GBK vs Latin1#

2.1 诊断编码#

1
# file 命令查看编码
2
file gene_names.txt
3
# 输出：gene_names.txt: UTF-8 Unicode text
4

5
file chinese_genes.txt
6
# 输出：chinese_genes.txt: ISO-8859 text  （可能是 GBK/GB2312）
7

8
# 更精确：uchardet（需要安装）
9
sudo apt install uchardet -y
10
uchardet unknown_file.txt
11
# 输出：UTF-8 或 GB18030 或 windows-1252
12

13
# 或 enca
14
sudo apt install enca -y
15
enca -L zh_CN unknown_file.txt
16
# 输出：Simplified Chinese National Standard; GB2312

2.2 编码转换：iconv#

1
# 基本语法
2
iconv -f <源编码> -t <目标编码> 输入文件 -o 输出文件
3

4
# GBK → UTF-8（最常见的生信场景）
5
iconv -f GBK -t UTF-8 chinese_report.csv -o chinese_report_utf8.csv
6

7
# GB18030 → UTF-8（GB18030是GBK的超集，兼容性更好）
8
iconv -f GB18030 -t UTF-8 old_data.txt -o old_data_utf8.txt
9

10
# Latin1 → UTF-8（西欧语言数据）
11
iconv -f LATIN1 -t UTF-8 european_data.txt -o european_data_utf8.txt
12

13
# 批量转换
14
for f in *.csv; do
15
    iconv -f GBK -t UTF-8 "$f" -o "${f%.csv}_utf8.csv"
16
done
17

18
# 查看支持的所有编码
19
iconv -l | head -50

2.3 生信文件中的编码问题#

GFF3/GTF 注释文件： 基因功能描述字段有时包含中文（来自一些国产数据库注释），用 GBK 编码的 GFF 文件在 Linux 工具里可能报错。

1
# 先诊断
2
file gene_annot.gff3
3
# 如果是 ISO-8859 或 unknown-8bit，大概率是 GBK
4

5
# 转换
6
iconv -f GBK -t UTF-8 gene_annot.gff3 -o gene_annot_utf8.gff3
7
# 验证
8
head -20 gene_annot_utf8.gff3

VCF 文件： VCF 规范要求 UTF-8，但部分旧软件可能写出 Latin1 或其他编码。bcftools 遇到非 UTF-8 字符会静默跳过或报错。

1
# 检查 VCF 编码
2
file variants.vcf
3
uchardet variants.vcf
4

5
# 必要时转换
6
cp variants.vcf variants_backup.vcf
7
iconv -f LATIN1 -t UTF-8 variants_backup.vcf -o variants.vcf

FASTA 文件： 序列行理论上是纯 ASCII（ATCGN + 简并碱基），但 header 行（> 开头）可能包含非 ASCII 字符。

1
# 检查 FASTA header
2
grep '^>' genome.fa | cat -A
3
# 如果有奇怪字符，可以用 iconv 转换
4

5
# 更安全：只保留 ASCII 字符（去掉非 ASCII 的 header 内容）
6
perl -pe 's/[^\x00-\x7F]//g' genome.fa > genome_clean.fa

3. BOM——UTF-8 的隐藏杀手#

3.1 什么是 BOM#

BOM (Byte Order Mark) 是文件开头的三个不可见字节：EF BB BF。Windows 记事本保存 UTF-8 文件时默认加上 BOM，Linux 工具看到它会直接崩。

1
# 检测 BOM
2
xxd sample.csv | head -1
3
# 如果有 BOM，开头三个字节是：efbbbf
4
# 输出示例：00000000: efbb bf53 616d 706c 652c 4772 6f75  ...Sample,Grou
5

6
# 或
7
file sample.csv
8
# 输出含 "UTF-8 Unicode (with BOM)" → 有BOM

3.2 BOM 在生信中的破坏力#

1
# 你以为第一列叫 "Gene"，其实叫 "\ufeffGene"
2
cut -f1 genes.csv | cat -A
3
# 输出：M-oM-;M-?Gene$    ← 前面有三个乱码
4

5
# R 读取有 BOM 的 CSV——第一列名变成乱码
6
df <- read.csv("genes.csv")
7
colnames(df)[1]
8
# [1] "ï..Gene"    ← 本该是 "Gene"
9

10
# Shell 脚本第一行有 BOM——直接报错
11
# 文件内容（看不见的BOM）: #!/bin/bash
12
bash script.sh
13
# /bin/bash^M: bad interpreter: No such file or directory

3.3 去掉 BOM#

1
# 方法1：tail -c +4（去掉前3字节）
2
tail -c +4 with_bom.csv > without_bom.csv
3

4
# 方法2：sed
5
sed -i '1s/^\xEF\xBB\xBF//' with_bom.csv
6

7
# 方法3：dos2unix（会自动去 BOM）
8
dos2unix with_bom.csv
9

10
# 方法4：Vim 打开
11
vim with_bom.csv
12
:set nobomb
13
:wq
14

15
# 批量去 BOM
16
find . -name "*.csv" -exec sed -i '1s/^\xEF\xBB\xBF//' {} \;

4. 编辑器配置——从源头避免编码问题#

4.1 Vim 配置#

1
" ~/.vimrc
2
set fileencoding=utf-8      " 默认编码
3
set fileencodings=utf-8,gbk,gb2312,latin1  " 读取时尝试的顺序
4
set fileformat=unix          " 默认换行符 LF
5
set fileformats=unix,dos     " 读取时尝试的顺序
6
set nobomb                   " 不写 BOM

保存时强制格式：

1
:set fileformat=unix    " LF 换行
2
:set fileencoding=utf-8 " UTF-8 编码
3
:w                      " 保存

4.2 VS Code 配置#

在 VS Code 状态栏右下角可以看到当前文件的编码和换行符格式。点击即可切换：

换行符：CRLF → 点一下选 LF
编码：UTF-8 → 点击可选择其他编码重新打开或保存

全局设置（settings.json）：

1
{
2
    "files.encoding": "utf8",
3
    "files.eol": "\n",
4
    "files.autoGuessEncoding": false
5
}

4.3 Windows 用户注意#

如果在 Windows 上编辑生信脚本/数据，强烈建议：

不要用记事本！用 VS Code / Notepad++ / Sublime
编辑器设置默认换行为 LF，默认编码为 UTF-8 without BOM
传文件到服务器用 scp/rsync，不要用 FTP（FTP 的 ASCII 模式会自动转换换行符）

5. 踩坑记录#

坑1：`^M` 出现在 Shell 脚本里导致 `bad interpreter`#

症状：bash run.sh 报 bad interpreter: /bin/bash^M: no such file or directory。

原因：Windows 上编辑的脚本，换行符是 CRLF。Shebang 行变成了 #!/bin/bash\r，系统找不到叫 /bin/bash\r 的解释器。

1
# 快速修复
2
dos2unix run.sh
3
bash run.sh   # 正常了

坑2：GFF3 文件里中文乱码#

症状：grep "激酶" genes.gff3 没结果，但明明知道文件里有注释提到”蛋白激酶”。

原因：GFF 文件可能是 GBK 编码。

1
# 诊断
2
uchardet genes.gff3
3
# GB18030
4

5
# 转换
6
iconv -f GB18030 -t UTF-8 genes.gff3 -o genes_utf8.gff3
7

8
# 验证
9
grep "激酶" genes_utf8.gff3 | head

坑3：read.csv 读出来的列名变成了 `ï..Gene`#

原因：CSV 文件带 BOM，R 把 BOM 字节当做列名的一部分。

解决：

1
# 方法1：预处理去 BOM
2
# system("sed -i '1s/^\\xEF\\xBB\\xBF//' data.csv")
3

4
# 方法2：R 内处理
5
df <- read.csv("data.csv", fileEncoding = "UTF-8-BOM")
6

7
# 方法3：用 readr（自动处理 BOM）
8
library(readr)
9
df <- read_csv("data.csv")

坑4：bcftools 报 “Unexpected character in FORMAT field”#

症状：VCF 文件的 FORMAT 列值看起来正常，但 bcftools 报非法字符。

原因：文件中某一行的某个字段混入了非 ASCII 字符（比如从 Excel 粘贴时带入了 Unicode 空白字符）。

1
# 检查非 ASCII 字符
2
grep -nP '[^\x00-\x7F]' variants.vcf
3

4
# 去掉所有非 ASCII（保留 VCF 结构）
5
perl -pe 's/[^\x00-\x7F]//g' variants.vcf > clean.vcf

坑5：dos2unix 转换后文件被截断#

症状：dos2unix big_file.txt 运行完文件比原来小了，最后几行不见了。

原因：文件中包含 \0（NULL 字节），dos2unix 默认在 NULL 处停止。

1
# 强制模式跳过 NULL 字节
2
dos2unix --force --safe big_file.txt
3

4
# 如果是二进制混文本，用 --assume作为文本
5
dos2unix --assume-text-mode big_file.txt

坑6：Git 自动转换换行符导致混乱#

Windows 上 Git 默认 core.autocrlf=true，clone 时自动把 LF → CRLF，commit 时 CRLF → LF。但如果项目里有二进制文件被误判为文本，或者某些测试用文件需要保留 CRLF，这个”智能转换”就成了灾难。

1
# 全局关闭自动转换（推荐生信团队统一配）
2
git config --global core.autocrlf false
3

4
# 项目级配置（在仓库根目录的 .gitattributes）
5
# * text=auto
6
# *.sh text eol=lf
7
# *.fastq binary
8
# *.bam binary

6. 小结#

问题	诊断命令	解决命令
CRLF 换行符	`file sample.txt`	`dos2unix sample.txt`
GBK 编码	`uchardet file.txt`	`iconv -f GBK -t UTF-8 file.txt`
UTF-8 BOM	`xxd file.csv \| head -1`	`sed -i '1s/^\xEF\xBB\xBF//' file.csv`
不可见字符	`cat -A file.txt`	`perl -pe 's/[^\x00-\x7F]//g'`
换行符统计	`grep -c $'\r' file.txt`	—
批量转换	—	`find . -name "*.txt" -exec dos2unix {} \;`

经验：

所有生信流程脚本和数据文件，统一使用 UTF-8 编码 + LF 换行符
从外面接收文件（合作者、Windows 用户、公开数据库），第一件事就是 file + dos2unix + iconv
在流程入口脚本里加上编码检测和转换，比事后追查问题省 10 倍时间

本文于 2025-12-03 在 Debian 12 上实测完成。dos2unix 7.5.2，iconv (glibc 2.38)，uchardet 0.0.8。所有命令可直接使用。

1. 换行符——CRLF vs LF vs CR#

1.1 三种换行符#

1.2 诊断换行符#

1.3 转换换行符#

1.4 生信流程中的换行符灾难#

2. 文件编码——UTF-8 vs GBK vs Latin1#

2.1 诊断编码#

2.2 编码转换：iconv#

2.3 生信文件中的编码问题#

3. BOM——UTF-8 的隐藏杀手#

3.1 什么是 BOM#

3.2 BOM 在生信中的破坏力#

3.3 去掉 BOM#

4. 编辑器配置——从源头避免编码问题#

4.1 Vim 配置#

4.2 VS Code 配置#

4.3 Windows 用户注意#

5. 踩坑记录#

坑1：`^M` 出现在 Shell 脚本里导致 `bad interpreter`#

坑2：GFF3 文件里中文乱码#

坑3：read.csv 读出来的列名变成了 `ï..Gene`#

坑4：bcftools 报 “Unexpected character in FORMAT field”#

坑5：dos2unix 转换后文件被截断#

坑6：Git 自动转换换行符导致混乱#

6. 小结#

文章分享

文章目录

文件编码与换行符：UTF-8/CRLF/BOM诊断与转换

1. 换行符——CRLF vs LF vs CR#

1.1 三种换行符#

1.2 诊断换行符#

1.3 转换换行符#

1.4 生信流程中的换行符灾难#

2. 文件编码——UTF-8 vs GBK vs Latin1#

2.1 诊断编码#

2.2 编码转换：iconv#

2.3 生信文件中的编码问题#

3. BOM——UTF-8 的隐藏杀手#

3.1 什么是 BOM#

3.2 BOM 在生信中的破坏力#

3.3 去掉 BOM#

4. 编辑器配置——从源头避免编码问题#

4.1 Vim 配置#

4.2 VS Code 配置#

4.3 Windows 用户注意#

5. 踩坑记录#

坑1：^M 出现在 Shell 脚本里导致 bad interpreter#

坑2：GFF3 文件里中文乱码#

坑3：read.csv 读出来的列名变成了 ï..Gene#

坑4：bcftools 报 “Unexpected character in FORMAT field”#

坑5：dos2unix 转换后文件被截断#

坑6：Git 自动转换换行符导致混乱#

6. 小结#

文章分享

文章目录

坑1：`^M` 出现在 Shell 脚本里导致 `bad interpreter`#

坑3：read.csv 读出来的列名变成了 `ï..Gene`#