SQL Server导出数据时字符编码乱码如何解决？

Question

在使用SQL Server导出数据至CSV或Excel文件时，常出现中文字符乱码问题，尤其是在使用SQL Server Management Studio（SSMS）“另存为”功能或bcp工具导出时。该问题多因导出文件未正确指定UTF-8或Unicode编码所致，导致记事本等默认编码为ANSI的程序打开时显示乱码。如何确保导出数据时正确保留中文字符，避免编码不一致引发的乱码？

Answer 1

1. 问题背景与常见现象

在使用SQL Server导出数据至CSV或Excel文件时，中文字符乱码是一个长期困扰开发和运维人员的典型问题。尤其是在通过SQL Server Management Studio（SSMS）的“另存为”功能导出查询结果，或使用命令行工具进行批量导出时，常出现汉字显示为“？？？”或“锟斤拷”等异常字符。

该现象的根本原因在于：导出过程中未明确指定文本文件的编码格式，导致系统默认采用非Unicode编码（如ANSI或Windows-1252），而这些编码无法正确解析UTF-8或Unicode中的中文字符。

例如，在Windows系统中，记事本（Notepad）默认以ANSI打开无BOM的文本文件，若导出文件实际为UTF-8但无字节顺序标记（BOM），则会被错误识别，从而引发乱码。

2. 编码机制分析：从字符集到文件存储

要解决乱码问题，必须理解以下核心概念：

• 字符集（Character Set）：定义了字符与数字之间的映射关系，如ASCII、GB2312、UTF-8。
• 编码（Encoding）：将字符转换为字节流的具体方式，如UTF-8是Unicode的一种实现方式。
• BOM（Byte Order Mark）：位于文件开头的特殊标记，用于标识文件编码类型，如EF BB BF表示UTF-8 with BOM。

SQL Server内部通常使用Unicode（如NVARCHAR类型），但在导出到外部文件时，若未显式控制编码，会依赖客户端工具或操作系统的默认行为，极易造成编码不一致。

3. 常见导出方式及其编码缺陷

导出方式	默认编码	是否支持UTF-8	乱码风险
SSMS “另存为” CSV	ANSI (系统区域设置)	否	高
bcp 工具导出	ASCII / OEM	需手动指定-c -C 65001	中至高
SQLCMD 导出	依赖输出重定向	可通过-chcp修改代码页	中
PowerShell脚本导出	可指定Encoding参数	支持UTF-8, UTF-8 BOM	低

4. 解决方案一：使用bcp工具并指定UTF-8编码

对于习惯使用命令行批量导出的用户，bcp是高效选择，但必须正确配置编码参数。

-- 示例：导出表数据为UTF-8编码的CSV文件
bcp "SELECT * FROM [数据库].[模式].[表名]" queryout "D:\data\output.csv" \
-c -C 65001 -t"," -r"\n" -S localhost -T

# 参数说明：
# -c : 使用字符数据类型
# -C 65001 : 指定代码页为UTF-8
# -t : 字段分隔符
# -r : 行分隔符
# -T : 使用Windows身份验证

注意：虽然-C 65001启用UTF-8，但生成的文件不含BOM，部分程序仍可能误判编码。

5. 解决方案二：PowerShell脚本导出并强制BOM

利用PowerShell的强编码控制能力，可确保导出文件带UTF-8 BOM，提升兼容性。

# PowerShell 脚本示例：从SQL Server导出并保存为带BOM的UTF-8 CSV
$connectionString = "Server=localhost;Database=TestDB;Integrated Security=true;"
$query = "SELECT * FROM ChineseData"
$conn = New-Object System.Data.SqlClient.SqlConnection($connectionString)
$cmd = New-Object System.Data.SqlClient.SqlCommand($query, $conn)
$conn.Open()
$reader = $cmd.ExecuteReader()

$output = @()
while ($reader.Read()) {
    $row = @()
    for ($i = 0; $i -lt $reader.FieldCount; $i++) {
        $row += $reader[$i]
    }
    $output += ($row -join ",")
}
$conn.Close()

# 使用UTF8Encoding对象写入BOM
$bom = New-Object System.Text.UTF8Encoding($true)
[System.IO.File]::WriteAllLines("D:\data\output_with_bom.csv", $output, $bom)

6. 解决方案三：SSIS或Azure Data Studio替代方案

对于企业级ETL场景，建议使用SQL Server Integration Services（SSIS）或Azure Data Studio进行导出。

在SSIS中，Flat File Destination组件允许明确设置文本编码为“65001 (UTF-8)”或“Unicode”，避免乱码。

Azure Data Studio作为现代跨平台工具，在导出结果时提供编码选项，包括UTF-8、UTF-16等，优于传统SSMS。

7. 验证流程图：确保导出文件编码正确

graph TD A[执行SQL查询] --> B{选择导出方式} B --> C[bcp命令行] B --> D[SSMS另存为] B --> E[PowerShell脚本] C --> F[添加-C 65001参数] D --> G[改用其他工具或后续转码] E --> H[使用UTF8Encoding(true)写入BOM] F --> I[生成UTF-8文件] H --> I I --> J[用记事本打开验证] J --> K{是否显示正常中文?} K -- 是 --> L[成功] K -- 否 --> M[检查BOM是否存在] M --> N[使用Notepad++查看编码] N --> O[必要时手动转换编码]

8. 推荐实践清单

1. 避免直接使用SSMS“另存为”导出含中文的数据。
2. 使用bcp时务必加上-C 65001参数启用UTF-8。
3. 优先采用PowerShell或Python脚本导出，便于控制编码与BOM。
4. 导出后使用Notepad++等工具确认文件实际编码。
5. 对关键报表文件，自动添加UTF-8 BOM头以增强兼容性。
6. 考虑将导出流程封装为自动化作业，减少人为失误。
7. 在文档中明确标注导出文件的编码标准，便于下游处理。
8. 测试不同终端（如Excel、Python pandas）读取导出文件的效果。
9. 在CI/CD管道中集成编码验证步骤。
10. 培训团队成员识别常见乱码模式及其根源。