UTF-8 Datei per FTP richtig verarbeiten

[evoka]

probier ich doch mal aus :-)

und... funktioniert!

Wenn du dir die Daten auf einer 5250 Session anzeigen lassen magst:

- Datei per ftp auf die i5 übertragen
- die CCSID auf 1208 gesetzt
- ne 5250 Sitzung unter 870 in nem SBS (also Job) 870 gestartet
- die Datei anzeigen lassen

[SourceCoder]

Guten Morgen und danke für die tollen Antworten.

Also mein Ziel ist es: Die Informationen mit den richtigen Zeichen in die Datenbank zu speichern und dann sollen diese Informationen später auf ein Label gedruckt werden.

Also ich habe es nun hinbekommen das die Zeichen auch richtig dargestellt werden, folgende Schritte habe ich getan.

1. CHGATR OBJ('/MyFile') ATR(*CCSID) VALUE(1208)
2. CHGJOB JOB() LANGID(PLK) CCSID(870)
3. Session Einstellung: AS/400 code page von 273 auf 870 geändert und Encoding von Windows OS default auf Windows-1250 (Mitteleuropäisch)

Wenn ich das richtig verstanden habe werden die Werte richtig in die DB übernommen wenn ich vorher über den Befehl "CHGATR" die CCSID auf "1208" geändert habe. Und die Schritte 2 und 3 sind nur für die reine Anzeige relevant richtig?

Das mit Schritt 1 sollte ja auch keine Probleme bereiten wenn auf einmal z.B tschechische Zeichen in dieser Datei vorhanden sein sollten oder?

[Fuerchau]

In die Datenbank bekommst du die Daten nur dann vernünftig, wenn die Felder ebenso UCS2 sind:
DDS Typ G, CCSID 13488
SQL N[VAR]CHAR(xx)

Im Programm sind die Variablen dann vom Typ "C".
Beim Drucken allerdings hört der Spaß fast wieder auf:
AFPDS = Dies geht, wenn du z.B. PDF-Ausgabe wählst, kann in der PRTF ein Typ-G-Feld mit einem TrueTypeFont verwendet werden.
Bei anderen Ausdrucken (SCS, lokalen Druckern) müssen die Daten in die korrekte CHRID für die PRTF ausgegeben werden. Die CHRID wird beim CRTPRTF/OVRPRTF angegeben.
Die Daten zum Drucker unterliegen, ebenso wie beim Display, keiner Codewandlung.
D.h., auf Grund der CHRID wird im Drucker die Codepage (850=Deutsch, 852=Osteuropa, ...) ausgewählt. Ist diese nicht vorhanden, wird Schrott gedruckt.

Wenn du z.B. einen Zebra-Drucker einsetzt, musst du die ZPL-Codes der Codepage kennen und die Daten passend in der EBCDIC-CCSID an den Drucker geben.

Im Programm kann man per API (dynmischer) oder auch per SQL (leider nur statisch) Codewandlungen durchführen, dazu sollte die Daten in einer "C"-Variablen vorliegen:
SQL: exec sql set : MyChar870 = cast(: MyCVar as char(nn) ccsid 870);
Leider lässt sich das so nicht per dynamischem SQL ausführen.

Oder du liest die Daten mittels dynamischem Cursor direkt in der passenden CCSID ein.

Wie du siehst, leider nicht ganz so einfach, da du im Vorhinein wissen musst, welche CCSID deine Daten haben um dann entsprechend für die Ausgabe reagieren zu können.
D.h., dass du am besten deine Daten mit einem eigenen Zusatzfeld und der Quell-CCSID speicherst.