Produits Unicode Galvanize

Les éditions Unicode des produits Galvanize vous permettent d'afficher des fichiers contenant des données Unicode et de les utiliser.

Unicode est un standard reconnu de codage des caractères prenant en charge la plupart des langages du monde.

Dois-je installer l'édition non-Unicode ou Unicode d'Analytics ?

Analytics est disponible dans des éditions non Unicode et Unicode. Les deux éditions se trouvent dans le même package d'installation ; c'est pendant l'installation que vous indiquez quelle édition installer.

Vous devez installer l'édition non-Unicode, même si vous devez afficher ou analyser des données Unicode. Les données Unicode peuvent être ouvertes uniquement dans l'édition Unicode d'Analytics.

Vous devriez trouver plus de données Unicode si vous évoluez dans un environnement disposant de systèmes d'information globaux, ou si vous analysez des données contenant plusieurs langages.

Lorsque l'édition Unicode est requise

Vous devez installer l'édition Unicode pour afficher ou analyser des données avec les caractères suivants :

• Caractères asiatiques
• une combinaison de codages de caractères non Unicode ou traditionnels

  Par exemple, certaines combinaisons de langues issues d'au moins deux de ces codages de caractères :

  • Latin 1 (anglais et langues d'Europe de l'Ouest)
  • Latin 2 (langues d'Europe centrale)
  • Cyrillique
  • Grec
  • Arabe

Les données unilingues

Si les données avec lesquelles vous travaillez sont uniquement en Anglais, ou si vous utilisez uniquement des langues de l'Europe de l'Ouest, vous devez plutôt installer l'édition non Unicode. Vous devez être néanmoins conscient(e) qu'un fichier uniquement en Anglais peut être Unicode.

Utiliser Analytics non-Unicode avec des données Unicode

Dans certains cas, il est possible et préférable d'utiliser Analytics non Unicode avec des données Unicode.

Si tous les caractères des données Unicode avec lesquelles vous travaillez sont pris en charge par l'un des codages de caractères traditionnels - par exemple, données uniquement en Anglais - il n'est pas nécessaire d'utiliser Analytics Unicode. Lorsque vous importez ces données dans Analytics non Unicode, les champs de type texte sont automatiquement convertis d'Unicode à ASCII, sans perte ni corruption des données.

Pour connaître les raisons expliquant pourquoi cette approche est préférable, consultez la section Inconvénients de l'édition Unicode.

Le langage des données est ce qui importe

Le ou les langages des données avec lesquelles vous travaillez définissent généralement l'édition d'Analytics à installer, et non le langage de l'interface utilisateur d'Analytics.

Par exemple, votre organisation doit utiliser l'interface espagnole d'Analytics, mais le choix d'installer les éditions non Unicode ou Unicode dépend du ou des langages que vous prévoyez de rencontrer dans les données.

Les interfaces utilisateur d'Analytics en chinois, en japonais et en polonais sont une exception aux instructions générales relativement au choix d'une édition Analytics. Les trois interfaces sont disponibles dans l'édition Unicode uniquement. Pour plus d'informations sur les interfaces localisées d'Analytics et la prise en charge de l'Unicode, consultez la section Prise en charge linguistique.

Quelle édition d'Analytics utilise-je actuellement ?

Pour savoir quelle édition d'Analytics vous utilisez actuellement, sélectionnez Aide > À propos pour ouvrir la boîte de dialogue contenant les informations relatives au produit et à l'inscription. Unicode ou non Unicode apparaît après le numéro de version.

Utilisateurs d'Analytics Exchange ou de Robots

Vous devez installer l'édition d'Analytics qui correspond à l'édition de Robots ou d'Analytics Exchange utilisée par votre organisation. Analytics ne peut pas intéragir avec Robots ou Analytics Exchange si les éditions ne correspondent pas.

Inconvénients de l'édition Unicode

L'édition Unicode d'Analytics a les inconvénients suivants :

• Tailles de fichier de données plus grandes Les données Unicode nécessitent environ deux fois plus d'espaces de stockage que les données non Unicode, chaque caractère étant représenté par deux octets au lieu d'un.
• Performance plus lente possible Avec des fichiers de données plus grands, certaines commandes Analytics peuvent prendre plus de temps d'exécution, deux fois plus de données étant traitées par l'édition Unicode.

En raison de ces inconvénients, vous devez installer l'édition Unicode uniquement dans le cas où vous devez travailler avec des données Unicode.

Données codées sur un octet et données codées sur deux octets dans Analytics

Analytics non Unicode

Pour la lecture et l'écriture de fichiers de données, l'édition non Unicode d'Analytics fonctionne avec des jeux de caractères codés sur un octet (SBCS) uniquement. Dans un jeu de caractères codés sur un octet, un octet de données est utilisé pour représenter chaque caractère ; 256 caractères au maximum sont pris en charge.

Le jeu de caractères codés sur un octet utilisé par Analytics non Unicode dépend de la langue spécifiée par le paramètre Option régionale du système de votre ordinateur. Si l'option régionale du système indique Anglais ou une langue d'Europe de l'Ouest, le jeu de caractères Windows-1252 est utilisé. Windows-1252 est aussi connu sous le nom « Windows Latin 1 ». Vous pouvez définir l'option régionale de votre système dans le Panneau de configuration Windows.

D'autres méthodes courantes permettant de faire référence à des jeux de caractères codés sur un seul octet sont « ANSI », « jeu de caractères ANSI » ou « ASCII étendu ».

Analytics Unicode

Lecture de données

L'édition Unicode d'Analytics peut lire des jeux de caractères codés sur deux octets ou sur un octet. Les caractères Unicode codés sur deux octets utilisent deux octets de données pour représenter chaque caractère. En utilisant au moins deux octets de données pour coder des caractères, Unicode permet de représenter tous les caractères des langues du monde dans un seul jeu de caractères.

Écriture de données

Pour les opérations d'écriture créant des fichiers de sortie, Analytics Unicode utilise en général le codage de caractères UTF-16. Pour certaines opérations, le fichier de sortie conserve le codage de caractère sur un octet présent dans le fichier source.

Nombre d'octets au regard du nombre de caractères

Lorsque vous utilisez des données de type Unicode codées sur deux octets, tenez compte de la différence entre la longueur d'un champ en termes d'octets (indiquée dans la boîte de dialogue Format de table) et la longueur d'un champ en caractères.

Par exemple, si un champ Unicode a une longueur de 44 octets dans la boîte de dialogue Format de table, il contient en fait 22 caractères.

Pourquoi il est important de distinguer les octets des caractères dans ACLScript

Lorsque vous utilisez des fonctions telles que STRING( ) et SUBSTRING( ) contenant un paramètre renvoyant à la longueur d'un champ, indiquez la longueur en caractères et non en octets. Inversement, certaines commandes, telles que DEFINE FIELD, demandent à ce que vous spécifiiez la longueur des champs en octets, et non en caractères.

Dans Analytics non Unicode, un octet est égal à un caractère ; ainsi, la distinction entre les octets et les caractères importe peu. Toutefois, dans Analytics Unicode, lors de l'utilisation de données Unicode codées sur deux octets, deux octets équivalent à un caractère ; ainsi, dans ce cas, il est important de bien faire la distinction.

Pour obtenir des informations détaillées sur le type d'unité à utiliser pour certaines commandes et fonctions, consultez le Guide de création de scripts ACL.

Importation de fichiers texte dans Analytics Unicode

Le codage d'un fichier texte a une influence sur son importation dans Analytics Unicode et sur le type de données utilisé pour les champs de type caractère dans la table Analytics ainsi créée.

Lorsque vous importez des fichiers ASCII et EBCDIC dans Analytics Unicode, deux possibilités s'offrent à vous :

• Convertissez le type de données caractère en UNICODE et créez un fichier de données Analytics

  Si, par la suite, vous remplacez le type de données UNICODE par un type ASCII ou EBCDIC, les caractères ne s'afficheront pas correctement dans les champs.

• Conservez le codage de caractères ASCII ou EBCDIC et créez un format de table Analytics uniquement sans fichier de données Analytics 

  Le format de table Analytics continue à être lié au fichier texte source.

Codage des caractères des fichiers texte	Option Assistant de définition de données	Type de données caractère dans une table Analytics	Longueur de caractères
UTF-16 Little-Endian (Unicode)	Texte Unicode	UNICODE	caractère codé sur deux octets
UTF-8 (Unicode)	Texte codé + jeu de caractères approprié (page de code) pour le fichier de données	UNICODE	caractère codé sur deux octets
ASCII étendu (jeu de caractères ANSI)	ASCII > Fichier texte délimité ASCII > Fichier image d'impression (rapport)	UNICODE	caractère codé sur deux octets
	ASCII > Autre format de fichier	ASCII	caractère codé sur un seul octet
EBCDIC	EBCDIC > Fichier image d'impression (rapport)	UNICODE	caractère codé sur deux octets
	EBCDIC > Autre format de fichier	EBCDIC	caractère codé sur un seul octet

Données petit-boutiste et gros-boutiste

« Petit-boutiste » et « gros-boutiste » sont des termes faisant référence à deux modes de codage de données Unicode différents. Les données Unicode issues d'ordinateurs Microsoft Windows sont généralement codées en petit-boutiste. Si vous utilisez Analytics sur un ordinateur Windows, vous ne pouvez pas analyser des données gros-boutiste.

Conversion de projets non Unicode Analytics en Unicode

Il est possible d'ouvrir un projet Analytics non Unicode dans l'édition Unicode d'Analytics, mais vous ne pouvez pas faire l'inverse : ouvrir un projet Analytics Unicode dans Analytics non Unicode.

	Ouvrir dans Analytics non Unicode	Ouvrir dans Analytics Unicode
projet non Unicode	Oui	Oui
projet Unicode	Non	Oui

Conversion de projet

Lors de l'ouverture d'un projet Analytics non Unicode dans Analytics Unicode, vous êtes invité(e) à convertir automatiquement le projet et son fichier trace associé en Unicode. Si vous choisissez la conversion, des copies du projet non Unicode et du fichier trace d'origine sont enregistrées avec l'extension de fichier .OLD et ne sont pas modifiées.

Fichiers de données Analytics

Lorsque vous convertissez un projet Analytics non Unicode en projet Unicode, les fichiers de données (.fil) Analytics associés ne sont pas convertis au format Unicode. Ils demeurent sous la forme de données ASCII (ANSI) codées sur un octet dans le projet Unicode.

Fonctions spécifiques à Unicode dans Analytics

Analytics dispose de six fonctions spécifiques au format Unicode utiles dans le cadre de la conversion et de l'analyse de données. Ces fonctions sont résumées dans le tableau ci-dessous. Seule l'édition Unicode d'Analytics inclut ces fonctions.

Pour obtenir des informations détaillées sur ces fonctions, consultez le document Guide de création de scripts ACL.

Fonction	Objectif
BINTOSTR( )	Renvoie des données caractère Unicode converties à partir de données caractère ZONED ou EBCDIC. Abréviation de "Binaire à Chaîne". Cette conversion garantit le bon affichage des valeurs codées en ZONED ou EBCDIC.
DBYTE( )	Renvoie le caractère Unicode situé à la position d'octet indiquée dans un enregistrement.
DHEX( )	Convertit une chaîne Unicode en chaîne hexadécimale. L'inverse de la fonction HTOU( ).
HTOU( )	Convertit une chaîne hexadécimale en chaîne de caractères Unicode. Abréviation de "Hexadécimal à Unicode". L'inverse de la fonction DHEX( ).
DTOU( )	Convertit une valeur date Analytics en chaîne de caractères Unicode dans la langue et le format régional spécifiés. Abréviation de "Date en Unicode". L'inverse de la fonction UTOD( ).
UTOD( )	Convertit une chaîne de caractères Unicode contenant une date mise en forme en valeur date Analytics. Abréviation de "Unicode en Date". L'inverse de la fonction DTOU( ).