企业官网建设流程全解析

开头可以直接从实际工作中遇到的乱码问题切入，讲清楚字符集对Oracle数据库的影响，以及什么时候需要修改字符集。这样既能快速抓住目标读者，又能自然引出后文。

1. 为什么需要修改字符集

先讲一个我真实遇到过的场景。

几年前我接手一个老系统，数据库是Oracle 10g，字符集ZHS16GBK。业务方反馈说页面上的中文偶尔变成问号，导出的报表里某些生僻字显示成"？？"，排查了一圈发现根因就是字符集。后来业务系统要纳入东南亚地区的数据，里面包含泰文、越南文，ZHS16GBK根本装不下这些字符集编码，只能启动字符集迁移。

字符集这个东西，平时没人关注，一旦乱码或者要接新语言的业务，就成了绕不开的坎。对Oracle数据库来说，字符集决定了三件事：数据在库里的存储编码方式、客户端拿到数据后如何解码、数据库与外部系统交互时的字符映射。这三件事任何一个环节对不上，轻则显示乱码，重则直接报ORA-12712、ORA-12720这类错误。

为什么要修改字符集，总结起来无非几种情况：

• 建库时选的字符集不符合业务需求，后期发现装载不了新语言的字符。
• 跨系统数据迁移时，源库和目标库字符集不一致，导入导出数据乱码。
• 系统合并或数据中心整合，需要把多个数据库统一到同一字符集。
• 老旧系统从GBK、UTF8单字节/双字节字符集升级到更通用的AL32UTF8。

这篇文章适合谁看？一是要处理乱码问题的DBA，二是负责数据库升级或迁移的运维工程师，三是刚接触Oracle、被字符集概念绕晕的初学者。我会把修改字符集的完整流程、核心原理、常见报错和排查方法都讲透，包括那些只能在实操里踩出来的坑。

2. 字符集核心概念与修改前的判断

2.1 数据库字符集与国家字符集的区别

Oracle里有两套字符集容易混：一套是数据库字符集（NLS_CHARACTERSET），另一套是国家字符集（NLS_NCHAR_CHARACTERSET）。

数据库字符集用于存储VARCHAR2、CHAR等类型的数据。国家字符集用于存储NVARCHAR2、NCHAR类型的数据。绝大多数业务表用的是VARCHAR2，所以真正关键的是数据库字符集。国家字符集一般在建库时选定，不涉及业务数据时很少动它。

查看当前字符集的常用SQL：

SELECT * FROM nls_database_parameters WHERE parameter IN ('NLS_CHARACTERSET','NLS_NCHAR_CHARACTERSET');

或者用简写：

SELECT userenv('language') FROM dual;

前者能直接看到两个字符集的名称，后者则展示会话级语言和字符集信息，比如SIMPLIFIED CHINESE_CHINA.ZHS16GBK。

2.2 常见字符集与其适用场景

Oracle世界常见的字符集有这几个：

ZHS16GBK是双字节字符集，兼容GB2312标准，支持简体中文和大部分繁体汉字。国内老系统绝大多数用的是这个，优点是每个汉字占两字节，存储紧凑，缺点是无法直接存储泰文、越南文等非汉字字符。

AL32UTF8是可变长度字符集，也是Oracle官方推荐的中文环境标准字符集。ASCII字符占1字节，大部分汉字占3字节，从ZHS16GBK迁到AL32UTF8，存汉字的字段空间占用会变大，这一点做容量规划时必须考虑。

UTF8在Oracle里特指老版UTF-8实现，不推荐新建库时使用，官方已经在后续版本里默认推AL32UTF8。

其他如WE8ISO8859P1、WE8MSWIN1252都是西欧单字节字符集，国内接触较少，不做深入展开。

判断字符集是否够用，有一条经验法则：如果业务涉及的语言字符超出当前字符集码位范围，就必须改。比如ZHS16GBK转储泰文，泰文字符在ZHS16GBK中根本没有对应的编码，写入必乱。

2.3 超集关系：修改字符集的底线

