Utiliser des CCSID avec des fichiers texte

à  merveille les différents
jeux de caractères, pages de code et formats de codage possibles.
Chaque fichier reçoit un numéro
appelé CCSID (Coded Character
Set Identifier). La figure 3
montre une liste des CCSID que
j’utilise. Vous en trouverez d’autres
dans l’IBM Information Center
(pour cela, sélectionner Programming,
Programming Support, Globalization,
Reference puis CCS
IDs).

Quand on crée un nouveau fichier
stream, on peut préciser le
CCSID avec lequel le fichier sera validé.
On peut faire cela en utilisant
le flag O_CCSID quand on appelle
l’API open(), comme dans la figure
4.

Le flag O_TEXTDATA indique à 
l’API open() que le fichier contient
des données textuelles. Quand on
lit des données à  partir d’un fichier
stream qui a été ouvert avec ce flag
activé, les données seront automatiquement
traduites du CCSID du
fichier en CCSID de votre job. Si
vous écrivez dans un fichier existant
où ce flag est spécifié, les données
seront traduites du CCSSID
de votre job en CCSID du fichier.
Cela permet de traduire automatiquement
des données vers et à  partir
d’ASCII, si l’on veut écrire des fichiers
lisibles par des ordinateurs
orientés ASCII, comme votre PC.

Important : O_TEXTDATA ne
traduit des données en CCSID du
fichier que si le fichier existe déjà . Si
l’on crée un nouveau fichier, on
part du principe que les données
que l’on écrit seront déjà  dans le
même CCSID que le fichier. C’est
pour cette raison que beaucoup
des exemples présentés montreront
deux appels à  l’API open(),
une fois pour créer le fichier avec le
bon CCSID et à  nouveau pour permettre
la traduction en utilisant le
flag O_TEXTDATA. La figure 4 démontre
cela.

Il est un détail de la figure 4 qui mérite une explication : c’est son utilisation du champ VARYING
pour la variable « texte ». De tels champs stockent la
longueur des données dans les deux premiers octets du
champ, afin de déterminer plus facilement la longueur des
données que le programme doit écrire. Ce procédé est aussi
plus performant parce qu’il dispense de la fonction intégrée
(BIF, built-in function) %trim() coûteuse.
Comme les deux premiers octets
du champ contiennent la longueur
et que l’on ne veut pas que cela
fasse partie des données qui seront
écrites sur disque, il faut ajouter 2 à 
l’adresse du champ pour obtenir le
départ des données caractère réelles.
Par conséquent, en appelant l’API
open(), je passe %addr(text)+2 au
lieu de simplement %addr(text).

A partir de la V5R2, IBM a ajouté
un nouveau flag à  l’API open appelée
O_TEXT_CREAT. Quand on spécifie
ce flag conjointement à  O_CREAT,
O_TEXTDATA et O_CCSID, on a la
possibilité de créer un nouveau fichier
stream et de commencer à  traduire les
données à  écrire dans ce fichier
stream, le tout d’un seul appel à  l’API
open(), comme on le voit figure 5.

La figure 5 montre l’écriture d’un
fichier texte compatible avec Microsoft
Windows. Comme un CCSID n’est
attribué à  un fichier que lors de sa
création originale, l’API unlink() est
utilisée pour supprimer toute éventuelle
copie précédente du fichier. Le
nouveau fichier est créé avec l’API
open(), reçoit le CCSID 1252, et il
est ouvert en mode texte afin que les
données écrites soient traduites en
ASCII.

Une fois le fichier texte créé, on
peut l’ouvrir, le modifier, et plus, avec
la commande OS/400 EDTF ou à 
partir de Windows avec Notepad ou
Word, et il fonctionnera correctement
sur l’un ou l’autre de ces systèmes.
Peu importe que l’iSeries soit une
machine EBCDIC et le PC une machine
ASCII. Comme le CCSID approprié
a été indiqué, l’iSeries effectuera
automatiquement la traduction
voulue !

La fonction O_CCSID existe depuis
la V5R1. Auparavant, l’OS/400 n’utilisait pas des CCSID
pour les fichiers stream ; il utilisait à  la place des pages de
code. S’il est nécessaire d’écrire une application qui fonctionne
en V5R1 ou antérieures, on peut faire à  peu près la
même chose que les CCSID, en remplaçant le flag O_CCSID
par le flag O_CODEPAGE.