Fremdsprachen einführen

[dschroeder]

Hallo,
unsere Anwendung hatte bisher nur mit der deutschen Sprache zu tun. Nun soll in zunächst geringem Maße eine Fremdsprachenfähigkeit geschaffen werden. Wir werden im ersten Schritt eine Übersetzungstabelle für einige Sprachen einbauen.

Jetzt die Frage: Alle unsere bisherigen Tabellen haben die CCSID 273 oder 1241 und legen die Daten als Single Byte Character ab. Wenn wir jetzt eine neue Tabelle erstellen wollen, in der sich fremdsprachliche Begriffe befinden, sollten wir diese neue Tabelle dann DBCS-fähig machen?

Hat jemand damit Erfahrungen? (Wir würden neue Tabellen immer mit SQL erzeugen). Muss man da spezielle Feldtypen angeben? Und wenn ja, wie behandelt man die im RPG? Kann man diese Feldtypen mit normalen Strings handeln? Müssen die Strings dann doppelt so lang deklariert werden? Ist Unicode der beste Zeichensatz dafür? (Ich finde Unicode etwas seltsam, weil nicht jedes Zeichen die gleiche Bytelänge hat.)

Es würde mich freuen, wenn jemand ein paar grundlegende Tipps für uns hätte. Die Anwendung wird erstmal nur eine kleine Geschichte werden, die relativ unkritisch ist. Eben ein Projekt zum ausprobieren.

Im Voraus vielen Dank.
Dieter

[andreaspr@aon.at]

Hi Dieter,

Es sollten nur jene Spalten in Unicode definiert werden die auch wirklich entsprechende Zeichen speichern müssen.
Z.B. Spalten die nur einen Status beinhalten würde ich weiterhin als CHAR definieren.

In RPG kannst du die Variablen als UCS2 oder Graphic definieren.
Und du kannst auch mit Char-Zeichen/Variablen in beide Richtungen arbeiten

DCL-S cust_name UCS2(100);
char_var = %Char (cust_name);
if (cust_name <> %UCS2('Maier'));

Es gibt auch UTF-8 (CCSID 1208). Damit werden die ersten 128 Zeichen als Single-Byte-Char gespeichert und nur im Bedarfsfall, wenn du z.B. Umlaute, Chinesisch, Russisch usw. verwendest, als Multi-Byte-Char gespeichert.
Vorteil: Geringer Speicherverbrauch wenn du hauptsächlich nur die ersten 128 Zeichen benutzt.
Nachteil: Höherer Speicherverbrauch wenn du oft mehr als die ersten 128 Zeichen benötigst.

Beispiel mit dem "€" Zeichen:
Unicode: 00100000 10101100
UTF-8: 11100010 10000010 10101100

Ein größeres Thema ist eher die Ausgabe dieser Zeichen.
Wenn du HTML erzeugst, ist es kein Problem ... alles als UTF-8 raus und fertig.
Nur wenn die APIs die du für die HTTP Antwort benutzt UTF-8 unterstützen.
Da gibt es auch unterschiedliche Technologien die nicht alle native UTF-8 unterstützen (PHP, Net.Data, CGI, ...)
PHP z.B. hat keine Probleme damit.

Wenn du aber 5250 Masken hast die nur Bestimmte Zeichensätze unterstützen gehen halt Informationen verloren.

lg Andreas

[Fuerchau]

Zur Ergänzung sei noch gesagt, dass ILERPG native kein UTF-8 unterstützt.
Ich kann hier nur einfache CHAR-Variablen nehmen, eine Definition mit CCSID(1208) scheitert beim Compiler sowohl auf A- als auc C-Variablen.

Seit V7Rx benötigt man i.W. die Funktionen %CHAR() oder %UCS2() für die Codewandlung nicht mehr. Dies erkennt der Compiler nun automatisch.

UTF8 ist ein 1-4-Byte-Code und wird häufig eben zum Datenaustausch verwendet (wie oben gesagt für z.B.HTML).
Da aber alle Anwendungen (auch Windows) z.Zt. mit UCS2-Strings umgehen ist die Speicherung in UTF8 wenig zielführend zumal ein Index über ein solches Feld binär ist und Funktionen wie SUBSTRING erst in UCS2 konvertieren müssen.

In der DSPF wird zwar UCS2 unterstützt, die 5250 kann aber nur in der Hostcodepage (SBCS) arbeiten, es erfolgt also eine Codewandlung von UCS2=>SBCS und zurück.
Die PRTF unterstützt dies auch, allerding nicht der normale Spooler. Bei der Ausgabe in SCS/AFPDS wird in die CHRID des Spools/PRTF umgewandelt.
Ausnahme ist hier die Direkterstellung einer PDF per OVRPRTF unter Umgehung des Spools.

Definierst du die Variablen also ganz normal als NCHAR/NVARCHAR gibt es auch bei ODBC/JDBC kein Problem, da diese Variablen alle in WCHAR (Widechar) übergeben werden und das ist wiederum UCS2.

[dschroeder]

Vielen Dank, Andreas.
Der Speicherplatz ist uns ziemlich egal. Hat Graphics irgendwelche Vorteile gegenüber Unicode? Der Rest der Welt (z.B. Java Webservices) liefern ja oft Unicode.
Welches Speicherformat würdest du denn empfehlen?

