UTF-8 und iSeries?

[RobertMack]

Hallo,

möglicherweise hilft Dir das API iconv (System API Reference, SC41-5801), damit habe ich im RPGLE von 273 nach 1208 konvertiert (für MQ Series).

Gruß,
Robert

[Stoeberl]

Hallo Robert,

weisst du zufällig wie ich die Parameter in RPG kodieren muss bzw. ob ich die API überhaupt von RPG aus aufrufen kann? Hab zwar schon mit API's gearbeitet aber da waren die Typen meist char* oder binary.

Was mir auch gerade erst aufgefallen ist: Ich kann mir mit SQL die Sätze (Feld mit CCSID 1208 *NORMALIZE) in der Datei gar nicht anzeigen lassen. Bringt immer nen SQL system error (SQL0901). Im Log steht:
Function error X'0306' in machine instruction. Internal dump identifier
(ID) 0100265A.
*** DBOP open FAILED. Exception from call to SLICÜ ***.
Internal failure occurred in query processor.
File QAP0ZDMP in library QTEMP already exists.
User Trace data for job 022054/XXX/QPADEV0008 dumped to member
QP0Z022054 in file QAP0ZDMP in library QTEMP.
27 records copied from member QP0Z022054.
1 User Trace buffer(s) deleted.
SQL system error.

Irgendwie scheint das alles noch etwas buggy zu sein ...

cu
Martin

[RobertMack]

Hab's mal rauskopiert, aber der Anhang konnte leider nicht hochgeladen werden.

[Fuerchau]

Definiere das Dateifeld mit CCSID 13488, verwende im RPG das Feld als 15G (Grafik) !
Zwischen DB<->JOB<->DSPF darf bei DBCS keinerlei Umsetzung erfolgen, allerdings kannst du dieses Progrmm nur in einer DBCS-Umgebung verwenden. Bei SBCS geht das nicht, da hier Inkompatibilität herrscht.
Für SBCS benötigst du ein eigenes Programm.

[Stoeberl]

Definiere das Dateifeld mit CCSID 13488, verwende im RPG das Feld als 15G (Grafik) !
Zwischen DB<->JOB<->DSPF darf bei DBCS keinerlei Umsetzung erfolgen, allerdings kannst du dieses Progrmm nur in einer DBCS-Umgebung verwenden. Bei SBCS geht das nicht, da hier Inkompatibilität herrscht.
Für SBCS benötigst du ein eigenes Programm.

Hallo Fuerchau,

wie ich bereits weiter oben geschrieben hab funktioniert es mit UCS2 (13488) oder UTF-16 (1200) ohne Probleme. Mich würd aber gerade UTF-8 interessieren da hier bei den Zeichen des Standard-Ascii Satzes nur 1 Byte beim Speichern verwendet wird. Bei UCS2 und UTF16 sind es mindestens 2 Byte pro Zeichen.
Inwiefern kann es da Inkompatibilitäten geben? Ich kann mit dem Programm (wenn ich UCS2 od. UTF-16 anstatt UTF-8 verwende) sowohl unter ner SBCS- als auch ner DBCS-Anmeldung Daten schreiben und auslesen. Hab's nicht detailiert getestet aber auf anhieb wär mir nichts aufgefallen. Die DBCS Zeichen werden halt unter der SBCS-Anmeldung falsch dargestellt und manche Sonderzeichen wie Ä,Ö,Ü sieht man nicht in der DBCS-Umgebung. Aber ansonsten hat es funktioniert.
Die Probleme hab ich nur bei UTF-8.

cu
Martin

[Fuerchau]

Wie ich schon sagte !
UTF-8 ist eine Speicherung von Unicode als normale ASCII-Zeichen. Dabei kann ein vervierfachung des Codes auftreten.
Wenn du also z.B. 30 Stellen Unicode speicern willst benütigst du 120 Stellen als Zeichenfeld um das Maximum aufzunehemn. Daher erscheint auch die Abbruchmeldung dass das Zielfeld für die Konvertierung zu klein ist !!!!!

Weiteres siehe auch:
http://www.utf-8.com/

[Stoeberl]

Hallo Fuerchau,

