ODBC et NLS_LANG

Question

Disons que j'ai créé deux programmes exécutables différents, par ex. en C++.

Pour une raison quelconque, la représentation interne du texte des deux programmes est différente l'une de l'autre. Supposons que le premier programme utilise la représentation textuelle A et l'autre représentation textuelle B. Il peut s'agir d'une page de code ANSI 8 bits spécifique, Unicode/UTF-8 ou Unicode/UTF-16 ou autre.

Désormais, chaque programme souhaite communiquer du texte (ajouter/extraire des données) vers/depuis la même table de base de données sur un serveur (de base de données). Chaque programme communique avec la base de données via ODBC. Les programmes ne connaissent donc pas le système de base de données avec lequel ils communiquent.

Dans ce cas précis, la base de données est en fait une base de données Oracle RDMS et l'administrateur du serveur de base de données a configuré la base de données pour utiliser UTF-8. Sur le système sur lequel les programmes s'exécutent, un pilote ODBC approprié est disponible, de sorte que les programmes peuvent se connecter via ODBC. Chaque programme traitera et convertira de manière appropriée le type de données ODBC SQL_C_CHAR vers sa représentation de texte interne. Je suppose que les programmes ne peuvent pas faire autrement que supposer un codage spécifique retourné pour le texte SQL_C_CHAR. Si ce n'est pas le cas, les programmes doivent être informés du codage.

Pour Oracle, je sais que la variable d'environnement NLS_LANG peut être utilisée sur le client. Je suppose qu'il affecte le pilote ODBC (lié à SQL_C_CHAR) pour convertir d'un codage spécifique (tel que donné par NLS_LANG) au codage interne de la base de données (dans cet exemple UTF-8) et vice-versa. Si la machine qui exécute mes programmes a un NLS_LANG, ce paramètre affectera les séquences d'octets renvoyées pour SQL_C_CHAR afin que mes programmes ne puissent pas assumer un codage spécifique pour le texte renvoyé via SQL_C_CHAR. Est-il possible de configurer la connexion ODBC (de préférence par programmation au moment de l'exécution), de sorte qu'elle prenne en charge les conversions de texte pour les deux programmes, à savoir de/vers la représentation UTF-8 et de/vers la représentation B de/vers UTF-8?

Cordialement, /Michael

PS. Comme les programmes se connectent via ODBC, je ne pense pas qu'il serait bon qu'ils aient maintenant quelque chose à propos de NLS_LANG car c'est une variable d'environnement spécifique à Orcacle.

Answer 1

Vous devez créer votre application avec la macro UNICODE définie (voir les fichiers d'en-tête sql comme sqltypes.h et sqlucode.h). Cela modifie les appels à SQLxxx qui sont normalement mappés à SQLxxxA (ANSI) à SQLxxxW et ils utilisent donc les API Wide Character. Cela signifie que vous pouvez passer unicode (bien encodé données UCS2) aux API SQL et combiné avec l'extraction de colonnes de chaînes comme SQL_WCHAR vous obtiendrez des données larges à partir de récupérations. Je l'ai peut-être manqué mais je ne vous vois pas mentionner une plate-forme (Windows ou UNIX) et cela peut faire une petite différence si par exemple vous êtes sur unix et n'utilisez pas le gestionnaire de pilotes unixODBC. Il y a des charges sur le site MS sur unicode et ODBC.

Il existe une explication raisonnable d'Oracle/Unicode/ODBC au Using the Easysoft ODBC-Oracle Driver with Unicode Data. Il explique ODBC et Unicode par Oracle/NLS_LANG dans un contexte C.