En general todos tus puntos son correctos. NLS_NCHAR_CHARACTERSET define el conjunto de caracteres para NVARCHAR2 , et. Alabama. columnas mientras que NLS_CHARACTERSET se usa para VARCHAR2 .
¿Por qué es posible que vea caracteres chinos con US7ASCII? ?
El motivo es que el conjunto de caracteres de su base de datos y el conjunto de caracteres de su cliente (es decir, consulte NLS_LANG value) son ambos US7ASCII . Su base de datos usa US7ASCII y "piensa" que el cliente también envía datos usando US7ASCII . Por lo tanto, no realiza ninguna conversión de las cadenas, los datos se transfieren bit a bit del cliente al servidor y viceversa.
Debido a ese hecho, puede usar caracteres que en realidad no son compatibles con US7ASCII . Tenga en cuenta que, en caso de que su cliente use un conjunto de caracteres diferente (por ejemplo, cuando use el controlador administrado ODP.NET en una aplicación de Windows), ¡los datos serán basura! Además, si considera la migración de un conjunto de caracteres de la base de datos, tiene el mismo problema.
Otra nota:no creo que obtenga el mismo comportamiento con otros conjuntos de caracteres, p. si su base de datos y su cliente usaran WE8ISO8859P1 por ejemplo. También tenga en cuenta que en realidad tiene una configuración incorrecta. Su base de datos utiliza el conjunto de caracteres US7ASCII , su NLS_LANG el valor también es US7ASCII (Lo más probable es que no esté configurado en absoluto y Oracle lo tenga por defecto en US7ASCII ) pero el juego de caracteres real de SQL*Plus, resp. su cmd.exe Lo más probable es que el terminal sea CP950 o CP936.
Si desea configurar todo correctamente, puede configurar su variable de entorno NLS_LANG=.ZHT16MSWIN950 (CP936 parece no ser compatible con Oracle) o cambie su página de códigos antes de ejecutar sqlplus.exe con el comando chcp 437 . Con esta configuración adecuada, no verá ningún carácter chino como probablemente hubiera esperado.
