Leerstelle zwischen den Zeichen, wegen Hexwertfüller 00

[Dancho]

Hallo Zusammen,

sehr oft lese ich eure sehr guten Beiträge und hoffe, dass Ihr mir heute mal helfen könnt. Über die Suchfunktion im Forum kam ich zu keinem passenden Beitrag, auch das Googlen brachte keine Hilfe.

Nun zum Problem:

Wir erhalten eine Datei über die x400. Ein Produkt verarbeitet die Datei und schiebt sie automatisch ins DB2(273) und ins IFS.

Jetzt sieht die Datei nach der Verarbeitung leider wie folgt aus im DB2:

*...+....1....+....2....+....3....+.
ÿÞC r e a t e d , H e a d e r A G ,

E r s t e l l t a m : 3 0 . 0 9

Mit Hexwerten:

* . . . + . . . . 1 . . . . + . . . . 2 . . . . + . . . . 3 . . . . + . *...+....1....+....2....+....3....+.
DF8EC300 99008500 8100A300 85008400 6B00C800 85008100 84008500 9900C100 C7006B00 *ÿÞC r e a t e d , H e a d e r A G , *
00404040 40404040 40404040 40404040 40404040 40404040 40404040 40404040 40404040 * *
00C50099 00A200A3 00850093 009300A3 00400081 0094007A 004000F3 00F0004B 00F000F9 * E r s t e l l t a m : 3 0 . 0 9*

Wie man ganz klar erkennen kann werden hier immer wieder die Hexwerte 00 ausgegeben, welche dann zu der Leerstelle führen.

Die Datei die wir parallel als e-mail bekommen, sieht im notepad ++ ganz normal aus.

Weiß jemand welche Ausgangs-CCSID das sein könnte, oder wie ich sie konvertieren muss, um die fehlerhaften Leerstellen zu entfernen?

Vielen Dank für eure Unterstützung

lg dancho :rolleyes:

[Fuerchau]

Das sieht mir sehr nach UTF-16 aus.
Hier besteht jedes Zeichen eben aus 2 Byte.

[Dancho]

Hallo Fuerchau,

danke für die schnelle Antwort.

UTF-16 wäre ja dann CCSID 1200 - 1205. Wie könnte ich die am besten Konvertieren?

Ich habe im IFS schon versucht die Datei durch hin und her Kopieren zu ändern, aber leider ohne erfolg.

[Fuerchau]

Das Problem ist ggf. die Kennung x'DF8E' die z.B. für Notepad den Hinweis auf UNICODE gibt und Notepad den Text korrekt interpretiert.
Anschließend folgen eben die UNICODE-Zeichen paarweise mit 'C300' ....
Allerdings ist hier der Zeichenwert wohl in EBCDIC und nicht in UTF-16 bzw. UCS2, denn x'C3' ist das EBCDIC 'C'.

Die Frage ist hier, wie sieht denn das Original aus und nicht nach der Verarbeitung.

[andwaw]

Das selbe Problem habe ich auch.
Ich habe alle CCSID's beim CPYFRMSTMF durch probiert allerdings gibt es scheinbar keine die die Leerstellen entfernt.

[Dancho]

also die original Datei hat als Kennung x'FFEF' und enthält danach für 'C' x'43' x'00' demnach ist in der Originaldatei schon das Leerzeichen mit drin.

Ich habe mal ein Bild angehangen, um dies zu verdeutlichen.http://web.logsolution.net/upload/screenshot.PNG

[Fuerchau]

Die Originaldatei hat tatsächlich UTF-16 (CCSID 1200).
Die 2-Byte-Hexkennung am Anfang kennzeichnet dies.
Dein Konverter kann das allerdings nicht erkennen und konvertiert eben direkt 1 zu 1, was bei Sonderzeichen (z.B. deutsche Umlaute) ein Problem ist.

Du musst diese selber konvertieren und erst dann an den Konverter abgeben.
Allerdings musst du die 2 Bytes am Anfang wegbekommen, da sonst der CPYFRMSTMF das nicht konvertieren kann.

Die Alternative ist anschließend einen SQL abzusetzen:

update myfile set field=replace(field, x'00', '')

Zum löschen der 2 Sonderzeichen am Anfang dann:

update myfile set field=replace(field, x'DF8E', '')

[Dancho]

Hallo Fuerchau,

super.

Vielen Dank, als adhoc Lösung bin ich damit erstmal sehr zu frieden, obwohl es das Ursprungproblem nicht löst, es dennoch elegant umgangen wird. :D

Netten Gruß

[ExAzubi]

Hallo,

vielleicht kann dir folgende API helfen


QlgTransformUCSData

http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=/apis/nls2.htm

[Fuerchau]

Dazu musst du nunmal die IFS-Datei mit IFS-API's erst mal selber lesen.
Ausserdem ist das API nur für UCS2<->UTF gedacht.

Einfacher ist da sicherlich obiges Verfahren, insbesonders da die 2 Bytes am Anfang der Datei ja nicht benötigt werden.