SQL*Loader 导入中文数据时出现报错或乱码，其核心原因在于数据文件编码、客户端会话字符集（NLS_LANG）与数据库服务器字符集三者之间的不一致，解决这一问题的关键在于确保数据流经的每一个环节都正确识别了字符编码，最有效的专业解决方案是在控制文件中显式指定 CHARACTERSET 参数，或者在执行导入前精确设置操作系统的 NLS_LANG 环境变量，以匹配源数据文件的编码格式。
字符集转换机制与报错根源
要彻底解决 SQLLoader 的中文报错问题，首先必须理解 Oracle 的字符集转换机制，Oracle 数据库在处理数据导入时，数据会经过三个关键节点：源数据文件、SQLLoader 客户端会话、数据库服务器，报错通常发生在客户端读取文件或向服务器提交数据的转换过程中。
当源文件是 UTF8 编码，而客户端环境变量 NLS_LANG 被设置为默认的 ZHS16GBK（简体中文）时，客户端会尝试用 GBK 的规则去解析 UTF8 的字节流，由于 UTF8 的汉字通常占用 3 个字节，而 GBK 占用 2 个字节，这种字节级别的错位会导致客户端无法识别字符，进而抛出“字段值过长”或“无效的字符编码”等错误，反之，如果数据库是 AL32UTF8，而客户端传入了未声明的 GBK 数据，数据库在验证字符边界时也会因为字节序列不合法而拒绝写入，明确每一层的编码是解决问题的前提。
精准诊断：定位编码不匹配环节
在实施修复方案前,必须通过专业手段诊断当前的编码环境，避免盲目操作。
需要确认目标数据库的字符集,可以通过执行 SQL 查询 SELECT value FROM nls_database_parameters WHERE parameter = 'NLS_CHARACTERSET'; 来获取，目前主流的 Oracle 数据库多为 AL32UTF8，但在老旧系统中可能仍存在 ZHS16GBK。
需要准确判断待导入的数据文件编码,在 Linux 环境下，可以使用 file i filename.csv 命令查看文件的 charset 属性；在 Windows 下，可以使用 Notepad++ 等编辑器查看“编码”格式，或者利用 PowerShell 的 GetContent 命令配合编码检测模块，切记，不要凭直觉猜测，例如带有 BOM（Byte Order Mark）头的 UTF8 文件和无 BOM 的 UTF8 文件在处理上存在细微差别。
检查当前客户端的 NLS_LANG 设置，在 Windows 的 CMD 中执行 echo %NLS_LANG%，在 Linux Shell 中执行 echo $NLS_LANG，如果输出为空，则客户端默认使用操作系统的编码，这往往是导致中文报错的隐形杀手。
核心解决方案：控制文件显式指定法
这是最推荐、最稳健的专业解决方案，因为它不依赖于操作系统的环境变量，具有跨平台和脚本化的独立性，通过在 SQL*Loader 的控制文件（.ctl）中直接声明数据文件的字符集，可以强制客户端按照指定编码读取数据。
假设数据文件 data.csv 是 UTF8 编码（无 BOM），而数据库字符集也是 AL32UTF8，在控制文件的 LOAD DATA 语句后，紧跟 CHARACTERSET UTF8。
LOAD DATA CHARACTERSET UTF8 INFILE 'data.csv' INTO TABLE target_table FIELDS TERMINATED BY ',' TRAILING NULLCOLS (col1, col2, col3)
如果数据库是 ZHS16GBK，而数据文件是 UTF8，SQL*Loader 会自动在客户端完成从 UTF8 到 ZHS16GBK 的转换，这种方法的优势在于“所见即所得”，控制文件本身即携带了编码元数据，避免了因不同运维人员环境变量配置不同导致的导入失败，对于带有 BOM 的 UTF8 文件，通常建议去掉 BOM 头，或者在处理时跳过第一个字节。
辅助解决方案：环境变量匹配法
如果无法修改控制文件,或者控制文件由第三方生成，那么必须确保客户端的 NLS_LANG 与数据文件编码一致。
数据文件是 UTF8，数据库是 AL32UTF8。 此时应设置客户端 NLS_LANG 为 AMERICAN_AMERICA.AL32UTF8，这样，客户端会直接将 UTF8 数据透传给数据库，无需转换，效率最高且不会报错。
数据文件是 GBK，数据库是 AL32UTF8。 此时应设置客户端 NLS_LANG 为 AMERICAN_AMERICA.ZHS16GBK，客户端会以 GBK 读取文件，然后将其转换为 AL32UTF8 发送给数据库。
在 Linux 下，执行命令：export NLS_LANG=AMERICAN_AMERICA.AL32UTF8，在 Windows 下，可以在注册表中修改，或者在当前 CMD 会话中执行 set NLS_LANG=AMERICAN_AMERICA.AL32UTF8，需要注意的是，这种方法对运维人员的操作规范性要求较高，容易在多人协作的环境中出现配置遗漏。
进阶排查：字段长度与字节截断
在解决了字符集匹配问题后,有时仍会遇到“字段值过大”的报错，这通常涉及字节长度与字符长度的定义差异。
在 Oracle 中，VARCHAR2(10) 在 UTF8 字符集下可能被解释为 10 个字节（取决于 MAX_STRING_SIZE 参数），也可能被解释为 10 个字符，如果定义的是字节长度，一个中文字符在 UTF8 下占 3 个字节，那么仅能存入 3 个汉字，如果数据文件中的汉字超过限制，SQL*Loader 就会报错。
针对这种情况,专业的解决方案是检查表结构定义，如果业务逻辑允许，建议使用 CHAR 语义来定义列，即 VARCHAR2(10 CHAR)，这样可以确保存储的是 10 个字符而非 10 个字节，如果无法修改表结构，则必须在数据源端截断过长的字符串，或者在控制文件中使用 SQL 函数进行处理，col1 CHAR(10) "SUBSTR(:col1, 1, 10)"，但这仅适用于字符语义，对于字节语义的截断需要更复杂的逻辑。
常见报错代码解析
在实际操作中,遇到具体的 ORA 错误代码能帮助我们快速锁定问题。
- ORA01722: invalid number：有时字符集错误会导致数字列被识别为乱码，进而无法转换为数字。
- ORA12899: value too large for column：这是典型的长度错误，如前所述，通常是字符集转换导致字节膨胀（如 GBK 转 UTF8）。
- *SQLLoader350: Syntax error**：如果控制文件中
CHARACTERSET拼写错误或指定的字符集名称不被 Oracle 支持（例如写成了 UTF8 而数据库版本极老不支持），会导致语法错误。
相关问答
Q1：如果数据文件在 Excel 中看起来是正常的中文，但导入后全是问号或者乱码，是什么原因？A1： 这通常不是 SQLLoader 的报错，而是典型的字符集不匹配导致的乱码，原因通常是数据文件实际编码（如 UTF8）与数据库期望的编码（或客户端 NLS_LANG 设置）不一致，数据库是 ZHS16GBK，但数据文件是 UTF8，且未在 SQLLoader 中指定转换，Oracle 会将 UTF8 的字节流强行按 GBK 解释，导致出现“烫烫烫”或“??”等乱码，解决方法是按照前文所述，在控制文件中指定正确的源文件字符集，让 Oracle 自动完成转换。
*Q2：在 Linux 服务器上使用 SQLLoader 导入中文，如何确保当前会话生效？A2：* 在 Linux Shell 脚本中执行 SQLLoader 时，建议不要依赖全局的环境变量配置，最佳实践是在脚本内部，紧挨着 sqlldr 命令之前显式导出 NLS_LANG。
export NLS_LANG=AMERICAN_AMERICA.AL32UTF8 sqlldr userid=user/pass control=load.ctl log=load.log
这样可以确保无论操作系统的全局配置如何,当前脚本都拥有正确的字符集环境，避免了因不同用户登录环境差异导致的不可预测错误。
希望以上方案能帮助您彻底解决 SQL*Loader 导入中文数据的报错问题，如果您在操作过程中遇到其他具体的错误代码，欢迎在评论区留言，我们可以进一步探讨具体的排查思路。
