View Full Version : Allgemeine Verwendung von Unicode
Die Performance ist da auch eher zu vernachlässigen. Und sich mit dem warten aif V6R1 herauszureden ...
Das casten per SQL mit verschiedenen CCSID's wird schon so lange unterstützt, wie es CCSID auf Feldebene gibt (ich arbeite seit V2R1 damit).
Wenn die Ausgabe auf STDOUT direkt per Web-API gesendet wird, muss ja auf jeden Fall eine CCSID-Umsetzung erfolgen. Ich denke nicht, dass du in deinem RPG bereits ASCII-Daten ausgibst sondern ganz normal deine Variablen, also in EBCDIC.
Wenn du nun UTF-8 ausgeben willst, so musst du dich hier schlau machen, wie du dem API dieses mitgeben kannst oder dir eben was anderes überlegen.
https://www-03.ibm.com/systems/i/software/http/examples/sample_utf8/utf8_demo.html
könnte da noch von Interesse sein.
D*B
PS: warum macht man sowas nicht mit Java?
andreaspr@aon.at
20-01-11, 07:38
@Baldur: Danke für die Denkanstöße. Jetzt weiß ich schon mal was ungefähr alles zu beachten ist. In der Praxis wird sicher noch das Eine oder Andere dazu kommen, aber nun kenn ich mich schon besser aus.
@Bender: Danke für den Link. Werde ich mir in den nächsten Tagen noch genauer anschauen.
Bzgl. Java: Wir arbeiten fast ausschließlich mit RPG. Java Wissen ist zwar in der Firma vorhanden, aber sicher nicht ausreichend um einen Performanten weg zu finden der mit der RPG-Ausgabe mithalten kann.
Danke, ihr beide habt mir sehr geholfen!
andreaspr@aon.at
01-02-11, 13:14
Der Unterschied zwischen CCSID 1200 und 13488 ist folgender:
13488 ist UCS2, d.h., jedes Zeichen ist fix in 2 Byte gespeichert und deckt i.W. 64000 verschiedene Zeichen ab.
1200 ist UTF-16, was eine variable Darstellung von 2 oder 4 Bytes ist und somit alles an verfügbaren Zeichen abdeckt.
1208 ist UTF-8, was eine variable Darstellung von 1 bis 4 Bytes ist!
Hallo Baldur,
kann es sein, dass UCS2 auf der DB2 doch variable 2 oder 4 Byte enthalten kann? Habe gerade den Violinschlüssel eingefügt. In Hex gibt er mir D834DD1E aus. Das gleiche Ergebnis wenn ich mit UTF-16 (1200) arbeite.
Bei allen Spielerein die ich bis jetzt gemacht habe, konnte ich noch immer keinen unterschied zwischen UTF-16 und UCS2 entdecken. Zumindest nicht Binär.
UCS2 als CCSID 13488 ist als 2-Byte-Code definiert.
Dass UTF-16 fast identisch ist liegt daran, dass erst bei den asiatischen Schriften 4-Bytes benötigt werden, für alle anderen Zeichen reichen 15 Bit ja aus.
Andreas,
vielleicht hilft Dir der folgenden Auszug aus der SQL Reference weiter.
Unicode data
Data that contains characters represented by two or more bytes. Each Unicode graphic string is encoded using either UCS-2 or UTF-16.
UCS-2 is a subset of UTF-16. The CCSID for UCS-2 is 13488. The CCSID for UTF–16is 1200.
NCHAR, NVARCHAR, and NCLOB are synonyms for Unicode graphic
data with a CCSID of 1200.
Schau Dir doch mal die SQL Reference an:
Kapitel 2 --> Data Types --> Character Strings und Character Encoding Schemes
Birgitta
andreaspr@aon.at
02-02-11, 09:17
Danke Baldur und auch danke Birgitta für eure Hinweise.
Die SQL Referenz habe ich schon gelesen. Habe sogar schon das ganze InfoCenter nach diesen Stichwörtern durchsucht.
Den einzigen unterschied, den ich bis jetzt gefunden habe ist eben die unterschiedliche CCSID und die Aussage aus der Referenz, dass UCS-2 eine Teilmenge aus UTF-16 ist.
Ich habe Sprachen vom arabischen und asiatischen Raum gespeichert. Binär war kein unterschied zu erkennen. Vielleicht gibt es Zeichen aus einem Stamm in Indonesien, die UTF-16 unterstützen und UCS-2 nicht, habe diese Zeichen bis jetzt jedoch nicht finden können.
Es ist auch nicht so wichtig. Ich fand es nur interessant, dass ich aus den Unterlagen und auch sonst im Internet keinen Hinweis auf den Praktischen unterschied finden kann.
Danke für eure Unterstützung!
UTF-16/UCS-2 - Wikipedia, the free encyclopedia (http://en.wikipedia.org/wiki/UTF-16/UCS-2)
http://en.wikipedia.org/wiki/Plane_(Unicode)
Danke Baldur und auch danke Birgitta für eure Hinweise.
Die SQL Referenz habe ich schon gelesen. Habe sogar schon das ganze InfoCenter nach diesen Stichwörtern durchsucht.
Den einzigen unterschied, den ich bis jetzt gefunden habe ist eben die unterschiedliche CCSID und die Aussage aus der Referenz, dass UCS-2 eine Teilmenge aus UTF-16 ist.
Ich habe Sprachen vom arabischen und asiatischen Raum gespeichert. Binär war kein unterschied zu erkennen. Vielleicht gibt es Zeichen aus einem Stamm in Indonesien, die UTF-16 unterstützen und UCS-2 nicht, habe diese Zeichen bis jetzt jedoch nicht finden können.
Es ist auch nicht so wichtig. Ich fand es nur interessant, dass ich aus den Unterlagen und auch sonst im Internet keinen Hinweis auf den Praktischen unterschied finden kann.
Danke für eure Unterstützung!
Hallo, ich habe vielleicht ein ähnliches Problem, dass hier reinpassen würde.
In eine Tabelle sollen Texte wie "Sluková, Kateřina" gespeichert werden können. Standardmäßig ist bei uns im System CCSID 273, sodass die Zeichen per SQL zwar mit Warnungen übermittelt werden, aber nicht korrekt dargestellt werden. Mit der CCSID 1208 kann ich die Varchar-Felder erstellen, allerdings sind damit die "Probleme" bei Darstellung in Query oder RPG wie ich gelesen und dann auch getestet habe vorprogrammiert. Eine CCSID 13488 oder 1200 funktioniert nicht auf unserer V7R2.
Fehlermeldung CCSID 13488:
SQL-Status: 22522
Vendorencode: -189
Nachricht: [SQL0189] ID für den codierten Zeichensatz 13488 ungültig. Ursache . . . . : Die ID für den codierten Zeichensatz (CCSID = Coded Character Set Identifier) 13488 ist aus einem der folgenden Gründe ungültig: -- Die CCSID ist keine EBCDIC-CCSID. -- Die CCSID wird vom System nicht unterstützt. -- Die CCSID ist für die Datenart nicht gültig. -- Wird die CCSID für Grafikdaten angegeben, muss die CCSID eine DBCS-CCSID sein. -- Wird die CCSID für UCS-2- oder UTF-16-Daten angegeben, muss die CCSID eine UCS-2- oder UTF-16-CCSID sein. -- Wird die CCSID für XML-Daten angegeben, muss sie eine SBCS- oder Unicode-CCSID sein. DBCS oder der Wert 65535 ist nicht zulässig. -- Wird die CCSID für CLOB-, DBCLOB- oder DATALINK-Daten angegeben, darf die CCSID nicht 65535 sein. -- Wird die CCSID für eine Ergebnisspalte der Funktion XMLTABLE angegeben, darf die CCSID nicht 65535 sein. -- Sind mehrere DATALINK-Spalten mit FILE LINK CONTROL vorhanden, müssen alle dieselbe CCSID haben. -- Die Klausel NORMALIZED kann nur für eine UTF-8- oder UTF-16-CCSID angegeben werden. Fehlerbeseitigung: Sicherstellen, dass alle CCSID-Werte in der Anweisung vom System unterstützt werden und für die Datenart zulässig sind. Eine Liste der gültigen CCSID-Werte enthält die Themensammlung zu DB2 for i SQL Reference in der Kategorie Datenbank im IBM i Information Center unter http://www.ibm.com/systems/i/infocenter/.
SQL DDL Statement für Tabelle
[CREATE TABLE KONZERN/CONTACT01P (
-- Schlüsselfelder
ObjectGUID FOR C01GUID CHAR(36) PRIMARY KEY,
ObjectClass FOR C01Class VARCHAR(20) NOT NULL,
DistinguishedName FOR C01DN VARCHAR(255) NOT NULL UNIQUE CCSID 1208,
-- Person
Nachname FOR C01NName VARCHAR(255) CCSID 1208,
Vorname FOR C01VName VARCHAR(255) CCSID 1208
....
Den CSV-Datensatz den ich versuche zu schreiben lautet:
"Land";"Pager";"ObjectGUID";"Rufnummer";"Vorname";"Deleted";"Firma";"Beschreibung";"Postfach";"Fax";"HiddenFromAddressList";"Privat";"EmailAddresses";"Büro";"PLZ";"E-Mail";"Info";"Enabled";"Initialen";"Landeskennzeichen";"IP-Telefon";"Abteilung";"Modified";"CommonName";"IsLinked";"Mobil";"ObjectClass";"Vorgesetzter";"Anzeigename";"Nachname";"SamAccountName";"UserPrincipalName";"DistinguishedName";"Webseite";"Ort";"Straße";"Bundesland";"Position"
"Tschechische Republik";;"e5a5ad1b-9b6e-4992-9978-384fac53f1c0";;"Kateřina";;"GUTMANN";"AD56";"";"";"True";;"";;"130 00";"xslukova@xx-group.com";;"False";"AD56";"CZ";;;"13.03.2015 10:33:11";"Sluková, Kateřina";"False";;"user";;"Sluková, Kateřina";"Sluková";"AD56";"AD56@XX.XX";"CN=Sluková\, Kateřina,OU=XX,OU=HGW,OU=XX,DC=XX,DC=XX";;"Ortschaft";"blabla";;
Momentan nutze ich die Variante mit der CCSID 1208, da ich die Daten nur mittels SQL u. C# verarbeite und sie damit korrekt dargestellt werden. Schöner wäre es aber, dass auch die Kollegen mit RPG die Sätze/Felder (ohne Umwege) lesen können.
In erster Linie stört mich momentan der Fehler bei CCSID 13488, den ich aber momentan nicht zu lösen vermag.
Im Anhang noch das komplette DDL Statement, der CSV Datensatz u. als PDF die festgehaltenen Erkenntnisse.
andreaspr@aon.at
18-01-16, 13:42
Dafür verwendest du nicht VARCHAR sonder VARGRAPHIC oder NVARCHAR.
lg Andreas