Oracle SQL Developer Environment encodage

Question

Je Oracle SQL Developer (01/03/07) et je suis en train de travailler avec une base de données qui utilise WE8ISO8859P1 encodage:

SELECT * FROM nls_database_parameters WHERE parameter = 'NLS_CHARACTERSET'; 

J'ai des problèmes avec des paquets d'économie qui contient des symboles unicode . Lorsque j'ouvre un paquet enregistré précédemment, tous les symboles Unicode sont positionnés sur '¿'.

Quels paramètres dois-je modifier pour que SQL Developer conserve ces symboles? J'ai essayé de définir le codage de l'environnement sur 'ISO-8859-15' et d'autres encodages, mais cela n'aidera pas.

Answer 1

Peut-être que vous pourriez avoir besoin de ce jeu de caractères migration

http://docs.oracle.com/cd/B10501_01/server.920/a96529/ch10.htm#1656

sur la documentation de l'Oracle

Answer 2

au moins pour ouvrir PKG dans SQL Developer, vous pouvez faire un essai rapide et voir si cela fonctionne: -

Modifiez le 'codage' du développeur SQL en 'unicode-utf-8' qui est maintenant la version par défaut des versions ultérieures.

Vous devrez éventuellement opter pour la migration de charset de base de données vers 'AL32UTF8' pour éviter d'autres problèmes (comme des données) dus à ce jeu de caractères.

Answer 3

Si vous regardez USER_SOURCE, vous verrez que le code source, tel qu'il est stocké/interprété par la base de données, se trouvera dans une colonne VARCHAR2, donc utilisez le jeu de caractères de la base de données. En tant que tel, votre code source devra être dans WE8ISO8859P1. En théorie, si le client et la base de données utilisent le même jeu de caractères, la base de données n'essaiera pas d'effectuer de traduction de jeu de caractères et vous pourrez peut-être faire une séquence d'octets WE8ISO8859P1 mais aura un sens en unicode. Cependant, à un moment donné, quelqu'un utilisera le mauvais client et il se cassera.

Vous n'avez pas besoin d'unicode pour les identificateurs etc dans le code, donc je suppose que c'est dans les littéraux de chaîne. Il est préférable de les stocker dans une table (colonne NVARCHAR2) et de les sélectionner dans le code plutôt que de les coder en dur. Si cela n'est pas possible, vous pouvez utiliser UNISTR et coder en dur les valeurs hexadécimales correspondantes.

Answer 4

Si votre base de données code un texte codé sur un seul octet non unicode (par exemple ISO-8859), tout symbole non présent dans la table de caractères sera considéré comme invalide et remplacé par un espace réservé. Vous ne pouvez pas revenir en arrière, l'information est perdue.

Cela peut être généralement travaillé lors du stockage de données, mais comme pour le code source, vous ne pouvez pas contrôler comment Oracle encoderait vos chaînes.

Si votre base de données est configurée pour utiliser un tel schéma de codage, vous n'êtes probablement pas censé écrire du code qui viole ses règles.