-
Wer es nicht so mit C-API's hat, hier gibts noch eine OPM-Version:
Convert a Graphic Character String (CDRCVRT, QTQCVRT) API
-
Also das mit der PRTF habe ich getestet.
Allerdings stehe ich da vor dem Problem, das in der PRTF jede Zeile deklariert sein muss die ich ausgeben will.
Da der Inhalt dynamisch ist und ich den vorher nicht kennen, bringt mir das glaube ich nichts.
Oder kann ich dabei irgendwie für einen Zeilenumbruch sorgen?
Dann würde ich zwei Zeilen deklarieren.
1. Zeile das Feld mit dem TRNSPY-Feld
2. Zeile mit meine XML-Strream den i immer wieder ausgebe (mit verschiedenen Inhalten).
Geht sowas?
-
Natürlich, nur ohne SPACEA/B.
In der XML dürfen ruhig außerhalb der Tags CRLF (SPACEA) vorkommen und dienen der Leserlichkeit.
Leerzeichen zwischen den Tags sind manchmal erlaubt, manchmal leider nicht.
Wenn du also ein Format ausgibst, sind am Ende eben noch Leerzeichen vorhanden.
Allerdings sind zwischen den Attributen, also Werte in Anführungszeichen, beliebig viele Leerzeichen erlaubt.
Ich weiß ja nicht, wie das Format deiner XML im Endeffekt aussieht und was dein Gegenüber erlaubt.
-
Natürlich, nur ohne SPACEA/B.
Ist das der Befehl mit dem ich den Umbruch einfüge?
-
Stimmt exakt.
Man kann den Leadin (den Hexwert) z.B. zusammen mit dem Startnode in eine Zeile ausgeben mit SPACEA(1):
also x'xxyy' + "< Start >"
Je Knoten und oder Attribut eine lange Zeile mit SPACEA(1), Leerzeichen am Ende sind egal.
Abschlussknoten in einer kurzen, abgezählten Zeile ohne SPACEA(1)
"< /Start >"
Ich habe auch manchmal das Problem, dass XML's am Ende noch jede Menge Leerzeichen enthalten.
Ich muss dann die Datei komplett selber lesen, Leerzeichen am Anfang/Ende entfernen und dann an den XML-Loader übergeben (.NET-Programmierung).
-
Und da bin ich auch schon wieder.
Also das mit dem BOM klappt soweit(letzten Tests stehen noch aus).
Aber wie bereits von Teilnehmern aus dem Forum angemerkt, funktionieren die Umlaute nicht.
Diese werden im Spool sauber angezeigt.
Im Zielsystem sind diese jedoch kaputt.
Ich habe mir iConv angesehen und auch versucht zu implementieren, aber aus meiner Sicht gibt es keinen Unterschied.
Folgendes habe ich aufgenommen:
PHP-Code:
F*------------------------------------------------------------------ F* Prototype for Code Conversion - Open F*------------------------------------------------------------------ D IConvOpen PR 52A ExtProc('QtqIconvOpen') D fromcode * Value options(*string) D tocode * Value options(*string) *------------------------------------------------------------------ * Prototype for Code Conversion *------------------------------------------------------------------ D IConv PR 10i 0 ExtProc('iconv') D 52a Value D * Value D 10i 0 Value D * Value D 10i 0 Value **************************************************************** * Code Page Conversions (iconv_t) ***************************************************************** D ToAscii DS D ICORV_A 1 4b 0 * return value to indicate if error occurred D ICOC_A 5 52b 0 DIM(00012) * cd * D ToEbcdic DS D ICORV_E 1 4b 0 * return value to indicate if error occurred D ICOC_E 5 52b 0 DIM(00012) * cd * D** D** D p_Qascii S * inz(%addr(Qascii)) D Qascii DS 32 D asciiCP 1 4b 0 inz(00813) D asciiCA 5 8b 0 inz(0) D asciiSA 9 12b 0 inz(0) D asciiSS 13 16b 0 inz(1) D asciiIL 17 20b 0 inz(0) D asciiEO 21 24b 0 inz(1) D asciiR 25 32a inz(*allx'00') D** D p_Qebcdic S * inz(%addr(Qebcdic)) D Qebcdic DS 32 D ebcdicCP 1 4b 0 inz(00037) D ebcdicCA 5 8b 0 inz(0) D ebcdicSA 9 12b 0 inz(0) D ebcdicSS 13 16b 0 inz(1) D ebcdicIL 17 20b 0 inz(0) D ebcdicEO 21 24b 0 inz(1) D ebcdicR 25 32a inz(*allx'00') D** D CHAR10 S 10A BASED (P)
In den C-Bestimmungen dann:
PHP-Code:
C MOVE *BLANKS MSGTODSPLY 52 C Z-ADD 0 rc 50 0 C MOVE *BLANKS XMLSTR2 * translate response to ASCII C eval rc = IConv( C ToAscii: C %addr(XMLSTR): C %len(%trimr(XMLSTR)): C %addr(XMLSTR): C %len(%trimr(XMLSTR)) C ) C if ICORV_A > 0 C eval MsgToDsply = 'Error in Translate' C MsgToDsply dsply C endif C**
Zusätzlich habe ich die *INZSR noch aufgenommen wo folgendes drin steht:
PHP-Code:
Csr *INZSR begsr * setup code page conversion ebcdic - ascii C eval ToAscii = IConvOpen(p_Qascii: C p_Qebcdic) C if ICORV_A = -1 * error processing here C endif * setup code page conversion ascii - ebcdic C eval ToEbcdic = IConvOpen(p_Qebcdic: C p_Qascii) C if ICORV_E = -1 * error processing here C endif * Csr #INZSR endsr
Also die Ansicht im Spool und das Ergebnis im Zielsystem ist mit meinem iConv-Versuch das gleiche.
Die Umlaute passen leider nicht.
Nach dem Aufruf von iConv wird XMLSTR mittels EXCPT ausgegeben.
PHP-Code:
O E EXCXML 1 O XMLSTR 198
-
also...
1) wenn Du nach dem Konvertieren die Umlaute bzw. überhaupt irgendwas im Spool noch lesen kannst, dann hat's was.
2) Der Aufruf von iconv sieht falsch aus; iconv gibt die Anzahl der (noch) nicht übersetzten Bytes zurück, das wird bei dem Prototyping nicht klappen. siehe z.B. hier:
http://www.scottklement.com/qrpglesrc.redemo2
Google findet etliche korrekte Beispiele.
3) wieso 813? Ich denke, es soll UTF-8 sein? Das wäre 1208.
Abschließend nochmal der beste Tip von allen: mach' es ordentlich und nicht über den Spool. Das ist böseste Zweckentfremdung und Vergewaltigung, die sich sicher nochmal rächen wird.
-
Hallo Anton,
vielen Dank auch dir für den Hinweis der Zweckentfremdung.
Ich versuche den Kunden auf eine Dateiausgabe zu bringen(damit funktioniert bereits alles).
Allerdings beharrt er auf die Ausgabe über diesen Weg.
Daher versuche ich hier zweigleisig zu fahren.
Ich habe mir das Beispiel von Scott angesehen und erhalten beim Wandeln die Fehler, das u.a. scPattern nicht deklariert ist.
Wenn i mir das Sample aus
http://www.cottklement.com/qrpglesrc.redemo2
ansehe, sehe ich hier auch keine Deklaration.
Übersehe ich was?
Schon jetzt allen vielen Dank für die Bemühungen.
-
Wichtig zu wissen ist, dass die Art des XML-Encoding in einem Header festgelegt wird. Alle Reader halten sich normalerweise dann daran, z.B.:
< ?xml version="1.0" encoding="UTF-8"? >
Gibst du also ASCII aus, musst du auch ASCII als Encoding angeben.
Besser ist, hier ANSI (Codepage 1252) zu wählen, das Encoding ist dann "ISO-8859-1", wähle also beim iConv die Codepage 1252 aus.
-
Stimmt; das ist entweder in dem Copy drin oder Scott hat ausnahmsweise mal einen kleinen Fehler gemacht.
Es kann aber nur ein Character-Feld sein.
Aber davon mal abgesehen ist das Prototyping für iconv in dem Beispiel ganz offensichtlich anders als Deins und einzig und allein darum ging es mir.
Viel Erfolg und viel Glück beim Kunden-Erziehen!
-
Nachtrag:
Beide CCSID's sind natürlich falsch!
Statt 813 nimm 1252, statt 037 nimm (wahrscheinlich) 273, das kommt darauf an, welche Quell-CCSID deine Daten haben!
Wenn das Encoding tatsächlich UTF-8 sein soll, muss die pASCII-CCSID natürlich 1208 lauten.
Eine XML-Ausgabe hat eigentlich kein BOM, da das Encoding über den Header festgelegt werden muss.
-
Habe jetzt folgendes Testprogramm mal aufgebaut:
Code:
H DEBUG DECEDIT('0,') DATEDIT(*DMY.) DFTACTGRP(*NO)
D QtqCode_T DS Qualified
D CCSID 10I 0 Inz(0)
D CvtAlt 10I 0 Inz(0)
D SubAlt 10I 0 Inz(0)
D ShiftState 10I 0 Inz(1)
D InLenOpt 10I 0 Inz(0)
D MixDataErrorOpt...
D 10I 0 Inz(0)
D Reserved 8A Inz(*ALLX'00')
D fromCCSID DS LikeDS(QtqCode_T)
D toCCSID DS LikeDS(QtqCode_T)
D iconv_t DS Qualified INZ
D rtn_value 10I 0
D cd 10I 0 Dim(12)
D
D QtqIConvOpen PR ExtProc('QtqIconvOpen')
D LikeDS(iconv_T)
D toCCSID LikeDS(QtqCode_T)
D fromCCSID LikeDS(QtqCode_T)
D hConv DS LikeDS(iconv_T)
D Inz(*LIKEDS)
D**
D iconv PR 10U 0 ExtProc('iconv')
D hConv LikeDS(iconv_t) VALUE
D pInBuff * VALUE
D nInLen * VALUE
D pOutBuff * VALUE
D nOutLen * VALUE
D MyData S 10A Inz('ABCDEFG')
D pData S * Inz
D ppData S * Inz(%addr(pData))
D nInLen S 10I 0
D nOutLen S 10I 0
D iconv_close PR 10I 0 ExtProc('iconv_close')
D hConv LikeDS(iconv_t) VALUE
/free
fromCCSID.CCSID = 273;
toCCSID.CCSID = 1208;
hConv = *ALLX'00';
hConv = QtqIconvOpen(toCCSID:fromCCSID);
/end-free
C eval nInLen = %len(%TrimR(mydata))
C eval nOutLen = %size(mydata)
C eval pData = %addr(myData)
C callp iconv(hConv : ppData : %addr(nInLen):
C ppData:%addr(nOutLen))
C callp iconv_close(hConv)
C MOVE '1' *INLR
Als Ergebnis steht in der hconv ein Return-Wert von -1.
Ich denke mal dass das ein Fehler ist?
Aber was für einer?
Folgendes erhalte ich in der DS-Anzeige von hConv:
Code:
> EVAL hConv
HCONV.RTN_VALUE = -1
HCONV.CD(1) = 1077952576
HCONV.CD(2) = 1077952576
HCONV.CD(3) = 1077952576
HCONV.CD(4) = 0
HCONV.CD(5) = 208
HCONV.CD(6) = 8
HCONV.CD(7) = -2
HCONV.CD(8) = -2147483648
HCONV.CD(9) = 0
HCONV.CD(10) = -978493160
HCONV.CD(11) = 671093600
HCONV.CD(12) = 0
Wenn ich das richtig verstanden habe und iconv sauber gelaufen ist, dann müsste der nInLen anschließend auf 0 stehen richtig?
Habe ich noch etwas übersehen/falsch implementiert?
Similar Threads
-
By VolkerGrebner in forum NEWSboard Programmierung
Antworten: 2
Letzter Beitrag: 16-02-07, 14:38
-
By vige1000 in forum NEWSboard Linux
Antworten: 4
Letzter Beitrag: 21-12-06, 11:56
-
By Robi in forum IBM i Hauptforum
Antworten: 2
Letzter Beitrag: 14-12-06, 11:12
-
By Weki in forum IBM i Hauptforum
Antworten: 4
Letzter Beitrag: 11-09-06, 13:31
-
By cseitz in forum IBM i Hauptforum
Antworten: 0
Letzter Beitrag: 20-06-06, 14:40
Berechtigungen
- Neue Themen erstellen: Nein
- Themen beantworten: Nein
- You may not post attachments
- You may not edit your posts
-
Foren-Regeln
|
Erweiterte Foren Suche
Google Foren Suche
Forum & Artikel Update eMail
AS/400 / IBM i
Server Expert Gruppen
Unternehmens IT
|
Kategorien online Artikel
- Big Data, Analytics, BI, MIS
- Cloud, Social Media, Devices
- DMS, Archivierung, Druck
- ERP + Add-ons, Business Software
- Hochverfügbarkeit
- Human Resources, Personal
- IBM Announcements
- IT-Karikaturen
- Leitartikel
- Load`n`go
- Messen, Veranstaltungen
- NEWSolutions Dossiers
- Programmierung
- Security
- Software Development + Change Mgmt.
- Solutions & Provider
- Speicher – Storage
- Strategische Berichte
- Systemmanagement
- Tools, Hot-Tips
Auf dem Laufenden bleiben
|
Bookmarks