En général, tous vos points sont corrects. NLS_NCHAR_CHARACTERSET définit le jeu de caractères pour NVARCHAR2 , et. Al. colonnes alors que NLS_CHARACTERSET est utilisé pour VARCHAR2 .
Pourquoi est-il possible que vous voyiez des caractères chinois avec
US7ASCII?
La raison en est que votre jeu de caractères de base de données et votre jeu de caractères client (c'est-à-dire voir NLS_LANG valeur) sont tous deux US7ASCII . Votre base de données utilise US7ASCII et il "pense" aussi que le client envoie des données en utilisant US7ASCII . Ainsi, il ne fait aucune conversion des chaînes, les données sont transférées bit par bit du client au serveur et vice versa.
De ce fait, vous pouvez utiliser des caractères qui ne sont actuellement pas pris en charge par US7ASCII . Sachez que si votre client utilise un jeu de caractères différent (par exemple, lorsque vous utilisez le pilote géré ODP.NET dans une application Windows), les données seront nulles ! De même, si vous envisagez une migration du jeu de caractères de la base de données, vous rencontrez le même problème.
Autre remarque :je ne pense pas que vous obtiendriez le même comportement avec d'autres jeux de caractères, par ex. si votre base de données et votre client utiliseraient tous les deux WE8ISO8859P1 par exemple. Sachez également que vous avez en fait une mauvaise configuration. Votre base de données utilise le jeu de caractères US7ASCII , votre NLS_LANG la valeur est également US7ASCII (très probablement, il n'est pas défini du tout et Oracle le définit par défaut sur US7ASCII ) mais le jeu de caractères réel de SQL*Plus, resp. votre cmd.exe terminal est très probablement CP950 ou CP936.
Si vous souhaitez tout définir correctement, vous pouvez soit définir votre variable d'environnement NLS_LANG=.ZHT16MSWIN950 (CP936 semble ne pas être pris en charge par Oracle) ou modifiez votre page de codes avant d'exécuter sqlplus.exe avec la commande chcp 437 . Avec ces paramètres appropriés, vous ne verrez aucun caractère chinois comme vous l'auriez probablement prévu.
