UTF-8 und iSeries?

[Stoeberl]

Hallo zusammen!

Ich mach mich gerade ein bisschen schlau zu Unicode und iSeries (momentan auf einer Maschine mit V5R3).
Für mich wär UTF-8 interessant da hier weniger Speicherplatz belegt werden würde als mit UTF-16 oder UCS-2.
Eine Datei mit einem Alpha-Feld mit CCSID 1208 konnte ich erstellen aber bei der Maske sagt er das er nur UTF-16 oder UCS-2 in Verbindung mit einem Grafikfeld mag.
Eine indirekte Umwandlung wie EVAL UTF16FELD = UTF8FELD meckert der RPG Compiler ebenfalls an. Muss ich die Werte jetzt jedesmal über API's konvertieren wenn ich UTF-8 in meinen phys. Dateien verwenden will oder gibt es da vom System her noch ne schönere Lösung?
Hat schon jemand seine Datenbank oder Teile davon auf UTF-8 umgestellt?

cu
Martin

[Sven Schneider]

Für die Konvertierung in RPG folgende BIF's :

von xxx nach char --> %CHAR oder Literal '...'
von xxx nach UCS-2 --> %UCS2 oder Literal U'...'
von xxx nach graph --> %GRAPH oder Literal G'...'

http://publib.boulder.ibm.com/infoce...c092508402.htm

Für die Darstellung im DSPF musst du die Felder als A=Alpha definieren.
Ich glaube nicht dass du DBCS oder Grafik-DBCS-Einheiten im Einsatz hast, geschweige denn die kostenpflichtige DBCS-Option von OS/400.
Die benötigst du aber wenn du UCS-2 Felder als DBCS anzeigen willst.
Weil diese werden dann nach DBCS (EBCDIC) konvertiert, da es die direkte Unterstützung für 5250-Enheiten nicht gibt und wahrscheinlich auch nicht geben wird.
Für UTF-8 genügen aber Alpha-Felder in der DDS.

http://publib.boulder.ibm.com/infoce...msttdccsid.htm

[Fuerchau]

UTF-8 wird auf der AS NICHT unterstützt, da das eine HTML-Formatierung ist.
Sonderzeichen wie Ä/Ö/Ü usw. werden in expandierter Form wie z.b. ä="&auml." dargestellt.
UTF-8 ist kein eigentlicher Code sondern eine Darstellung des Codes.
Durch UTF-8 können eben Internetseiten entsprechend aufbereitet werden, die interne Speicherung in einer Datenbank ist dann aber meistens UNICODE.

Man bedenke auch die teilweise drastische Erweiterung der Speicherung, wenn diese im UTF-8 erfolgt. Um z.B. 30 Ü's in einem Namensfeld zu speichern würde ich 30 * "&uuml." also 6*30 = 180 Stellen benötigen, müsste das dann allerdings für die Darstellung in einer DSPF z.B. in CCSID 273 übersetzen.

[Stoeberl]

UTF-8 wird auf der AS NICHT unterstützt, da das eine HTML-Formatierung ist.
Sonderzeichen wie Ä/Ö/Ü usw. werden in expandierter Form wie z.b. ä="&auml." dargestellt.
UTF-8 ist kein eigentlicher Code sondern eine Darstellung des Codes.
Durch UTF-8 können eben Internetseiten entsprechend aufbereitet werden, die interne Speicherung in einer Datenbank ist dann aber meistens UNICODE.

Man bedenke auch die teilweise drastische Erweiterung der Speicherung, wenn diese im UTF-8 erfolgt. Um z.B. 30 Ü's in einem Namensfeld zu speichern würde ich 30 * "&uuml." also 6*30 = 180 Stellen benötigen, müsste das dann allerdings für die Darstellung in einer DSPF z.B. in CCSID 273 übersetzen.

Hmmm, versteh ich jetzt nicht ganz.
Nach der Erklärung auf http://de.wikipedia.org/wiki/UTF-8 wird der komplette Zeichensatz von Unicode unterstützt. Funkioniert auch, wenn ich dem Feld den Wert 'ä' über SQL zuweise hab ich nachher 'C3A4' als Hex-Code in dem Feld stehen.

cu
Martin

[Sven Schneider]

Also, folgende Kombinationen machen nur Sinn :

- wenn DB-Feld ALPHA mit UTF-8 dann solltest du im DSPF auch Alpha verwenden. Im Program ist dann auch keine Konvertierung mit BIF's notwendig, das macht das System selbst. Verwendest du im DSPF ein Grafik mit UTF-16/UCS-2, dann solltst du beim UTF-8 DB-Feld CCSID(1208 *NORMALIZE) verwenden.
- wenn DB-Feld Grafik mit UTF-16/UCS-2 dann kannst du in DSPF die CCSID für UTF-16/UCS-2 bei einem Grafik Feld verwenden.

[Stoeberl]

Soweit gemacht. Hab aber immer noch Probleme beim wegschreiben. Wenn ich z.B. ein 'Ä' über mein Programm in die Datei schreiben will bekomme ich folgenden Fehler:
Data mapping error on member XXX
34 -- The data could not be converted from or to a UTF-8 or UTF-16 CCSID.
The expansion of single-byte data to a double-byte value caused the
converted length to be larger than the maximum length the result could hold

Das Feld in der Datei ist mit 30 Alpha und CCSID(1208) für UTF-8 definiert.

cu
Martin

[Fuerchau]

Bei der Konvertierung von SBCS nach DBCS muss das Zielfeld eben mindestens doppelt so lang sein wie das Quellfeld.

