Fremdsprachen einführen

[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.

[dschroeder]

Ich muss doch noch etwas fragen: Ein Kollege vertrat die Meinung, dass eine Umstellung auf DBCS wegen Fremdsprachen nicht immer notwendig ist. Die gängigen Sprachen (alle mit lateinischen Buchstaben, sowie die mit griechischen und kyrillischen Zeichen) müsste man mit den Single Byte Character Set abbilden können. (Klar: Japanisch geht dann nicht).

Wenn das so ist und ein spanischer Anwender gibt ein Zeichen ein, das unser deutscher Zeichensatz nicht kennt: Dann müsste ein deutscher Anwender ja ein Ersatzzeichen sehen. Wenn der deutsche Anwender das dann wieder speichert, macht er dem spanischen Anwender dann seine Daten kaputt?

[BenderD]

... wenn man denn bei den Daten weiß, wo sie herkommen und wie sie codiert sind, kann man auch eine Unicode View über die Daten stellen; bzw. das Unicode Feld zusätzlich führen und per Trigger erzeugen und konsistent halten. Die Anwendung selber bleibt dabei unberührt. Zu Deiner Ausgangsfrage: selbst bei zurückschreiben der gelesenen Daten bleibt der Inhalt in Hex erhalten solange man keine Eingaben in diesen Feldern macht.

D*B

[dschroeder]

Vielen Dank! Die Idee mit der View werde ich hier mal ansprechen.

[Fuerchau]

Nun ja, das mit den Sprachen verhält sich da etwas anders.
Die CCSID's werden zusätzlich in Sprachgruppen geführt. Diese sind dann mit Latin-1 bis inzwischen latin-15 aufgeteilt.
Alle CCSID's einer Latin-Gruppe lassen sich ohne Verlust hin und her konvertieren.
CCSID's unterschiedliche Latin-Gruppen führen bei der Konvertierung zu Verlusten.
Vor Einführung von Unicode konnte man z.B. zwischen 273 und 870 nicht konvertieren, der Open einer Tabelle schlug fehl.
Ab einem bestimmten Zeitpunkt wurde die Konvertierung wohl auf 2-stufig umgestellt, d.h., 1. Stufe in UCS2, 2. Stufe in Ziel-CCSID.
Solange man dann die Daten nur liest, ist es unkritisch.
Schreibt man die Daten zurück, werden sie nicht mehr korrekt zurückkonvertiert, da bei der Hin-Konvertierung Ersatzzeichen oder "?" verwendet wird. Sporadisch gibt es aber bei einigen CCSID-Kombinationen trotzdem was auf die Finger.
In ILERPG hat man halt das Problem, dass beim Lesen alle Felder die definiert sind (z.B. als DS), gefüllt und beim Update zurückgeschrieben werden.
In SQL kann man gezielt sich auf die Felder beschränken.
Übrigens ab irgendwann kann man beim Update in Free in Klammern die Feldliste angeben.

[Fuerchau]

Die Idee ohne Unicode auszukommen geht eingeschränkt natürlich auch, in dem man für jeden Sprachraum eine eigene Tabelle mit der gewünschten CCSID anlegt und die Daten dort pflegt.
Allerdings ist dann erforderlich, dass Tabelle, Job und Terminal alle mit derselben CCSID fahren, damit es nicht zu Darstellungsverlusten kommt.

[dschroeder]

Nochmals danke. Ist ein sehr komplexes Thema. Mich würde interessieren, was andere IBM i Anwender machen. Es ist ja oft so, dass man weiß, was theoretisch die beste Lösung ist, dass man aber in der Praxis doch eine einfachere (bzw. bekannte) Lösung wählt. Habt ihr zum großen Teil wirklich eure Tabellen auf DBCS umgestellt?