由于ORACLE提供了字符集的转换功能，因此数据库字符集与客户端NLS_LANG设置不同是可以接受的，前提条件是数据库的字符集必须是客户端NLS_LANG设置字符集的超集，那么由于客户端使用的字符是属于数据库字符集中的一部分，因此不会产生转换时数据丢失及乱码的情况。
例如：对于一个需要存储简体文信息的数据库来说，它的字符集设置和客户端NLS_LANG设置一般可以使用ZHS16GBK编码。但是如果数据库字符集选用了UTF8的话，也是可以的，因为ZHS16GBK编码属于UTF8的子集。ORACLE在数据库与客户端进行数据交换时自动进行编码的转换，在数据库中实际存储的也是UTF8编码的数据。此时其它数据库和此数据库也可以正常的进行数据交换，因为ORACLE会自动进行数据的转换。在实际使用中，遇到过繁体XP的字符集ZHT16MSWIN950转换成AL32UTF8字符集时，一些特殊的字符和个别冷僻的汉字会变成乱码。后来证实是XP需要安装一个字库补丁软件，最后顺利解决此问题。
结论：对于数据库字符集为UTF8，而客户端采用本地字符集的情况，最好进行测试验证，因为UNICODE标准本身发展很快，一些客户端的操作系统对UNICODE标准支持的力度不一致，有些操作系统支持不好，有些特殊字符在转换后会产生乱码。由于这个话题已经超出了本文的范畴，在此就不详细讨论了。
4.2.3、客户端NLS_LANG与本地化环境不同引起的乱码：
一般情况下，客户端NLS_LANG与本地化环境采用了不同的字符集会出现乱码，除非本地化环境的字符集是客户端NLS_LANG设置字符集的子集。如果把客户端NLS_LANG设置为UTF8就属于这种情况，由于目前还没有可以直接使用UNICODE字符集的操作系统，因此客户本地化环境使用的字符集只能是某种语言支持的字符集，它属于UTF8的子集。下面我们就着重讨论这种情况。
虽然目前WINDOWS的内核是支持UNICODE的，但是WINDOWS并不支持直接显示UNICODE编码的字符,而且它并不知道目前的字符采用了何种字符集，所以默认情况下，它使用缺省的代码页来解释字符。因此，对于其它类型的编码，需要先进行转换，变成系统目前的缺省代码页支持的字符集才能正常使用。
WINDOWS中的缺省代码页是由控制面板设置中的语言及区域的选择所决定的，属于客户本地化的环境设置。简体中文WINDOWS的字符编码就是GBK，它的缺省代码页是936。对于其它非WINDOWS的操作系统，我们可以把它们目前缺省使用的字符集作为用户的本地化环境设置。另外，我们使用的大部分工具，如写字板，SQL*PLUS等，它们没有提供编码转换功能，因此在客户端直接输入或查询数据往往都会遇到乱码的问题，必须由应用程序或一些工具去做编码的转换，才能保证正常的使用。比如SQL*PLUS遇到的问题，我们在4.1节中已经进行了详细的论述。
5、最后的结论及建议：
以上不厌其烦的列举了种种因为选用了不恰当的数据库字符集而出现的问题，最后总结归纳起来，以下几点就是我个人的建议了：
1) 一般情况下，建议优先考虑客户的本地化环境，选用本地通用的字符集作为数据库的字符集和客户端NLS_LANG的设置，使得数据库、客户端NLS_LANG、客户端操作系统三者的字符集可以完全兼容，这样出现的问题和麻烦最少。就简体中文而言，目前最常用的字符集是ZHS16GBK，建议大家选用。
2) 如果系统需要支持多语言，采用了UNICODE标准，那么ORACLE数据库字符集在版本9以上可以选用AL32UTF8，如果涉及到ORACLE8及8i的数据库，字符集可以选用UTF8。
3) 如果应用程序完全支持UNICODE，可以根据客户的本地化环境自动转换编码，则客户端的NLS_LANG可以设置成和数据库服务器端字符集完全一致。如果应用程序不能自动进行编码的转换或需要在客户端进行一些管理维护活动，则建议把客户端的NLS_LANG设置成本地环境使用的字符集，由ORACLE来进行编码的转换工作。此时需要对客户端的操作系统进行验证测试，因为目前各个操作系统对UNICODE标准支持的程度不同，有时会出现一些特殊字符转换不正常的情况。