[mk]

Hi Dieter,

mal so als Test

Tabelle im SQL anlegen mit
CREATE TABLE LIB/TEST01P (FLD01ASGRAPHIC GRAPHIC ( 50) CCSID 13488 NOT NULL WITH DEFAULT)


(Mit SQL und PHP arbeitet das einwandfrei)

Bei eurer Umgebung ist das auszuprobieren ( Genie Sitzungen , Server DefaultFsCCSID 1141 )
Ich bin aber noch nicht soweit das ich eine 100% Lösung gefunden habe

Gruß
Michael

[dschroeder]

Danke Baldur.
Wir haben eben mal einen Test gemacht und das Feld als NVAR(1000) angelegt. Sah beim ersten Test ganz gut aus. Wenn ich das richtig verstehe, ist NVAR ein Doppelbyte Characterset. Du würdest das gegenüber UTF-8 vorziehen, oder?

[dschroeder]

Danke Michael. Wir haben eben eine Datei mit SQL und NVAR angelegt. Mit SQL-Mitteln konnte man da ganz gut drauf zugreifen und z.B. eine korrekte Längenmessung für japanische Zeichenketten vornehmen.
Was unterscheidet denn den Datentyp Graphic von NVAR?

[andreaspr@aon.at]

Für die Entscheidung welcher Datentyp für euch am geeignetsten ist würde ich die SQL Referenz empfehlen (Character conversion)

The CCSID value for data in UCS-2 format is
13488.
UCS-2 is a subset of UTF-16. UCS-2 is identical to UTF-16 except that
UTF-16 also supports combining characters and surrogates. Since UCS-2
is a simpler form of UTF-16, UCS-2 data will typically perform better
than UTF-16.

[Fuerchau]

Im wesentlichen gar nicht.
GRAPHIC mit entsprechender CCSID ist DBCS, wobei es DBCS gibt, die nicht Unicode sind.
Mit Einführung von Unicode (CCSID 13488) benötigt man die anderen (fast) nicht mehr.
Für Nicht-Unicode-DBCS (z.B. Japanisch) gibt es nämlich spezielle DBCS-5250, die aber leider nicht Unicode unterstützen.

Mit V7 (vielleicht auch schon V6) wurde der SQL-Typ NCHAR/NVARCHAR (N=National) eingeführt, der auch bei vielen anderen Datenbanken schon verwendet wird.
Oracle und SQL-Server speichern die Daten dann allerdings in UTF8, was zur Laufzeit halt ein paar Nanosekunden kostet, dies ständig in WCHAR und zurück zu wandeln.

Zusätzlich wird die CCSID 1200 statt 13488 verwendet.
Die 1200 gilt aber nicht als UCS2 sondern als UTF-16 (also 2/4-Bytes).
D.h., dass NCHAR tatsächlich nur ca. 32K Zeichen als 2-Bytes und alle anderen als 4-Bytes gespeichert werden, während die 13488 eben die 64K Zeichen speichert.
Solange man aber noch nicht mit Codepoints jenseits von 32K zu tun hat, passiert auch nichts, denn die vollständige Unterstützung von UCS4 gibt es auch noch nicht.

Den Unicode-Zeichensatz kann man sich in Windows mal mit der "Zeichentabelle" zu gemüte führen. Da tauchen dann ab Code x'Axxx' dann spezielle Codes auf, die in UTF16 dann 4 Bytes benötigten.

Bei der Umwandlung von UTF-16 in UCS2 gibt es aber bis zu den 64K-Zeichen noch keine Probleme und wann denn vulkanisch oder klingonisch aufgenommen wird steht noch in den Sternen.

Testen kann man das tatsächlich nur mit einer ODBC-Anwendung (Z.B. per Excel, mit MS-Query download, mit meinem Upload/400 upload) oder einer verknüpften Tabelle in Access oder SQL-Server.

Noch ein Tipp zu MS-Query:
MS-Query ist selber keine Unicode-Anwendung (selbst mit Office 2016 noch nicht) und stellt Sonderzeichen eben als Kästchen dar. Trotzdem verarbeitet Excel das dann korrekt.

[dschroeder]

Vielen Dank für die ausführliche Antwort, Baldur.
Wenn ich also folgende Annahmen treffe:
1. Speicherplatz ist uns egal
2. Performancedifferenzen beim Zugriff sind uns auch egal
3. Die meisten (wahrscheinlich alle) Zugriffe werden wir mit SQL machen und die Daten dann im RPG-Programm weiterverarbeiten.

Dann könnte man sagen:
Wenn wir als Datentyp NCHAR einsetzen, machen wir erstmal nichts grundlegend falsch.

Ist das so?
Können wir diese Datentypen im RPG problemlos verarbeiten?

[Fuerchau]

Ja, das ist problemlos, der Feldtyp ist "C".
Aber Vorsicht:
Bei Move/Eval/Prozeduraufrufen erfolgt ggf. eine automatische Konvertierung wenn die Arbeitsvariablen, Parameterschnittstellen nicht auf "C" angepasst sind.
Mit Like-Definition ist die Gefahr gering, Definitionen auf C-Ebene (außen rechts) müssen vermieden werden.

[dschroeder]

Vielen Dank an alle. Ich werde jetzt mal ein paar Tests machen.