[Stoeberl]

Ich denk mal das ist nicht das Problem da ich
- DBCS-Zeichen ohne Probleme wegschreiben kann
- der Fehler erst beim WRITE auf das Satzformat auftritt. Die Zuweisung des Wertes an das Dateifeld über EVAL DATEIFELD = %CHAR(%TRIM(MASKENFELD)) war schon ein paar Statements vorher und brachte keinen Fehler

cu
Martin

[Fuerchau]

Wie ist das DATEIFELD im RPG denn definiert (Typ) ?
Ich nehme mal an, dass dieses Feld nicht als GRAPHIC definiert ist und somit das System gezwungen ist die Konvertierung SBCS/DBCS durchzuführen und da passt dann irgendwas nicht.
Beim EVAL wird eh abgschnitten bzw. aufgefüllt, was bei Datei-IO's nicht der Fall ist.

Achja:

Wis steht denn die Job-CCSID ?
Bei Datenbankzugriffen in normale CHAR-Felder wird in/von Job-CCSID konvertiert.
Der JOB selber kann aber (glaube ich) keine DBCS-CCSID sein.
Die Programm-Felder müssen also vom Typ Grafik sein, damit eben keine Konvertierung stattfindet.

[Stoeberl]

Das Feld DATEIFELD ist in der Physischen mit 30A CCSID(1208 *NORMALIZE) definiert. Das Feld MASKENFELD ist in der Maske mit 15G CCSID(13488 *LEN 30).
Nachdem ich einen Satz in der Physischen gelesen habe weise ich dem Maksenfeld den Wert mit EVAL MASKENFELD = %UCS2(DATEIFELD) zu. Nachdem der Wert in der Maske geändert wurde wird dem Dateifeld der Wert mit der Anweisung EVAL DATEIFELD = %CHAR(%TRIM(MAKSKENFELD)) zugewiesen.
Rufe ich das Programm in einer DBCS Umgebung auf und schreibe DBCS-Zeichen in das Maskenfeld klappt das wegschreiben. Wenn ich unter einer deutschen Anmeldung ein Ä,Ö,Ü,§,²,³ od. ´wegschreiben will stürzt das Programm mit dem bereits erwähnten Fehler ab (in der DBCS-Umgebung kann ich die Zeichen gar nicht eingeben).

Ich habe auch das Maskenfeld mal auf 30A geändert und die Zuweisungen durch EVAL MASKENFELD = DATEIFELD und EVAL DATEIFELD = MASKENFELD ersetzt. Das Ergebnis war dasselbe. Die anderen Zeichen auf der Tastatur konnte er ohne Probleme wegschreiben, nur bei diesen hat er Probleme.

Hab auch gerade nochmal bei Unicode.org vorbeigeschaut. Die ganzen Zeichen mit denen es nicht funktioniert scheinen nicht im normalen ASCII-Zeichensatz zu sein und werden wohl daher beim wegschreiben umgesetzt auf einen 2-Byte Wert. Wahrscheinlich müsste man die Zeichen schon vorher nach UTF-8 konvertieren aber ausser der API QlgTransformUCSData() hab ich noch nichts dazu gefunden. Kann auch in der RPG-Source kein Feld mit CCSID(1208) definieren.

Ne Idee wie man das noch elegant lösen könnte? Ansonsten muss ich es mal mit der API probieren, auch wenn ich im Moment noch nicht genau weiss wie ich die im RPG verwenden muss.

JobCCSID unter der deutschen Anmeldung ist 273. Das ganze funktioniert auch wenn ich statt UTF-8 UTF-16 od. UCS2 in meiner Physischen verwende, mich hätte aber eben gerade UTF-8 interessiert da hier bei den meisten Zeichen weniger Platz verbraucht wird beim speichern.

cu
Martin

[Stoeberl]

DBCS ist bei uns im Einsatz. Ist auch der Hauptgrund warum mich UTF-8 / Unicode interessiert...

Hab jetzt mal folgendes ausprobiert:
1. Masken- und Datenbankfelder auf UCS-2 geändert -> klappt problemlos, auch mit DBCS-Zeichen

2. Maskenfelder auf UCS-2 und Datenbankfelder auf UTF-8. Die Zuweisung im RPG Programm läuft über EVAL MASKENFELD = %UCS2(DATEIFELD) und EVAL DATEIFELD = %CHAR(MASKENFELD).
Hier habe ich einen re-produzierbaren Fehler:
- Satz im Programm anlegen wo in einem Feld mehrere DBCS Zeichen sind
- Satz wegschreiben und wieder reinlesen (bis hierher klappt es noch)
- Ein DBCS-Zeichen aus dem Satz löschen und wieder wegschreiben
- Wenn ich jetzt den Satz wieder reinlesen will wird er beim Read nicht mehr gefunden (Equal-Schalter auf 1)
- Über SQL kann ich mir den Satz ohne Probleme ansehen
- Lösche ich die DBCS-Zeichen aus dem Satz kann ihn auch das Programm wieder reinlesen

Ne Idee was das sein könnte? Die Hex-Codes hab ich mir angeschaut, ist soweit nicht auffälliges ... ausser vielleicht das ich bei UCS-2 Dateifeldern für meine DBCS-Felder den passenden Hex-Code laut den Tabellen von Unicode.org habe und bei UTF-8 nen Wert der nicht mal im momentan zugelassenen Bereich liegt.

UCS2-HEX......UTF8 -HEX
30B9.............E382B9
30B7.............E382B7

cu
Martin