das ist mir soweit schon klar. Aber da er erst beim WRITE auf das Satzformat abstürzt denke ich mal es ist ein Problem im System. Das Programm stürzt auch ab wenn ich dem DATEIFELD (mit 30A und CCSID(1208) definiert) ein einzelnes Zeichen wie 'Ä' zuweise da er anscheinend beim Write den 1 Byte Wert von 'Ä' in einen 2 Byte Wert konvertieren will. Die einzige Idee die mir jetzt dazu einfällt wäre es das Zeichen 'Ä' bereits vor der Zuweisung an das Dateifeld nach UTF-8 zu konvertieren, dann bräuchte er beim WRITE nichts mehr umsetzen. Wenn ich UCS-2 in der Datei verwende stürzt er auch nicht ab sondern schneidet die Zeichenfolge einfach ab wenn sie zu lang ist.

Ausserdem finde ich es auch seltsam das die Hex-Zeichen bei UTF-8 in der Datei so gar nicht denen von Unicode.org entsprechen. Wenn ich z.B. das Zeichen 'Ä' per SQL in ein UTF-8 Dateifeld einfüge und mir den Hex-Code danach mit DSPPFM anzeige wird Hex '4A' ('Ä' in Codepage 273) nach Hex 'C384' konvertiert (entspricht laut den Tabellen von Unicode.org einem asiatischem Zeichen). Bei UTF-16 wird es korrekt nach Hex '00C4' konvertiert.

Aber ich hab jetzt soweit mit dem Thema abgeschlossen. Mal abwarten was sich in nächster Zeit in der Richtung noch auf der iSeries tut.


cu
Martin

[Fuerchau]

Nun ja, da UTF-8 eine variable Speicherung ist, muss man beim Lesen andere Felder als beim Schreiben verwenden, was so bei RPGLE nun mal nicht geht.
Erklärung:
Ein Zeichen < x'7f' belegt in beide Richtungen nur 1 Byte, daher kann das Zielfeld genauso lang wie wie das Quellfeld sein. Für alle anderen Zeichen kommt es zur Verkürzung.
Umgedreht muss das Quellfeld aber 4x kürzer sein, da ja im Zweifel eine Vervierfachung auftreten kann.
Ausserdem muss man berücksichtigen, dass das PGM-Feld ggf. immer mit Leerzeichen aufgefüllt ist.
Also kann ein Unicode-Feld nach UTF-8 bis zu 4x größer werden. Ein UTF-8-Feld von gleichgroß bis zu einem viertel.
Die Lösung könnte ggf. ein VARLEN-Feld sein, wenn die aktuelle Länge beim Schreiben eben max. 1/4tel der verfügbaren Länge beträgt.

Die Speicherung im UTF-8 macht also insoweit keinen Sinn, da Unicode hier sowieso die konsistentere Wahl ist.
UTF-8 wird eher im Datenaustausch (Streamfiles) verwendet, die Speicherung immer in UNICODE.

Nun zu deinem Konvertierungsproblem:
Hexcodes im Programm werden in der Codepage des Job's interpretiert, dies gilt auch beim SQL/STRSQL. Wenn du also ein normales Zeichenfeld dem SQL übergibst dann ist das immer der Hexwert der JOB-CCSID (im Zweifel falls 65535 eben Deutsch 273, siehe auch QCCSID).
Die Konvertierung in UTF-8 macht eben eine Konvertierung des aktuellen Hex-Wertes in UTF-8.
UTF-16 oder auch Unicode sind per Definition aber weltweit gleich. Sprich dein 'Ä' ist bereits im korrekten Hexcode verwendet und kann daher auch korrekt in UTF-8 übersetzt werden.

[Sven Schneider]

Was ich nicht verstehe :

Warum definierst du im DSPF ein DBCS-Grafik Feld, willst aber nur UTF-8 Daten speichern.

Ich habe es oben schon beschreiben, definiere im DSPF ein Alpha-Feld mit UTF-8 CCSID, dann solltest du keine Probleme bekommen.

Sven

[Stoeberl]

Was ich nicht verstehe :

Warum definierst du im DSPF ein DBCS-Grafik Feld, willst aber nur UTF-8 Daten speichern.

Ich habe es oben schon beschreiben, definiere im DSPF ein Alpha-Feld mit UTF-8 CCSID, dann solltest du keine Probleme bekommen.

Sven

Hallo Sven,

in der Maske kann ich kein Alpha-Feld mit CCSID(1208) definieren. Nur Grafik-Felder mit CCSID(13488) für UCS2 od. CCSID(1200) für UTF-16 sind möglich.

cu
Martin