Oracle修改字符集有一条硬性规定：目标字符集必须是当前字符集的超集。超集就是这个字符集包含另一个字符集的全部字符，并且编码一致。

比如AL32UTF8是ZHS16GBK的超集吗？是。ZHS16GBK包含的所有汉字，在AL32UTF8中都有对应的Unicode码位，且编码规则一致，所以可以从ZHS16GBK直接ALTER到AL32UTF8。反过来就不行，从AL32UTF8降到ZHS16GBK，万一数据里包含AL32UTF8独有的字符（如某些CJK扩展汉字），转换后无法表示，Oracle直接拒绝执行。

这也是为什么那么多ZHS16GBK系统最终都迁到AL32UTF8——这是单向可行的升级路线。

3. 修改前的完整准备工作

3.1 用CSSCAN评估字符集转换风险

修改字符集最怕的不是操作失败，而是数据在转换后出现无法还原的损坏。Oracle自带的CSSCAN工具就是用来评估这种风险的。

CSSCAN全称Character Set Scanner，在$ORACLE_HOME/bin目录下。它不直接修改数据，只扫描当前数据库中哪些数据在目标字符集下会产生转换问题。它需要一个回答文件来指定参数，典型内容如下：

FULL=Y USERID=system/oracle ARRAY=1024 PROCESS=3 LOG=ccscan.log

然后执行：

csscan system/oracle FULL=Y LOG=ccscan LOG=cc

命令执行完成后，会生成几个日志文件，重点看ccscan.log。里面分三部分：

• Conversions：表示可以转换的数据行数。
• Exceptions：表示转换后可能丢失或损坏的数据行数。
• Errors：表示完全无法转换的数据行数。

Exceptions和Errors部分是重点。如果数量为0，可以放心直接ALTER；如果有少量Exceptions，需要先定位到具体表和具体行，单独处理；如果数量较大，意味着这个库不适合直接改字符集，必须走数据迁移方案。

3.2 数据备份的最佳方案

在修改字符集之前，备份是最后一道防线。我建议做全量物理备份加逻辑备份的双保险。

物理备份用RMAN进行：

rman target / BACKUP DATABASE PLUS ARCHIVELOG;

逻辑备份用数据泵：

expdp system/oracle DIRECTORY=DMP_DIR DUMPFILE=pre_charset_full.dmp FULL=Y LOGFILE=pre_charset_full.log

有人觉得做了RMAN就不需要expdp，实际操作中我遇到过物理备份恢复后字符集标记仍是旧值的情况（因为备份文件本身也记录字符集信息），需要额外处理。而expdp导出的是逻辑数据，导入到新环境时按目标字符集重新写入，这种迁移路径更干净。

所以我的建议是：如果库比较小，直接以expdp逻辑导出为主；如果库很大，以RMAN物理备份为主，同时挑几个核心业务表做expdp局部导出用于验证。

3.3 关闭应用连接与会话检查

字符集是在线操作，但绝不能在有活跃业务事务时执行。需要确保没有应用连接正在读写数据。

先通过v$session确认连接情况：

SELECT sid, serial#, username, status, machine, program FROM v$session WHERE username IS NOT NULL;

如果有业务会话，需要通知应用方停止服务或断开连接池。等v$session里只剩DBA自己的会话后，才能进入下一步。这里有一个容易忽略的细节：应用程序的连接池即使应用停了，连接也可能保持在空闲状态，不会自动断开。稳妥做法是在运维窗口直接重启应用服务器，或者用alter system kill session逐个清理。

3.4 监听器和环境的静态检查

除了数据库本身，客户端工具和中间件的字符集环境也需要提前检查。Linux上通过环境变量确认：

echo $NLS_LANG

如果没有设置或值不对，设置成和目标字符集一致：

export NLS_LANG="SIMPLIFIED CHINESE_CHINA.AL32UTF8" export ORACLE_SID=orcl

Windows下的注册表也可能记录NLS_LANG，检查注册表路径HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\下的NLS_LANG键值。客户端和数据库字符集不一致时，即使数据库修改成功，客户端工具连接后显示出来仍然是乱码。

4. 字符集修改实操流程

