Konvertierung nach Graphic --> CCSID Problem

[KM]

Sobald die CCSID 65535 angegeben ist, erfolgt keine Code-Konvertierung. Die Angabe von 273 war schon richtig. Das ist die EBCDIC-Codepage für deutsch (ohne Euro-Symbol). Damit wird korrekt konvertiert.

Gruß,
KM

[Fuerchau]

CCSID 13488 steht für Unicode/UCS2.
CCSID 65535 steht für *HEX.

Um also in UCS2 zu konvertieren, muss ein CCSID ungleich 65535 verwendet werden.

Beim "Insert ... Select" sollte die Job-CCSID eigentlich keine Rolle spielen !

Da ein Job nicht in UCS2 arbeiten kann, liest dein Select die Daten und konvertiert diese in die JOB-CCSID (dein CAST in 13488 wird also wieder rückgängig gemacht) um ihn anschließend in die Zieltabelle wieder umzuwandeln.

Was anderes besagt die CPF-Nachricht nämlich nicht, als das die Codewandlung von/nach 65535 nicht funktioniert.

[codierknecht]

Hallo Fuerchau

Beim "Insert ... Select" sollte die Job-CCSID eigentlich keine Rolle spielen !

das mag durchaus sein. Dennoch gelingt mir der Insert nur, wenn ich die Job CCSID entsprechend ändere. Andernfalls erhalte ich wieder die Fehlermeldung.

Wenn ich die Daten mittels CPYF in die Zieldatei kopiere und die CCSID NICHT umstelle, so ist die Datei in SAP hinterher mit Sonderzeichen und sonstigem Zeug gefüllt. Mit einer anderen CCSID gelingt es jedoch hervorragend.

[sflo]

Hallo Fuerchau,
hallo zusammen,

hierzu habe ich auch eine Frage: ich bin auf der Suche nach einer richtigen Kodierung zu base64 mittels RPGLE. Das Problem ist, dass die vorhandene Funktion SYSTOOLS.BASE64ENCODE eine VARCHAR mit der max. Länge von VARCHAR(2732) annehmen kann. Ich benötige aber die Konvertierung einer größeren Zeichenkette. Hat jemand Tipps dazu?

Vielen Dank und viele Grüße,
Claudia

[Fuerchau]

Da hilft nur, selber machen: https://www.scottklement.com/base64/

[KM]

Hallo Claudia,

wenn Dein String größer als 2732 Zeichen ist, dann versuche ihn doch mal zu splitten. Die ersten Blöcke müssen Vielfache von 3-Bytes Länge sein. Der letzte Block ist dann egal. Die Ergebnisse kannst Du dann wieder zusammenfügen. Dann sollte das richtige Ergebnis dabei rauskommen.

Viele Grüße,
KM

[Fuerchau]

Ja und nein.
Das Problem ist, dass dann jeder Block auch weider einzeln dekodiert werden muss.
Am Ende eines MIME64 wird mit 1 oder 2 "=" aufgefüllt damit die Anzahl Zeichen wieder durch 4 teilbar ist. Ich kann das schon verstehen, wenn die Daten als Block an eine andere Anwendung weiter gereicht werden muss, sollte die Kodierung auch vollständig in einem Block erfolgen.
Also muss man es selber machen und halt Scott's Routinen ggf. auch aufbohren.

Nachtrag:
"Die ersten Blöcke müssen Vielfache von 3-Bytes Länge sein" habe ich übersehen, das passt dann ja.

[KM]

hier ein Beispiel...

Encode:
values(systools.base64encode('DasisteinTes') concat systools.base64encode('tmitBase64Encode'))

Decode:
values((systools.base64decode('xIGiiaKjhYmV44Wi')) concat systools.base64decode('o5SJo8KBooX29MWVg5aEhQ=='))

Beim Decode müssen es natürlich Blöcke mit einer Länge von Vielfachen von 4 Zeichen sein.

Funktioniert also problemlos.

Gruß,
KM

[sflo]

Hallo KM,

vielen Dank für die hilfreiche Antwort. Das lässt sich mit SQLRPGLE en- und decoden. Jedoch wenn ich die Webseite https://www.base64decode.org/ benutze, klappt das nicht. Haben Sie noch einen Hinweis dazu?

Viele Grüße
Claudia

[Fuerchau]

Das ist tatsächlich ein Problem.
Hier spielt die Bitwertigkeit der unterschiedlichen Codepages natürlich eine gewaltige Rolle.
Mime64 macht aus 3x8-Bit 4x6-Bit. Diese 6 Bits werden über eine Tabelle als Index in die 32 möglichen Zeichen übersetzt. Nun ist aber bei der Aufteilung von EBCDIC '000' = x'F0F0F0' ='111100001111000011110000' eine andere Bitfolge entstanden als bei ASCII '000' = x'303030' = '001100000011000000110000'. Dies führt wegen des anderen Index zu einer anderen Kodierung in Mime und kann daher nicht korrekt auf einem anderen System dekodiert werden.
Wenn du also das MIME-Format mit der ASCII-Welt austauschen willst, musst du deine Quelldaten vorher in ASCII übersetzten. Dies kannst du am Besten mit der CCSID 1208 (UTF-8) erreichen. Dann bist du auch sprachneutral. Beim Dekodieren musst du dann halt von 1208 wieder in 273 o.ä. umwandeln.

[Rainer Ross]

Hallo Forum,

für das Encode und Decode von BASE64 gibt es API's auf dem System.
Die sollten bis zu einer Größe von 2GB problemlos funktionieren.
Wenn bei der Konvertierung mit der Seite https://www.base64decode.org/
andere Ergebnisse kommen, dann liegt das daran, dass die Seite UTF8 benutzt.

Damit mit den API's die gleichen Ergebnisse kommen, muss beim Encoding erst
nach UTF8 konvertiert und dann nach BASE64 codiert werden.

//------------------------------------------------------------------//
// BASE64 - Encode String - SRVPGM(QSYSDIR/QAXIS10HT)               //
//------------------------------------------------------------------//
                                                                      
   dcl-pr encbase64bin int(10) extproc('apr_base64_encode_binary');   
           encoded_p   pointer value;                                 
           source_p    pointer value;                                 
           sourcelen   int(10) value;                                 
   end-pr;
                                                            
//------------------------------------------------------------------//
// BASE64 - Decode String - SRVPGM(QSYSDIR/QAXIS10HT)               //
//------------------------------------------------------------------//
                                                                      
   dcl-pr decbase64bin int(10) extproc('apr_base64_decode_binary');   
           decoded_p   pointer value;                                 
           encoded_p   pointer value;                                 
   end-pr; 

Herzliche Grüße

Rainer

[Fuerchau]

UTF8 oder nur ANSI/ASCII ist letztlich egal, halt nur kein EBCDIC.