Discussion :

[inpra]

Bonjour à tous,

Je souhaite transférer un fichier .TXT( put normal), apparemment en ASCII (a-t-on plusieurs types d'ASCII ?), mais une fois arrivé sur l'as400, je n'arrive pas à le visualiser correctement :

mon fichier TXT
STELLO_COLQUA|21|0|7|C9876|C1185|TITINA VENDOR|GROUPAMA PF1|2011-11-28|2012-01-01|EUR|1052-102|CARDS|6742-102|CREDIT CARDS|3738558.5802|3738558.5802|3738558.5802|3738558.5802|2012-04-06|2012-04-18||Collection|PRIMARY |3743997.0002|374.3997|10000.0000000000|1.0000000000

Le résultat sur AS400 (voir fichier joint capture.png)

Par contre, si je crée un document TXT vide avec notepad, et je copie le contenu de mon fichier TXT initial, puis je transfère vers l'as400, là c'est ok.

Est-ce un pb du format ASCII de mon fichier initial ?

Merci à tous pour votre réponse.

[mlacanada]

Bonjour,

Quel est le cssid de ton fichier sur l'AS/400 (8 devant ton fichier) ?
Sinon lorsque tu te connectes par ftp , est-ce que tu tapes bien la commande ascii avant le put ?

Bonne journée

Marie

[inpra]

Bonjour,

Quel est le cssid de ton fichier sur l'AS/400 (8 devant ton fichier) ?
Sinon lorsque tu te connectes par ftp , est-ce que tu tapes bien la commande ascii avant le put ?

Bonne journée

Marie

Mon cssid = 500, oui ascii avant le put, bizarre non ?

[mlacanada]

Est-ce que tu utilises bien quote site namefmt 1 avant le put pour qu'il utilise la nomenclature de l'ifs et qu'il ne cherche pas à transférer en EBCDIC ?
Peux-tu écrire l'ensemble de tes instructions et aussi si tu transfères depuis Windows ou Unix ?

[inpra]

Est-ce que tu utilises bien quote site namefmt 1 avant le put pour qu'il utilise la nomenclature de l'ifs et qu'il ne cherche pas à transférer en EBCDIC ?
Peux-tu écrire l'ensemble de tes instructions et aussi si tu transfères depuis Windows ou Unix ?

Connecté à SYSTEM.xxxxx.fr.
220-QTCP at SYSTEM.xxxxx.FR.
220 Connection will close if idle more than 5 minutes.
ftp> user services services
331 Enter password.
230 SERVICES logged on.
ftp> put YYYY_2013_03_20.TXT mybib/YYYY130320

Je transfère depuis windows 7.
Merci pour ton aide.

[vazymimil]

Bonjour,

L'application qui produit le fichier semble le faire plutôt en UTF-16 LE qu'en simple ASCII.
Ça correspond au CCSID 1203 qui n'est pas supporté sur la machine sur laquelle je travail et donc peut-être pas la tienne.

[inpra]

Bonjour,

L'application qui produit le fichier semble le faire plutôt en UTF-16 LE qu'en simple ASCII.
Ça correspond au CCSID 1203 qui n'est pas supporté sur la machine sur laquelle je travail et donc peut-être pas la tienne.

et quelle serait la solution d'après toi ? je me vois mal faire la manip de créer un document vide, copier le contenu etc. manuellement, surtout que cela va être des échanges quotidiens.

[vazymimil]

et quelle serait la solution d'après toi ? je me vois mal faire la manip de créer un document vide, copier le contenu etc. manuellement, surtout que cela va être des échanges quotidiens.

Oui pardon je suis parti un peu en urgence

tu peux essayer en faisant "quote type c 1203" avant le put mais ici ça ne marche pas le ccsid 1203 n'est pas supporté

tu peux convertir le fichier sous windows avec powershell par exemple

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

 gc -en Unicode in.txt | Out-File -en Ascii out.txt

[m4k-Hurrican]

Si c'est de l'UTF-16, çà doit pouvoir se traiter.
Déjà il faudrait transférer ce fichier sur l'IFS, en binaire via FTP. A partir de là, on voit dans quel CCSID il est vraiment, et on pourra envisager des solutions.
Le seul hic à ma connaissance concerne les UTF16 codés en Big-Endian ou Little-Endian. Le Little n'étant à priori pas supporté sur notre système. Mais il suffit alors de convertir le fichier (des API ainsi que des exemples existent), puis de le traiter.

[inpra]

Si c'est de l'UTF-16, çà doit pouvoir se traiter.
Déjà il faudrait transférer ce fichier sur l'IFS, en binaire via FTP. A partir de là, on voit dans quel CCSID il est vraiment, et on pourra envisager des solutions.
Le seul hic à ma connaissance concerne les UTF16 codés en Big-Endian ou Little-Endian. Le Little n'étant à priori pas supporté sur notre système. Mais il suffit alors de convertir le fichier (des API ainsi que des exemples existent), puis de le traiter.

J'ai fait un copier/coller du fichier vers l'IFS le CCSID me donne 850. avant le put j'ai fait quote type c 850 et le résultat est le même.

[m4k-Hurrican]

Un copier / coller transforme le fichier puisque tu passes par l'interface du clipboard.
Fais un ftp en mode binaire.

Edit : mieux, si les données contenues ne sont pas sensibles, peux tu me transmettre le fichier txt ?

[Hédhili Jaïdane]

Bonjour.

Amha le plus simple est de faire une conversion en local en batch sous Windows comme le préconise vazymimil,ou de demander à l'application qui génère le fichier de le faire en ASCII. J'ai rencontré ce problème il y a fort longtemps et c'est l'une et l'autre des solutions qui ont été utilisées.

Il y a une API sur l'AS/400, dont je ne rappelle plus le nom, qui fait de la conversion entre CCSID. Scott Klement a fait un écrit là dessus.

[m4k-Hurrican]

C'est QlgTransformUCSData().

Et sinon, ne mettons pas la charrue avant les bœufs, assurons nous du fichier de départ.

[inpra]

C'est QlgTransformUCSData().

Et sinon, ne mettons pas la charrue avant les bœufs, assurons nous du fichier de départ.

Ci-joint un bout de mon .TXT initial. Merci

[FORMULARY]

Ton fichier est en unicode LE (Little Endian).
A ne pas confondre avec UTF-8.
C'est un codage sur 2 octets comme DBCS, mais c'est bien en ASCII.

Depuis le PC, on peut préciser le CCSID du fichier à importer.
QUOTE TYPE C 17856 pour Unicode LE
QUOTE TYPE C 17854 pour Unicode BE
Probleme: Si les tables de translations n'ont pas été installées sur ton AS, le transfert ne s'effectuera pas correctement.

Une solution simple pour convertir le fichier unicode en ANSI (le système utilisé par windows) consiste à utiliser la commande type :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
CD C:\TEMP
TYPE FicUnicode.Txt >FicANSI.txt
FTP xxxxxxx
PUT FICANSI.TXT  biblio/fichier
QUIT

[m4k-Hurrican]

Et toc, pas de bol, c'est bien de l'UTF-16LE.
Pile poil celui qui pose souci.
Bon, ben il va falloir convertir çà avant de l'envoyer sur ton serveur.
Personnellement je le laisserai au minimum en UTF8 plutôt qu'en ANSI ou autre code page standard Windows, histoire de ne pas risquer de perdre des infos.
Maintenant il faut trouver une méthode pour convertir le fichier sans intervention. Notepad++ reconnait l'UTF-16LE et permet de convertir en une option de menu ton fichier en UTF8. Vu qu'il est scriptable, on doit pouvoir jouer avec çà.
Sinon si tu as un Linux sous la main, la commande iconv te fera çà en un tour de main.

[inpra]

Merci à tous.
M4K, non je n'ai pas de Linux sous la main, du coup j'ai testé les solutions de FORMULARY à savoir :
QUOTE TYPE C 17856 pour Unicode LE ou QUOTE TYPE C 17854 pour Unicode BE et il a raison, les tables de translations ne sont pas installées sur ma machine, et le transfert ne se fait pas.

J'ai essayé l'option TYPE comme conseillé, et là comment dire, ça marche impeccable !
Je n'ai qu'un mot à dire : "respect" à tous.

Dernière interrogation, le mode TYPE peut-il me faire perdre des données ?
merci.

[FORMULARY]

La commande TYPE permet simplement d'afficher le fichier.
On redirige la sortie dans un fichier. Or windows est par défaut ANSI.

Sur le principe, on passe d'un codage sur 2 octets à un codage sur 1.
On a donc forcément des caractères qui sont mal ou pas repris.
Maintenant, si ton fichier ne reprend que du texte "standard" issu de France ou d'Angleterre, il n'y a pas de problème.
S'il reprend un texte issu d'Espagne avec des caractères accentués comme ñ il ne devrait pas non plus y avoir de problème, pour peu que les caractères existent sous windows.
S'il reprend des idéogrammes chinois, là, vous aurez forcément des pertes. Mais je ne pense pas que ce soit vote cas !

[inpra]

La commande TYPE permet simplement d'afficher le fichier.
On redirige la sortie dans un fichier. Or windows est par défaut ANSI.

Sur le principe, on passe d'un codage sur 2 octets à un codage sur 1.
On a donc forcément des caractères qui sont mal ou pas repris.
Maintenant, si ton fichier ne reprend que du texte "standard" issu de France ou d'Angleterre, il n'y a pas de problème.
S'il reprend un texte issu d'Espagne avec des caractères accentués comme ñ il ne devrait pas non plus y avoir de problème, pour peu que les caractères existent sous windows.
S'il reprend des idéogrammes chinois, là, vous aurez forcément des pertes. Mais je ne pense pas que ce soit vote cas !

non non ce n'est pas du chinois ni du laotien lol !
je vais donc mettre la commande "type" avant mon FTP et andiamo !!!

Encore merci à tous.

[Hédhili Jaïdane]

...

J'ai essayé l'option TYPE comme conseillé, et là comment dire, ça marche impeccable !
Je n'ai qu'un mot à dire : "respect" à tous.

Dernière interrogation, le mode TYPE peut-il me faire perdre des données ?
merci.

En fait, TYPE utilisé par FORMULARY dans la partie code (batch) n'est pas une option ou un mode, c'est juste la commande DOS-Windows (cmd.exe ou command.com) qui permet d'afficher le contenu d'un fichier, dans l'exemple, la sortie est redirigée vers un fichier. Et comble du bonheur, elle convertit le fichier comme pour l'afficher. FORMULARY d'y avoir pensé. Pour la perte de données, c'est possible. Il faudrait tester à fond.