4.1 方案选择：ALTER DATABASE还是UPDATE props$

当数据库当前字符集与目标字符集满足超集关系时，最推荐的方式是ALTER DATABASE CHARACTER SET。它的原理是更新数据字典里的字符集标记，并不逐行转换数据，所以执行速度很快。

还有一种改法：UPDATE props$表，直接修改Oracle内部属性表。这种方式的适用场景很窄，多见于从高版本字符集降级到低版本的逆向操作，或者ALTER DATABASE因为某些版本Bug无法执行时的应急手段。操作稍有不慎，会导致所有数据字典中的字符集信息与真实数据编码不一致，严重时数据库无法启动。非必要不推荐，本文不过多展开，只提醒大家知道有这条路径，但是不要轻易用。

4.2 标准修改步骤详解

以下是Oracle 11g/12c/19c单实例环境的标准修改流程，一个单库修改字符集的完整操作顺序。

第一步，以DBA身份登录SQL*Plus：

sqlplus / as sysdba

第二步，关闭数据库并启动到mount状态：

shutdown immediate; startup mount;

第三步，开启受限会话模式，防止新会话进入：

alter system enable restricted session;

第四步，打开数据库：

alter database open;

第五步，确认当前字符集：

SELECT name, value$ FROM sys.props$ WHERE name LIKE 'NLS%CHARACTERSET';

第六步，执行字符集修改：

alter database character set AL32UTF8;

如果目标字符集不是当前字符集的超集，这里会直接报ORA-12712。如果库里有特殊字符集定义（如CHAR_CS），可能还会遇到其他错误，下文会列。

第七步，关闭受限模式：

alter system disable restricted session;

第八步，重启数据库，让所有参数重新加载：

shutdown immediate; startup;

第九步，验证修改结果：

SELECT * FROM nls_database_parameters WHERE parameter LIKE '%CHARACTERSET%';

完整的操作序列，从第一步到第九步，正常情况下一分钟内可以执行完。真正耗时间的不是SQL本身，而是前期的会话清理、备份和客户端的协调沟通。

4.3 从ZHS16GBK到AL32UTF8的注意事项

这个迁移方向是目前国内最常见的案例。有一点必须先想清楚：ZHS16GBK一个汉字占2字节，AL32UTF8一个汉字占3字节。如果原来某个表VARCHAR2(100)存满了100个汉字，迁移到AL32UTF8后需要300字节，而字段长度限制仍是100字符，Oracle的字符语义和字节语义在这一步会产生差异。

举个例子：SQL> ALTER TABLE test MODIFY name VARCHAR2(100 CHAR)；如果你原表用的是VARCHAR2(100)（默认按字节计），数据迁移后会因为最高长度限制报ORA-12899。必须在迁移前把所有含有中文的VARCHAR2字段改为CHAR语义或加大长度。这个检查可以用下面的SQL批量查出来：

SELECT owner, table_name, column_name, data_type, char_length, char_used FROM dba_tab_columns WHERE data_type='VARCHAR2' AND char_used='B' AND owner NOT IN ('SYS','SYSTEM');

类似的，字段索引长度也会受影响。Oracle索引条目最大长度有限制，原来恰好踩线的索引，字符集切换后可能超出限制，要及时检查并重建。

4.4 国家字符集（NLS_NCHAR_CHARACTERSET）的调整

数据库字符集改完，如果国家字符集也想调整，比如从UTF8改成AL16UTF16，需要使用另一条语句：

alter database national character set AL16UTF16;

这条语句的执行条件和数据库字符集类似，要求目标字符集是当前国家字符集的超集。但问题在于，国家字符集一般只在NVARCHAR2、NCHAR类型上用，而大多数国内业务场景的NVARCHAR2都是历史遗留设计，新开发的项目基本都用VARCHAR2。所以如果没有实际的NVARCHAR2类型字段，通常不建议动国家字符集，动它的收益很小，风险却不少。

5. 常见报错与排查实录

5.1 ORA-12712：目标字符集必须是当前字符集的超集

完整报错信息是：

ORA-12712: new character set must be a superset of old character set

