ODBC et NLS_LANG

Question

Supposons que j'aie créé deux programmes exécutables différents, par exemple en C++.

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

Maintenant, chaque programme veut communiquer du texte (ajouter/récupérer 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 par l'intermédiaire d'ODBC. Les programmes ne savent donc pas avec quel système de base de données 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.

Un pilote ODBC approprié est disponible sur le système sur lequel les programmes sont exécutés, afin que les programmes puissent se connecter via ODBC. Chaque programme traitera et convertira le type de données ODBC SQL_C_CHAR en sa représentation textuelle interne de manière appropriée. Je suppose que les programmes ne peuvent faire autrement que d'assumer un codage spécifique pour le texte SQL_C_CHAR. Si ce n'est pas le cas, les programmes doivent être informés du codage en question.

Pour Oracle, je sais que le NLS_LANG peut être utilisée sur le client. Je suppose qu'elle affecte le pilote ODBC (lié à SQL_C_CHAR) pour convertir un encodage spécifique (comme indiqué par NLS_LANG) vers l'encodage 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, de sorte que mes programmes ne peuvent pas soudainement supposer un encodage spécifique pour le texte renvoyé via SQL_C_CHAR.

Est-il possible de configurer la connexion ODBC (de préférence de manière programmatique au moment de l'exécution), de sorte qu'elle prenne en charge les conversions de texte de manière appropriée pour les deux programmes, c'est-à-dire de/à la représentation vers/depuis UTF-8 et de/à la représentation B vers/depuis UTF-8 ?

Voir aussi, /Michael

PS. Comme les programmes se connectent via ODBC, je ne pense pas qu'il soit souhaitable qu'ils sachent quoi que ce soit sur NLS_LANG car il s'agit d'une variable d'environnement spécifique à Orcacle.

Answer 1

Vous devez construire votre application avec la macro UNICODE définie (voir les fichiers d'en-tête sql comme sqltypes.h et sqlucode.h). Cela change les appels à SQLxxx qui correspondent normalement à SQLxxxA (ANSI) en SQLxxxW et qui utilisent donc les API dites à caractères larges. Cela signifie que vous pouvez passer de l'unicode (des données encodées UCS2) aux API SQL et, combiné avec la récupération de colonnes de chaînes en tant que SQL_WCHAR, vous obtiendrez des données larges à partir des récupérations. Je l'ai peut-être manqué, mais je ne vois pas que vous mentionnez une plate-forme (Windows ou UNIX), ce qui peut faire une petite différence si, par exemple, vous êtes sous Unix et que vous n'utilisez pas le gestionnaire de pilote unixODBC. Il y a beaucoup de choses sur le site de MS à propos de l'unicode et de l'ODBC.

Une explication raisonnable d'Oracle/Unicode/ODBC est disponible à l'adresse suivante Utilisation du pilote Easysoft ODBC-Oracle avec des données Unicode . Il explique ODBC et Unicode par rapport à Oracle/NLS_LANG dans un contexte C.