le forum IBM i

Bonjour,

Dans un rpg ile, le programme génère un code mime en utilisant la library BASE64 et la fonction base64_encode;
Le résultat est ensuite écrit dans un fichier UTF-8 dans l'IFS.

Dans certains cas où la cause est encore indéterminée, il n'est pas possible avec ce code mime de restituer le pdf original,
avec en résultat un pdf vide (mais avec le bon nombre de pages).

Le travail est lancé en ccsid 297.
Dans un même travail certains code mime sont "corrects" (donnent donc le pdf original) alors que d'autres sont "faux".

De plus l'encodage sur notre machine et sur celle d'un tiers sont différents mais reproduisent le même pdf.

Sauriez-vous si la version d'OS, le niveau de PTF sont à vérifier ? S'agirait-il de paramètres systèmes différents ?

Comment s'assurer qu'un code mime est correct ? (coder et décoder ou autre?)

merci d'avance,

Daniel GARCIA.

Bonjour,

Je recommanderai aujourd'hui d'utiliser la fonction SQL d'encodage en base64 : https://www.ibm.com/docs/en/i/7.6.0?top ... e64-encode

La plupart du temps, les problèmes viennent de la gestion des CCSID ;
- à l'entrée dans la fonction : elle attend du binaire (*hex ou 65535). Si les données sont lues et stockées dans des variables CHAR avec un CCSID cela peut modifier la valeur avant encodage
- à la sortie : on récupère une CHAR qui ne contient que des caractères ASCII de base, vous pouvez normalement l'utiliser dans n'importe quel CCSID
- si vous écrivez sur l'IFS le résultat, voir le CCSID du fichier généré
- qui peut aussi être altéré lors du transport

Pour moi le CCSID du job a peu d'importance du moment que vous pouvez utiliser CAST en SQL ou indiquer un CCSID sur vos variables RPG si besoin

Bonjour M BONNET,

Merci pour votre réponse.
Je vais essayer d'encoder via les fonctions SQL,
Je mettrai le résultat sur le fil

Bonjour,

Pour que l'encodage fonctionne il faut que le code de base et le code d'arrivée soient tout le temps les mêmes.
Vous parlez du CCSID du job. Mais ce qui importe c'est le CCSID des champs en entrée et en sortie.
Nous avons personnellement des champs en CCSID 1147 (le même que 297 mais avec le symbole €) car notre système de base est en CCSID 1147, mais aussi des champs en CCSID 1208 (UTF-8) sur nos fichiers récents, car nos interfaces basculent en Web.
Autre chose à prendre en compte, le fichier en sortie.
Il existe, et il est bien défini en UTF-8 ? Là aussi, ce n'est pas toujours évident, plusieurs outils n'affichant pas le même résultat...
Si j'utilise la commande WRKLNK par exemple, le fichier apparait en code 1252 (Windows), alors que si je l'ouvre avec un éditeur dédié, il est bien défini avec un entête et des attributs UTF-8.

Pour ce qui est de générer des PDF, nous utilisons pour notre part l'outil dédié PDFLib.
C'est un peu lourd car il faut tout traiter en code, mais le résultat est toujours celui qu'on attend, avec une vitesse d'exécution fort appréciable, et pour un coût de licence raisonnable, quand on voit celui d'autres outils.