这是出现频率最高的错误，原因就是目标字符集不包含当前字符集的所有字符。典型场景是试图从AL32UTF8降级到ZHS16GBK。遇到这个错误，先确认修改方向是否正确。如果确需降级，你需要走全量数据导出的迁移方案，不能直接ALTER。

5.2 ORA-12720：新旧字符集不能相同

报错信息：

ORA-12720: new character set must be different from old character set

这个错误比较低级，通常是目标字符集名字写错了。比如库里当前是AL32UTF8，你写成了ALTER DATABASE CHARACTER SET UTF8，看起来都是UTF8，实际上是两个不同的字符集名称，Oracle会按不同的对象处理。要么拼写错误，要么记错了当前字符集，先查清楚再操作。

5.3 ORA-12721：RAC和Data Guard环境下的限制

在RAC环境下，所有实例都需要先关闭，只保留一个实例启动到mount状态执行修改。在Data Guard环境下，需要先停止日志应用，否则主备结构会产生不一致。解决办法很明确：RAC数据库改字符集时，关闭所有节点（包括scan listener），单实例启动操作；Data Guard下，在备库执行ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL，修改完主库后，要把备库也重建（因为数据文件中的字符集信息已经变了，备库无法通过redo自动同步）。

5.4 修改后客户端仍显示乱码

数据库字符集已经改好了，业务人员反馈页面还是乱码，这类问题最常见的原因在三个位置。

一是客户端的NLS_LANG。SQL*Plus、PL/SQL Developer、Navicat都有各自的字符集处理方式，必须把客户端的NLS_LANG设置成和目标字符集一致。PL/SQL Developer在Tools -> Preferences -> NLS Options里设置；Navicat一般通过连接属性的Encoding设置。

二是JDBC连接串。Java程序连接Oracle时，JDBC驱动会读取数据库字符集，但如果连接串中显式指定了characterEncoding或oracle.jdbc.defaultNChar，就可能覆盖默认值。检查应用配置文件里是否有类似characterEncoding=UTF-8的设置，Java侧尽量保持与数据库一致。

三是中间件编码转换层。应用服务器（WebLogic、Tomcat）的URIEncoding参数，以及HTTP请求和响应的Content-Type中charset设置，都可能影响最终中文显示。数据库层面干净不代表应用层面干净，排查时要从数据库往客户端往应用方向逐层查。

5.5 修改过程中实例异常中断的处理

如果在执行alter database character set过程中实例重启或断电，数据库可能停留在字符集信息不一致的状态，严重时无法正常打开。遇到这种情况，先尝试shutdown abort后重新startup mount，看数据库能否正常进入mount状态。如果能mount，重新执行一次完整流程。如果连mount都不行，就需要从RMAN备份做不完全恢复，恢复到一个固定时间点（执行修改之前），然后把整个流程再走一遍。

5.6 修改后触发器、包和视图的重编译

字符集修改后，数据字典里的对象状态可能会变成INVALID。原因是存储过程、函数、触发器、视图的定义文本中原本按旧字符集解析的信息，在字符集切换后需要重新解析。

出现INVALID对象的概率不高，但一旦出现，需要在修改完成后执行一次全库对象重编译：

utl_recomp.recomp_parallel(4);

如果嫌麻烦，最省事的办法是执行$ORACLE_HOME/rdbms/admin/utlrp.sql脚本，正常环境几分钟内能完成。

6. 修改字符集后的验证和收尾工作

6.1 全库数据验证的核心思路

字符集修改完成不代表万事大吉，必须以数据为判断依据。

先做技术层验证：确认NLS_DATABASE_PARAMETERS中的两个字符集参数为目标值，确认告警日志文件alert_ .log中没有ORA-错误记录。

再做业务数据验证：导出几张小表的前几百行，对比修改前后的中文内容是否一致。重点检查生僻字、全角标点、特殊符号这三类高风险数据。如果库里有CLOB字段，一定单独抽查CLOB内容，因为CLOB的字符集处理本身就比普通VARCHAR2复杂。

6.2 应用系统回归测试清单

数据库改动后，应用系统的回归测试必不可少。下面的清单是实践总结出来的必测项：

