Oracle Database Character Set settings

Garbled characters in the oracle11g Character SetSystem Environment: win7 flagship edition. oracle11g is installed today and there are two installation files Win32_11gr2_database_1of2.zip
Win32_11gr2_databasesilicate f2.zip
After decompression, each file has a database file that overwrites the second database file to the first one. Click setup.exe to install it directly. During the installation process, because the UTF-8 character set will be used in the future development process, the UTF-8 character set is selected during installation (the default is GBK, and 10 Gb does not need to select the character set encoding method ). After the installation is complete, connect to Oracle under DOS. Everything works normally. However, when you connect to Oracle using PL/SQL Dev, the following prompt appears: The general meaning is that the character set of the database is al32utf8 client character set is zhs16gbk and must be modified in the registry: The specific modification method is as follows:

Oracle11g changed the character set al32utf8 to zhs16gbk

Database character set (al32utf8) and client character set (zhs16gbk) are different.
Character Set conversion may cause unexpected results.
Note: You can set the client character set through the nls_lang environment variable or the nls_lang registry key in
HKEY_LOCAL_MACHINE \ SOFTWARE \ oracle \ key_oradb11g_home1.

Simplified chinese_china.zhs16gbk contains american_america.al32utf8.
This is not a problem of modifying the character set of the client. The character set of the database to be modified. I am oracle11g in my notebook, so I am very brave:
SQL> Conn/As sysdba
SQL> shutdown immediate;
SQL> startup Mount
SQL> alter system enable restricted session;
SQL> alter system set job_queue_processes = 0;
SQL> alter system set aq_tm_processes = 0;
SQL> alter database open;
SQL> alter database character set zhs16gbk;
ORA-12712: new character set must be a superset of old Character Set
Note: The new character set must be a superset of the old one. In this case, we can skip the superset check and make changes:
SQL> alter database character set internal_use zhs16gbk;
-- We can see that this process is exactly the same as the internal process of the alter database character set operation. That is to say, the help provided by internal_use is that the Oracle database bypasses the validation of the subset and superset.
SQL> select * from V $ nls_parameters;
SQL> shutdown immediate;
SQL> startup
SQL> select * from V $ nls_parameters;