Cela fonctionne parce que les conditions suivantes sont toutes les deux vraies :
- Le jeu de caractères client est égal au jeu de caractères de votre base de données.
- Le jeu de caractères autorise toutes les valeurs d'octet
Votre jeu de caractères de base de données et votre jeu de caractères client sont définis sur US7ASCII . Dans ce cas, chaque donnée est écrite/lue une par une sans aucune conversion, c'est-à-dire que les octets que vous envoyez sont exactement écrits dans la base de données. Vous n'avez probablement pas défini NLS_LANG du tout côté client mais Oracle le définit par défaut sur AMERICAN_AMERICA.US7ASCII .
US7ASCII est un encodage 7 bits. Je suppose qu'une application ASCII pure (qui pourrait être assez difficile à trouver) ignorerait simplement le 8e bit qui est stocké dans une architecture 8 bits. Autres jeux de caractères, par ex. AL32UTF8 n'autorisez pas chaque valeur d'octet. Dans ce cas, ces caractères seront remplacés par un espace réservé, par ex. ¿ ou ? .
Remarque, vous définissez votre jeu de caractères client sur US7ASCII ce qui n'est probablement pas correct. Réglez-le correctement sur le jeu de caractères utilisé par votre application, puis ° sera remplacé.
Si vous utilisez SQL*Plus, vérifiez la page de code de la console avec la commande chcp , rép. locale charmap . Définissez votre NLS_LANG variable d'environnement en conséquence avant de démarrer sqlplus.
