ORA-12704字符集不匹配报错，远程帮忙修复故障经验分享

这个ORA-12704的错误，我印象里最深的一次是帮一个外地开网店的朋友处理的，他不是搞技术的，但他的电商网站后台突然瘫痪了，页面上老是弹出一个他看不懂的数据库错误，就是ORA-12704，他急得不行，因为正好赶上做活动，订单没法处理,直接给我打来了视频电话求助。

我让他把完整的错误信息截图发给我，错误信息大概说的是，在某个查询语句里，进行UNION或者WHERE条件比较的时候，字符集不匹配，具体是两个部分，一边是NCHAR类型的数据，另一边是普通的VARCHAR2类型的数据，数据库不知道该怎么把这两种“口音”不同的文字放在一起比较，所以就报了错。（来源：基于Oracle官方文档对ORA-12704错误的通用描述）

因为是远程，我第一件事就是让他帮我看看他数据库的字符集设置，我一步一步教他如何用数据库管理工具（他用的PL/SQL Developer）执行一个简单的查询：SELECT * FROM NLS_DATABASE_PARAMETERS WHERE PARAMETER LIKE '%CHARACTERSET%';，他查完告诉我，数据库的字符集是AL32UTF8，这是现在比较通用的Unicode字符集，按理说兼容性很好，这就有点奇怪了，既然数据库底层设置没问题,那问题大概率出在具体的SQL语句或者某个表字段的定义上。

我让他找到最近一次更新或者新上线的功能，特别是涉及到数据库查询的那部分代码，他回忆说，就在出错前几个小时，他们的程序员刚更新了一个会员查询的功能，说是能更快地根据姓名和昵称搜索用户，我一听“姓名”和“昵称”，就觉得可能是这里的问题,因为中文环境下的字符集问题很常见。

我让他把那段新写的SQL代码发给我看，果然，在代码里我发现了一个关键点：在WHERE条件中，程序将一个用户输入的字符串（张三’）直接和一个表里的字段进行比较，这个用户输入的字符串，在程序里被默认处理成了国家字符集类型（比如NVARCHAR2），而数据库表里的那个字段，定义的是普通的VARCHAR2类型，虽然它们看起来都是存中文，但在数据库内部，AL32UTF8字符集下的VARCHAR2字段和作为国家字符集的NVARCHAR2字段，被认为是两种不同的编码方式，当SQL语句试图把N'张三'（NVARCHAR2类型）和customer_name（VARCHAR2类型）用等号连接时，ORA-12704错误就蹦出来了。（来源：常见开发错误场景，将绑定变量或字面量误定义为NCHAR/NVARCHAR2类型与基表VARCHAR2字段比较）

问题根源找到了，解决办法就有好几个选择，最简单的办法，我让他转告他们的程序员，修改SQL语句，确保比较的双方字符集类型一致，要么，把那个用户输入的值从国家字符集类型转换成和数据库字段一样的字符集，比如使用TO_CHAR函数：WHERE customer_name = TO_CHAR(:input_name)，要么，更彻底一点，如果业务上没有特殊要求，直接去掉用户输入值前面的N前缀，让它也变成普通的VARCHAR2类型，我建议他们采用第一种微调SQL的方式，因为改动最小,可以最快让系统恢复。

为了保险起见，我还让他帮忙检查了一下那个customer_name字段所在的表，确认没有其他字段被错误地定义成了NCHAR或NVARCHAR2类型，而其他大部分字段都是VARCHAR2，避免以后再次出现类似问题，他检查后说没有,这下就放心了。

他们的程序员按照我说的修改了代码，重新部署后，网站后台立刻就恢复正常了,我朋友总算松了一口气。

通过这次远程帮忙，我总结了几条给非技术朋友或者初级开发者的简单建议：第一，当出现字符集错误时，别慌，先看完整的错误信息，它会告诉你大概在哪个操作上出了问题，第二，了解一下自己数据库的“普通话”是什么（即数据库字符集和国家字符集设置），第三，也是最关键的，写SQL语句的时候，尽量让比较的“苹果对苹果，梨对梨”，确保数据类型和字符集类型一致，如果要从根本上避免，在设计数据库表的时候，就要统一规划好字符集的使用，除非有存储多国语种的特别需求，否则尽量使用统一的字符集类型，比如全部使用VARCHAR2，这样能省去很多麻烦，这次经历也让我觉得，有时候复杂的错误，根源往往就是一个很小、很基础的细节没注意到。