différence entre NLS_NCHAR_CHARACTERSET abd NLS_CHARACTERSET pour Oracle

j'ai une petite question, ici, que je voudrais savoir la différence entre
NLS_NCHAR_CHARACTERSET et NLS_CHARACTERSET paramètre dans oracle ??

à partir de ma compréhension NLS_NCHAR_CHARACTERSET est de type NVARCHAR types de données
et pour NLS_CHARACTERSET serait pour VARCHAR2 types de données.

j'ai essayé de le tester sur mon serveur de développement qui mes paramètres actuels pour CHARACTERSET est comme suit :-

PARAMETER                      VALUE
------------------------------ ----------------------------------------
NLS_NCHAR_CHARACTERSET         AL16UTF16
NLS_NUMERIC_CHARACTERS         .,
NLS_CHARACTERSET               US7ASCII

Puis j'ai inséré quelques caractères Chinois les valeurs dans la base de données. j'ai inséré les caractères dans une table appelée data_ et mise à jour de la colonne pour l'ADRESSE et ADDRESS_2 qui sont VARCHAR2 colonnes. Par droit de mon entente avec le réglage actuel pour NLS_CHARACTERSET US7ASCII , les caractères chinois ne devraient pas être pris en charge, mais il est toujours à l'affiche dans la base de données ?? ne NLS_NCHAR_CHARACTERSET prévalent sur cette ??

Merci.

Vous ne devez pas copier les captures d'écran. Copier/coller le texte à partir de SQL Plus et le format du code
ok noté. merci pour le tuyau 🙂

OriginalL'auteur Steven Tang Ti Khoon | 2016-04-19

  1. 6

    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 voyez des caractères Chinois avec US7ASCII?

    La raison en est, votre base de données de jeu de caractères et votre client de jeu de caractères (voir la section NLS_LANG valeur) sont à la fois US7ASCII. Votre base de données utilise US7ASCII et il "pense", aussi que le client envoie des données à l'aide de US7ASCII. Ainsi, il ne fait pas de conversion de chaînes de caractères, les données sont transférées de l'un-à-un à partir du serveur vers le client et vice-versa.

    En raison de ce fait vous pouvez utiliser des caractères qui ne sont pas réellement pris en charge par US7ASCII. Conscients que, dans le cas où votre client utilise un jeu de caractères différent (par exemple, lorsque vous utilisez ODP.NET Géré Pilote dans une application Windows) les données seront déchets! Aussi, si l'on peut considérer comme une base de données de jeu de caractères de la migration, vous avez le même problème.

    Une autre remarque: je ne pense pas que vous devriez avoir le même comportement avec les autres jeux de caractères, par exemple, si votre base de données et votre client serait d'utiliser WE8ISO8859P1 par exemple. Sachez également que vous avez réellement mauvaise configuration. Votre base de données utilise le jeu de caractères US7ASCII, votre NLS_LANG valeur est également US7ASCII (la plus probable, il n'est pas fixé à tous et Oracle par défaut à US7ASCII) mais le vrai jeu de caractères de SQL*Plus, resp. votre cmd.exe terminal est le plus susceptible CP950 ou CP936.

    Si vous voulez tout correctement, vous pouvez soit configurer votre variable d'environnement NLS_LANG=.ZHT16MSWIN950 (CP936 ne semble pas être pris en charge par Oracle) ou de changer votre page de codes avant d'exécuter sqlplus.exe avec la commande chcp 437. Avec ce bon de paramètres que vous ne pourrez pas voir les caractères Chinois que vous auriez probablement prévu.

    merci pour l'explication =) . je pense que je l'ai eu hehe 😉

    OriginalL'auteur Wernfried Domscheit