• 中文字段的增删改查，尤其是页面表单提交的中文内容。
• 报表导出环节，Excel、CSV、PDF三类格式的中文与特殊字符显示。
• 接口交互环节，与外部系统通过XML、JSON、WebService传输的中文数据。
• 短信、邮件通知中的中文，这部分容易在网关层面出现编码转换。
• 旧数据查询，日期、金额之外，重点检查带有备注、描述、说明类文本字段。
• 权限和审计日志，确认用户中文名、应用模块中文名是否正常显示。

6.3 恢复回滚预案

即使做了充分准备，仍然要准备好回滚方案。最稳妥的回滚方式是RMAN恢复。一旦发现修改字符集后业务数据出现大面积损坏，立即执行：

RMAN> STARTUP FORCE MOUNT; RMAN> RESTORE DATABASE; RMAN> RECOVER DATABASE; RMAN> ALTER DATABASE OPEN RESETLOGS;

如果做的是expdp逻辑导出，回滚方案是重建一个原字符集的数据库，导入导出数据，切换连接。对比两种方式，RMAN的恢复速度更快，逻辑导入的方式更灵活，但需要重新搭建环境。无论哪种方式，前提都是修改前有完整备份。

我个人在实际操作中有一个习惯：把修改前的数据库静态信息导出一份保留，包括v$parameter中的字符集相关参数、props$表中所有NLS开头的记录、数据库版本、组件列表。这些信息在回滚时能快速确认数据库是否回到了修改前的状态。

7. 延展：关于字符集迁移的其他场景

7.1 数据库升级与字符集修改的顺序问题

如果数据库既要做版本升级，又要改字符集，先后顺序值得提前考虑。我的经验是：先升级版本，后改字符集。理由很简单：新版本对字符集的支持面更广，从旧版升级到目标版本后，再执行ALTER DATABASE CHARACTER SET更稳妥，报错概率更低。反过来先改字符集再升级，步骤多一层风险，而且升级工具在跨版本时对字符集的校验也更严格。

7.2 多租户环境（PDB）的字符集修改

Oracle 12c以上支持多租户架构，PDB可以设置独立的字符集。Oracle 12.2以上也允许多个PDB拥有不同字符集，前提是它们的字符集与CDB的字符集兼容。

在PDB内修改字符集，需要先切换到对应PDB：

ALTER SESSION SET CONTAINER = pdb1; ALTER DATABASE CHARACTER SET AL32UTF8;

注意，如果你有多个PDB，需要在每个PDB里分别执行，不能指望CDB层面一条命令全改。而且PDB的字符集修改前同样需要确认超集关系和数据可转换性。

7.3 云数据库和托管数据库的限制

如果是云平台提供的Oracle数据库服务，比如Oracle Cloud、阿里云RDS for Oracle，修改字符集通常会受到平台限制。有的平台允许用户自助修改，有的则禁止ALTER DATABASE CHARACTER SET，只能提工单由平台方操作。建议在购买服务之前就确认好字符集选择，因为云数据库后期改字符集的成本远高于自建库。

8. 最后的几点体会

做了这么多年数据库运维，我的感触是：修改字符集不是一个高频率操作，但每一次遇到都是关键任务。它不像加索引、调参数那样可逆性强，一旦执行出错，代价是数据层的。

真正有价值的经验不是会执行那条ALTER语句，而是能够准确回答：为什么需要改？改了之后存储空间变化多大？如何在不影响业务的情况下找到停机窗口？怎么验证数据没有在无声无息中损坏？

如果看完这篇文章你只能记住三点，我希望是：

第一，修改前至少做两种备份，RMAN物理备份加expdp逻辑导出，防止意外。

第二，执行前用CSSCAN确认数据可转换性，避免掉进超集关系的坑。

第三，改完不是结束，客户端NLS_LANG、JDBC连接、应用层编码这三处都要联动调整，否则数据库改好了，业务看到的还是乱码。

字符集的问题，本质上是一致性的问题。把数据库这一端做好了，把客户端那一端对整齐了，整个链路才能真正稳定运行。