上周又被叫去看一个线上问题一套服务跑在 Linux 上数据库用的是 SQL Server业务页面上一切正常但运维同事从终端连上去查数据订单一栏的备注全是问号导出的报表里中文变成了方块。这就是典型的Linux 系统上 SQL Server 中文乱码场景。这类问题看着玄乎实际上排查路径非常固定——它永远发生在三个位置之一存进去的时候丢了、传出来的路上错了、显示的时候渲染歪了。这三件事的处理方式完全不同搞错顺序会在错误的方向上浪费大半天。这篇内容会结合实际技术栈把排序规则、字段类型、驱动字符集、导入导出工具参数、系统 locale 这几条线一次讲透给出可以直接对照执行的排查命令和改法。无论你是刚接手 Linux 上 SQL Server 的运维还是被乱码折腾过的后端开发或数据开发都能在这里找到和自己情况对应的那一节。1. 乱码先分层三个环节各自的问题需要分开排查1.1 一个典型误判现场的重演我见过最常见的错误是看到乱码就直接去改服务器排序规则。折腾半天重启完发现该乱还是乱。原因很简单你看到的乱码可能跟存储毫无关系。举个真实遇到的情况。某套业务系统的数据库服务器部署在 Linux 发行版上字符集环境默认是POSIX。业务应用通过 JDBC 连接插入和读取都正常页面中文显示毫无问题。但运维在 SSH 终端里用命令行工具执行SELECT出来的中文全是???。这时候数据本身是好的问题出在客户端进程的 locale 没有设置成 UTF-8工具拿到的输出流是按单字节解释的遇到多字节字符就退化成了问号。反过来也有另一种情况终端里显示是好好的中文但打开网页一看是乱码。这时候数据可能已经在入库时被破坏只是命令行工具用某种方式凑巧还原了字节。所以第一件事不是动手改而是做一次分层验证把同一份数据用不同路径读出来比较结果。这一步花不了五分钟能省掉后面几小时的盲目试错。注意不要拿命令行显示正常当作数据正常的证据也不要拿页面显示正常当作存储正常的证据。两边必须交叉验证。1.2 五分钟定位法三段式验证我自己的习惯是跑三步验证按顺序来哪一步出问题就锁定在哪一层。第一步验证存储层。在数据库里直接比较长度和字节绕开所有客户端渲染SELECT col_name, LEN(col_name) AS 字符数, DATALENGTH(col_name) AS 字节数 FROM dbo.demo_table WHERE id 1;这里的关键是看字符数和字节数的比例。如果字段是varchar中文环境下正常应该是 1 个字符对应 2 个字节GBK 系或 3 个字节UTF-8如果字段是nvarchar1 个中文字符固定对应 2 个字节且DATALENGTH应该是LEN的两倍。如果DATALENGTH和LEN相等说明每个字符只占一个字节——那基本可以确定中文已经被替换成了单字节的问号数据已经损坏。第二步验证传输层。换一个客户端读同一份数据。如果网页端正常、终端不正常问题在终端侧如果两边都不正常但字节数是对的问题在驱动或转换环节如果两边都不正常且字节数也不对问题回到了存储层。第三步验证显示层。把查询结果重定向到文件用十六进制工具看一眼字节sqlcmd -S 127.0.0.1 -U sa -P your_password -Q SELECT col_name FROM db.dbo.demo_table -o /tmp/out.txt xxd /tmp/out.txt | head -50看输出文件里对应位置是E4 B8 ADUTF-8 的中、D6 D0GBK 的中还是3FASCII 问号。这三种字节序列直接对应三种完全不同的病因比盯着屏幕猜有效得多。这个方法的底层逻辑是乱码的本质是字节序列被错误地按另一套编码规则解释或者更糟——字节在某个环节被不可逆地替换掉了。前者可以救后者救不回来。区分这两者是所有后续操作的前提。2. 存储层排序规则和列类型决定了字还能不能救2.1 varchar 与 nvarchar一字之差天壤之别这是所有乱码问题的根子上。varchar存的是按当前排序规则代码页编码的字节nvarchar存的是UTF-16 编码的双字节序列。这个差别在中文场景下是决定性的。具体来说当你的列是varchar(50)而排序规则是SQL_Latin1_General_CP1_CI_AS代码页 1252那么你往里写测试两个字时SQL Server 会尝试把这两个字映射到 CP1252 字符集映射不上就直接写成两个问号??。这个替换是不可逆的原来的信息彻底没了后续不管怎么改排序规则、怎么改字段类型都救不回来。如果排序规则是Chinese_PRC_CI_AS代码页 936即 GBKvarchar是可以正常存中文的因为 GBK 本身就包含汉字。但这时候会引入新问题你的应用可能同时连了多个库、多个表它们的排序规则不一致做 JOIN 或者 UNION 的时候就会撞上排序规则冲突Cannot resolve the collation conflict between Chinese_PRC_CI_AS and SQL_Latin1_General_CP1_CI_AS in the equal to operation.nvarchar就没有这些烦恼。它统一用 UTF-16 存储跟排序规则的代码页无关跨库跨表比较也不会有编码问题。缺点是存储空间翻倍每个字符 2 字节索引键长度上限也受限制nvarchar 索引键上限 900 字节合 450 个字符。我的选型原则很直接场景推荐类型理由姓名、地址、备注、标题等可能含中文的字段nvarchar一劳永逸不依赖排序规则纯 ASCII 的编码类字段订单号、哈希、状态码varchar省空间索引效率高历史遗留varchar存中文的库先评估再迁移迁移成本和兼容性要算清楚有大量写入、需要极致压缩的场景varchar UTF-8 排序规则兼顾空间与中文支持但有版本门槛最后一行说的是 SQL Server 2019 引入的 UTF-8 排序规则比如Latin1_General_100_CI_AS_SC_UTF8。它的意义在于让varchar也能存 UTF-8 编码的中文平均每个汉字占 3 字节比nvarchar的 2 字节还费但对纯英文场景能省一半空间。这不是一个可以随便套用的银弹后面我会专门讲它的坑。2.2 服务器、数据库、列三级排序规则怎么看排序规则是分层的服务器有一层默认数据库继承服务器或者单独指定列又继承数据库或者单独指定。排查时必须三级都看只看服务器级别会漏掉问题。看服务器默认SELECT SERVERPROPERTY(Collation) AS 服务器排序规则;看所有数据库的排序规则SELECT name, collation_name FROM sys.databases ORDER BY name;看具体某张表每一列的排序规则SELECT t.name AS 表名, c.name AS 列名, ty.name AS 数据类型, c.max_length, c.collation_name FROM sys.columns c JOIN sys.tables t ON c.object_id t.object_id JOIN sys.types ty ON c.user_type_id ty.user_type_id WHERE t.name demo_table ORDER BY c.column_id;这三条查完你就能画出一张完整的图谱。我遇到过的典型问题是服务器默认是拉丁排序规则某张表在创建时手动指定了中文排序规则然后这张表和另一张表做 JOIN 时冲突报错。只看服务器级别是查不出来的必须下到列级别。还有一类容易被忽略的对象临时表。临时表建在 tempdb 里它的排序规则继承的是服务器默认不是当前数据库的。所以你在一个中文排序规则的库里 JOIN 临时表很可能就撞上了。解决方式有两种一是建表时显式COLLATE二是 JOIN 时加COLLATE DATABASE_DEFAULTSELECT a.id, b.name FROM #temp_input a JOIN dbo.demo_table b ON a.code b.code COLLATE DATABASE_DEFAULT;2.3 改排序规则的正确姿势与它的边界这是最容易踩坑的地方必须讲清楚ALTER DATABASE ... COLLATE只改变数据库的默认排序规则不会动已有用户表的已有列。也就是说你执行完下面这行ALTER DATABASE demodbs COLLATE Chinese_PRC_CI_AS;新建的表、新建的列会默认用这个排序规则但demo_table.col_name这一列的排序规则丝毫不变还是原来的。很多人改完运行没报错就以为搞定了结果测试发现老数据该乱还是乱。要改已有列得逐列ALTER而且还要考虑索引、约束、外键的依赖ALTER TABLE dbo.demo_table ALTER COLUMN col_name NVARCHAR(100) COLLATE Chinese_PRC_CI_AS NOT NULL;这个语句在以下情况会失败该列上有索引且索引键超长、该列被用在计算列或索引视图里、该列参与了 CHECK 约束。失败信息通常不太友好需要一个个解依赖再改回来。改数据库排序规则本身也需要独占访问标准操作序列是ALTER DATABASE demodbs SET SINGLE_USER WITH ROLLBACK IMMEDIATE; ALTER DATABASE demodbs COLLATE Chinese_PRC_CI_AS; ALTER DATABASE demodbs SET MULTI_USER;注意WITH ROLLBACK IMMEDIATE会强行断开所有连接并回滚未提交事务。生产环境执行前务必确认没有正在跑的重要作业最好安排在维护窗口。我见过有人在业务高峰执行这句直接导致一批订单事务回滚。至于已经损坏的数据怎么判断能不能救给一个我实际用过的判断方法SELECT col_name, CAST(col_name AS VARBINARY(200)) AS 原始字节 FROM dbo.demo_table WHERE id 1;如果字节里出现大量3FASCII 问号那是真丢了只能从源系统重新导入。如果字节是一串看起来杂乱但非3F的值比如 UTF-8 的E4 B8 AD被当成了三个 GBK 字符存进去那就有机会用二进制转换还原出来-- 前提该列当前排序规则的代码页能无损容纳这些字节 SELECT CAST(CAST(col_name AS VARBINARY(200)) AS VARCHAR(200)) COLLATE Latin1_General_100_CI_AS_SC_UTF8 AS 还原结果 FROM dbo.demo_table WHERE id 1;这段逻辑走的是先把字符串当字节取出来再按 UTF-8 重新解释的思路。成功率取决于原始字节在存入过程中有没有被截断或替换不能指望百分百。所以最靠谱的永远是从源头重新导一遍别在数据库里做数据考古。2.4 UTF-8 排序规则的诱惑与陷阱SQL Server 2019 之后Latin1_General_100_CI_AS_SC_UTF8这类排序规则确实让varchar能存中文了很多人一看觉得是救星直接全库切过去。我劝你先看完这几个坑。坑一长度语义变了。varchar(10)在 UTF-8 排序规则下能存 10 个字节也就是 3 个汉字。原来按字节设计的字段长度全部要重算。nvarchar(10)对应要varchar(30)才能装下同样多的中文这在字段定义和应用程序参数长度校验里都会出问题。坑二隐式转换。一个 UTF-8 排序规则的varchar列和一个非 UTF-8 排序规则的varchar列比较时SQL Server 要做隐式转换转换过程可能丢字符也可能让索引失效。执行计划里看到CONVERT_IMPLICIT就要警惕。坑三客户端驱动支持度。老版本驱动、老版本 FreeTDS、某些语言的旧版 ODBC 封装对 UTF-8 排序规则的varchar处理并不完善可能读出来仍然乱码。上线前必须在实际客户端环境里验证。所以我的建议是新项目如果确定能上 2019 及以上版本可以统一用 UTF-8 排序规则 varchar存量系统不要轻易动用 nvarchar 更稳妥。混合使用是灾难的起点。3. 客户端与驱动层连接字符串里的隐形开关3.1 驱动版本的选择逻辑在 Linux 上连 SQL Server驱动选择比 Windows 上要讲究。常见的有三种官方 ODBC 驱动msodbcsql 系列、FreeTDS、以及各语言自带的协议实现。我的优先级排序是官方 ODBC 驱动 语言原生实现 FreeTDS。原因是官方驱动在字符集处理上做了完整的 UTF-16 与 UTF-8 转换对nvarchar的支持是可靠的。FreeTDS 虽然兼容性好、部署轻但它的字符集配置依赖freetds.conf里的client charset参数一旦漏配就默认用 ISO-8859-1中文必乱。而且 FreeTDS 不同版本对nvarchar的处理行为有差异跨版本升级时容易出现以前好的现在坏了。检查已装的驱动odbcinst -q -d正常情况下应该能看到类似[ODBC Driver 18 for SQL Server]的输出。如果只有[FreeTDS]说明你用的很可能是 FreeTDS 路径出问题的概率更高。连接串里要显式声明字符集。ODBC 官方驱动的 DSN 写法[demodsn] DriverODBC Driver 18 for SQL Server Server127.0.0.1 Port1433 Databasedemodbs Encryptyes TrustServerCertificateyes注意Encrypt和TrustServerCertificate这两个参数。新版驱动默认开启加密如果服务端证书是自签的不关掉校验会连不上报错信息跟字符集毫无关系容易误导排查方向。如果确实要用 FreeTDSfreetds.conf里必须显式配置[global] client charset UTF-8 tds version 7.4 [demodsn] host 127.0.0.1 port 1433 database demodbs tds version 7.4 client charset UTF-8client charset UTF-8这一行是 FreeTDS 中文乱码的头号原因。它决定了 FreeTDS 把服务端返回的 UTF-16 转成什么编码交给应用。不配就默认走 ISO-8859-1中文直接完蛋。3.2 各语言客户端的字符集参数对照不同语言的驱动字符集参数的写法和默认值都不一样这块我整理成一张表实测可用语言 / 驱动关键参数建议值备注Python pyodbc无需显式指定-驱动层自动处理 UTF-16 转换Python pymssqlcharsetutf8不指定会走 FreeTDS 默认编码PHP sqlsrvCharacterSetUTF-8连接选项数组里设置PHP PDO_DBLIBcharsetUTF-8底层走 FreeTDS需同步配 confJava JDBCcharacterEncodingUTF-8新版驱动已自动老版本需显式Node.js tediousoptions.charset默认即可内部统一 UTF-8Go go-mssqldb无需显式指定-原生协议实现UTF-16 自动转换.NET Core需注册 CodePages 提供程序-见下方说明其中 .NET Core 这个要单独说一句。在 Linux 上跑 .NET Core 时如果代码里用到Encoding.GetEncoding(GBK)或类似的老代码页会抛NotSupportedException因为默认只带 UTF-8 和少量基础编码。需要在程序入口注册System.Text.Encoding.RegisterProvider( System.Text.CodePagesEncodingProvider.Instance);不注册的话业务代码里做 GBK 与 UTF-8 互转的地方就会失败表现出来的现象就是某几个接口的中文乱码其他接口正常。这种局部乱码最难查因为它不是全局配置问题。3.3 sqlcmd 的编码行为与输出重定向sqlcmd是 Linux 上最常用的命令行客户端也是中文乱码投诉最多的地方。它的行为要拆开看输入编码和输出编码是两套东西。输入侧如果你的 SQL 脚本文件里含中文比如INSERT INTO ... VALUES (测试)sqlcmd需要知道文件是什么编码。用-f参数指定sqlcmd -S 127.0.0.1 -U sa -P your_password \ -d demodbs \ -f 65001 \ -i /tmp/insert_demo.sql-f 65001表示输入文件和输出流都按 UTF-8 处理。不指定的话sqlcmd会按当前 locale 的代码页来解释文件UTF-8 的中文就会被拆成乱码字节。输出侧如果结果要重定向到文件建议显式指定编码并用统一的工具处理sqlcmd -S 127.0.0.1 -U sa -P your_password \ -d demodbs -f 65001 \ -Q SET NOCOUNT ON; SELECT col_name FROM dbo.demo_table \ -o /tmp/result.txt \ -W -s |-W去掉列值两边的空格填充-s指定分隔符这两个参数对导出文件的可用性影响很大。导出后一定用file命令确认编码file -i /tmp/result.txt如果输出是charsetunknown-8bit或iso-8859-1说明-f没生效或者被 locale 覆盖了。这种情况下我会在命令前显式加环境变量LANGC.UTF-8 LC_ALLC.UTF-8 sqlcmd -S ... -f 65001 ...另外提醒一点如果你用的是新版基于 Go 重写的命令行工具通常叫sqlcmd但版本号是 1.x它的行为和老的 ODBC 版本有差异-f参数可能不被支持编码处理由终端环境决定。排查时先sqlcmd -?看一眼版本和参数列表别拿老文档套新工具。4. 数据进出环节文件编码、bcp 与 BULK INSERT4.1 先把文件编码这件事确认清楚批量导入导出的乱码九成源于一个低级但普遍的问题没人确认过源文件到底是什么编码。业务方给过来的 CSV可能是 Windows 上 Excel 另存的 GBK也可能是某个系统导出的 UTF-8还分带不带 BOM 两种还可能是 UTF-16LE。这三种在导入时表现完全不同UTF-8 无 BOM导入 GBK 环境的库中文变乱码但字节完整UTF-8 带 BOMBOM 会变成第一列的第一个字符通常表现为第一行第一列多出奇怪的符号或者导入报错GBK导入 UTF-8 环境的库中文变乱码UTF-16LE不指定宽字符模式直接导整个文件都是乱码标准动作是先探测file -i /path/to/input.csv head -c 64 /path/to/input.csv | xxdxxd输出的前几个字节如果是EF BB BF说明是 UTF-8 带 BOM如果是FF FE是 UTF-16LE如果前几个字节里有D6 D0这类 GBK 双字节那就是 GBK 编码。确认完编码统一转成同一种再导入不要指望数据库端帮你猜# GBK 转 UTF-8 iconv -f GBK -t UTF-8 /path/to/input.csv -o /path/to/input_utf8.csv # 去掉 UTF-8 BOM sed -i 1s/^\xEF\xBB\xBF// /path/to/input_utf8.csviconv转换时如果遇到无法映射的字符默认会中断。加-c参数可以跳过但我强烈不建议在生产数据上用-c它会静默丢字符你根本不知道丢了什么。宁可中断然后定位是哪一行有问题。提示转换完成后一定要抽样验证diff (head -20 原文件) (head -20 新文件)看一眼确认没被截断或者串行。我踩过一次因为原文件某行有非法字节导致整批数据错位排查花了很久。4.2 bcp 参数选择与实测记录bcp是 Linux 上做大批量导入导出的主力工具它的参数组合直接影响编码结果。核心就三个选项-c字符模式把数据按当前代码页转成字符-w宽字符模式按 UTF-16LE 处理-N原生模式保留二进制表示性能最好但不通用导出含中文的数据首选-w导出的文件是 UTF-16LE虽然用普通编辑器打开可能看着别扭但导回来绝对不会丢字符bcp demodbs.dbo.demo_table out /tmp/demo_w.dat \ -S 127.0.0.1 -U sa -P your_password \ -w -C 65001这里-C 65001指定代码页为 UTF-8。注意-w配合-C 65001时实际输出是 UTF-16 还是 UTF-8 取决于驱动版本和bcp版本实测下来新版官方工具会输出 UTF-8 无 BOM老版本输出 UTF-16LE。所以导出后必须验证一次file -i /tmp/demo_w.dat如果是charsetutf-16le导回来的时候同样用-w如果是charsetutf-8导回来时用-c -C 65001。这个不匹配是导入乱码的高频原因我在不止一个环境里见过有人导的时候用-w、导回来用-c然后抱怨数据怎么坏了。导回去bcp demodbs.dbo.demo_table_staging in /tmp/demo_w.dat \ -S 127.0.0.1 -U sa -P your_password \ -w -C 65001 -b 10000-b 10000控制每批提交的行数。大批量导入时设置批次能显著降低日志膨胀也能在出错时只回滚当前批次。这个参数是我从一次导入 800 万行把事务日志撑爆的经历里学来的。下表是我实测过的参数组合与结果对照供参考导出参数文件编码导入参数中文结果-c默认代码页GBK 或 UTF-8取决于 locale-c取决于 locale 是否一致不一致必乱-c -C 65001UTF-8-c -C 65001正常-wUTF-16LE-w正常-wUTF-16LE-c乱码-N二进制-N正常但不可跨版本跨平台通用结论很简单导出用什么参数导入就用什么参数别混。混用是乱码的加速器。4.3 BULK INSERT 的 CODEPAGE 陷阱如果是在 T-SQL 里做导入BULK INSERT的编码控制靠CODEPAGE和DATAFILETYPE两个子句。BULK INSERT dbo.demo_table_staging FROM /tmp/demo_utf8.csv WITH ( FORMAT CSV, FIRSTROW 2, FIELDTERMINATOR ,, ROWTERMINATOR \n, CODEPAGE 65001, DATAFILETYPE char, TABLOCK );这里有三个容易踩的点。第一CODEPAGE和DATAFILETYPE要配对。DATAFILETYPE char配 UTF-8 或 GBK 编码的文件DATAFILETYPE widechar配 UTF-16LE 的文件。配错的话中文要么乱码要么整体偏移。第二CODEPAGE 65001在部分版本上行为不稳定。老版本对 UTF-8 的支持有 bug可能把三字节的中文按单字节处理导致截断。如果目标表是nvarchar且版本较老稳妥做法是把文件转成 UTF-16LE 再用widechar导成功率高得多。第三ROWTERMINATOR在 Windows 生成的文件里是\r\n。从 Windows 传过来的 CSV行尾是回车换行而 Linux 上生成的通常是\n。如果指定错了整个文件会被当成一行报字段数超限之类的错误。这个错误信息跟编码毫无关系但实际原因就是行尾符不对。用file命令看一眼file /tmp/demo.csv输出里如果带with CRLF line terminators那ROWTERMINATOR就得写0x0d0a。还有个隐藏点BULK INSERT读取文件时用的是SQL Server 服务进程的权限和 locale不是你当前客户端的。所以你在终端里LANGC.UTF-8不代表服务进程也是。如果执行报操作系统错误 5拒绝访问或无法打开文件先检查目录权限再检查服务进程的环境变量。5. Linux 系统层locale 没配对前面全白搭5.1 locale 到底该设成什么我纠正过一个流传很广的误解要正确显示中文locale 必须是zh_CN.UTF-8。不是的。en_US.UTF-8同样能正确显示中文因为决定编码的是UTF-8这个后缀不是前面的语言标识。语言标识只影响系统消息、日期格式、排序规则这些。真正的区别在于LANGC或LANGPOSIX单字节环境中文必乱LANGen_US.UTF-8UTF-8 环境中文正常显示系统消息英文LANGzh_CN.UTF-8UTF-8 环境中文正常显示系统消息中文所以如果你的服务器只需要显示中文而不需要中文系统提示设成C.UTF-8或者en_US.UTF-8就够了还省得装完整的中文语言包。这在精简容器镜像里特别实用。检查当前状态locale输出里注意LANG、LC_ALL、LC_CTYPE三个。LC_ALL的优先级最高设了它其他都失效。如果LC_ALL被设成了C那LANG设成什么都不管事。生成缺失的 localeDebian / Ubuntu 系apt-get install -y locales sed -i s/^# *\(en_US.UTF-8\)/\1/ /etc/locale.gen locale-gen update-locale LANGen_US.UTF-8RHEL / CentOS 系的路径不同通常是localedef -i en_US -f UTF-8 en_US.UTF-8 localectl set-locale LANGen_US.UTF-8改完要重新登录 shell 才生效因为环境变量是在登录时读取的。改完验证locale echo $LANG有个特殊情况值得提某些精简镜像里locale -a只输出C和POSIX连C.UTF-8都没有。这时候要么装语言包要么用LANGC.UTF-8试试——部分发行版的 glibc 内置支持C.UTF-8不需要额外安装。实在不行就只能在应用层做显式编码指定绕开对 locale 的依赖。5.2 容器与服务的环境变量传递容器化部署时locale 问题会被放大因为容器默认环境通常是极简的docker run --rm -it your_image locale大概率输出LANG和LC_*全空等于POSIX。这时候所有依赖 locale 的程序都会按单字节处理。在 Dockerfile 里固定住最省事ENV LANGC.UTF-8 ENV LC_ALLC.UTF-8用C.UTF-8而不是en_US.UTF-8的原因是不需要额外装locales包镜像能小几十兆。如果业务确实需要中文排序规则再考虑装完整语言包。如果是 Kubernetes 部署还要注意环境变量的传递链路。在部署描述里定义env: - name: LANG value: C.UTF-8 - name: LC_ALL value: C.UTF-8一个常见的坑是应用容器里 locale 设对了但它调用的外部工具比如通过exec调bcp、sqlcmd跑在另一个最小化的 sidecar 容器里那个容器没设。表现出来就是应用本身中文正常但导出文件乱码。还有 systemd 管理的服务。systemd 服务的环境变量不继承登录 shell 的LANG要在单元文件里显式写[Service] EnvironmentLANGC.UTF-8 EnvironmentLC_ALLC.UTF-8改完执行systemctl daemon-reload systemctl restart your_service。这一步漏了的话你在 SSH 里手动跑脚本一切正常服务跑起来就乱码非常折磨人。6. 排查速查表与踩坑清单6.1 症状到病因的速查表这张表是我这几年攒下来的遇到乱码先对号入座能省掉不少猜的时间症状最可能的原因首选验证方式网页正常命令行显示???客户端 locale 不是 UTF-8locale查看LANG/LC_ALL命令行正常网页乱码应用层字符集配置或输出编码错误抓包或打印应用侧字节两边都乱DATALENGTH LEN数据已存成单字节问号不可逆查DATALENGTH与LEN对比两边都乱但字节数偏大字节存对了解释编码错了CAST(... AS VARBINARY)看原始字节部分行乱、部分行正常源文件混合编码或某几行有非法字节iconv逐行验证只有某些表乱这些表或列的排序规则异常查sys.columns.collation_nameJOIN 时报排序规则冲突两侧列的排序规则不一致错误信息里直接给了两个排序规则名导入后第一行第一列多乱码源文件带 UTF-8 BOMhead -c 3 | xxd看EF BB BF导入报字段数超限行尾符不匹配\r\nvs\nfile看是否 CRLF导出文件被识别为unknown-8bit工具输出了本地代码页而非 UTF-8显式加-f 65001或-C 65001手动执行正常服务执行乱码systemd 或容器未继承 locale查单元文件Environment或容器 ENV用这张表的时候有个技巧先看症状出现在哪个环节再往表里查。不要一上来就怀疑数据损坏绝大多数乱码是显示层或传输层的问题数据本身是好的。数据真的损坏的情况比例远低于想象。6.2 几条付出代价才得到的经验经验一改编码之前先备份尤其是改排序规则。这一条听起来是废话但我见过不止一次有人改完发现某些查询报错想回滚却发现没备份。排序规则改动会影响索引、约束、存储过程里的临时表定义回滚不是简单地把COLLATE改回去就行的。改之前至少做一次完整备份并且在测试库上先跑一遍全量回归。经验二不要用SET LANGUAGE或者SET DATEFORMAT去修乱码。这两个设置影响的是日期格式和系统消息语言跟字符编码毫无关系。我见过有人在网上看到这类建议就照着做白折腾半天。乱码只有编码这一个维度别被带偏。经验三COLLATE DATABASE_DEFAULT是 JOIN 冲突的通用解法但它有性能代价。加了这个子句后被转换的列无法使用索引查找可能从索引扫描变成全表扫描。在数据量大的表上要谨慎更好的办法是从根上统一排序规则而不是到处贴膏药。经验四验证编码问题永远用二进制说话。屏幕上看到的中文可能是终端帮你还原的假象。我现在的习惯是任何跟编码相关的排查第一步都是xxd或者CAST AS VARBINARY把字节打出来看。字节不会骗人显示会。经验五新项目直接上nvarchar能避开 90% 的问题。存储空间多花的那点成本跟后期排查乱码、迁移数据、修数据的工作量比完全不值一提。真到了空间敏感的场景再针对性优化那几个大表没必要全库都省。经验六把编码约定写进开发规范比事后排查有效一百倍。我现在参与的每个项目都会在规范里明确三条库表字符字段一律nvarchar、所有源文件统一 UTF-8 无 BOM、所有容器基础镜像固定LANGC.UTF-8。这三条定下来乱码类问题的报障量直接掉到接近零。技术问题的根治往往不在技术本身而在流程约定。最后补充一个我最近才用顺手的小技巧排查乱码时在测试库里建一张探针表专门放各种典型字符——中文、日文、emoji、全角符号、生僻字——每种占一行。遇到问题时先往这张表插一遍再读一遍能在一分钟内判断是存储问题还是显示问题。emoji 尤其有用因为它属于补充字符需要_SC结尾的排序规则才能正确存储如果 emoji 显示成两个问号说明排序规则版本太老这个问题顺带就暴露了。