View Full Version : Unicode: UCS-2 (13488) oder UTF-8 (1208)
Hallo Forum,
mit welcher CCSID sollte die Datei (DDS) erstellt werden? 13488 für UCS-2 oder 1208 für UTF-8 bzw. 1200 für UTF-16 ?
Das Problem bei UCS-2 ist, dass alle CHAR Feder auf Graphic umgestellt werden müssen bei UTF8 nicht.
Habe ich evtl. bei der Konvertierung Probleme wenn ich UTF-8 verwende ?
:confused:
Wird bei UTF-16 auch ein Graphic Feld verlangt ?
:confused:
Gruß
UTF8 und UTF16 müssen auch speziell behandelt werden, da der Inhalt variabel lang ist (1-2 bzw 1-4 Bytes).
Wenn du z.B. ein 10-stelliges UTF8-Feld mit 10x 'Ü' füllst, benötigt der Inhalt 20 Stellen, es passt also nicht !
Im ILERPG benötigst du ggf. Konvertierfunktionen.
UCS-2 wird in ILERPG automatisch als Type C deklariert.
Beim EVAL musst du ggf. mit %CHAR() in SBCS und % UCS2() zurück konvertieren.
Für diese Varianten gibt es KEINE DSPF/PRTF-Unterstützung, du musst also programmtechnisch reagieren.
Auf der AS/400 fährst du am Besten mit UCS2.
Hallo zusammen,
meine Problematik passt hier gut rein, deshalb hänge ich mich hier einmal an.
Ich möchte Daten aus der DB2 auf einer utf8-Webseite darstellen und auch Eingaben entgegennehmen und auch wieder korrekt in der DB2 speichern.
Über die PHP-Extension ibm_db2 kann ich dazu Verbindung zur DB2 aufnehmen und Daten auslesen. Beim Auslesen von Daten erhalte ich den deutschen Zeichensatz geliefert. Allerdings wird als Client-CCSID die 65535 (keine Konvertierung) angenommen, so dass beim Speichern eine Konvertierung fehlschlägt. Leider finde ich bisher keine Möglichkeit die CCSID zu beeinflussen. Von der Logik her würde ich erwarten, dass man diese nach dem Verbindungsaufbau mittels db2_set_option setzen kann (ähnlich wie bei MySQL "SET NAMES utf8") - allerdings finde ich hier nichts derartiges. Auch die CCSID des für den Verbindungsaufbau benutzen Users wirkt sich nicht aus.
Wovon hängt die CCSID eines auf einem Apache laufenden PHP-Programms ab, welches sich per PHP-Extension ibm_db2 (letztlich also per ODBC) bei der DB2 anmeldet und wie kann man diese gezielt verändern?
Bin ich überhaupt auf dem richtigen Weg?
Mein Plan:
- DB2 Tabellen als ucs-2 definieren
- connect von PHP zur DB2 auf ucs-2 setzen (da ist die Frage wie?)
- per PHP die UCS-2 Daten intern für die Ausgabe in utf-8 wandeln und beim Speichern den umgekehrten Weg gehen
Für Hinweise, Beurteilungen und Tipps wäre ich sehr dankbar.
Für Job's gilt die Default-CCSID QCCSID des Systems.
Für abweichende Benutzer-Einstellungen kann man im USRPRF noch eine LOCALE angeben (Muster sind in der Lib QSYSLOCALE, erstellt mit CRTLOCALE).
Per SETJOBATR des CRT/CHGUSRPRF kann man dann z.B. die CCSID aus der LOCALE übernehmen.
Bei der Verbindung kann man nur angeben, dass CCSID 65535 beim Lesen/Schreiben in die Default-CCSID (ergibt sich aus QLANGID) gewandelt werden soll.
Beim Schreiben per ODBC müssen die Parameter als VARWCHAR/WCHAR definiert sein, Default ist nur VARCHAR/CHAR.
Wird der SQL insgesamt zusammengebaut, so muss bei der Verbindung bereits eingestellt werden, dass der gesamte SQL-String als UCS2 übergeben wird.
Ansonsten gibts Verluste.
Besser ist es, mit Parametermarkern "?" und expliziter Parameterdefinition zu arbeiten.
Vielen Dank für dei Antwort.
Für abweichende Benutzer-Einstellungen kann man im USRPRF noch eine LOCALE angeben
Wie eingangs erwähnt ändert eine andere Einstellung der CCSID im Userprofil leider nichts. Die Vorschläge bzgl. LOCALE fruchten auf unserem System leider nicht, da es weder eine QSYSLOCALE noch eine QLANGID zu geben scheint. (Sorry, ich kann das technisch nicht vernünftig ausdrücken, da ich mich mit PHP beschäftige und mit dem AS400-Umfeld an sich wenig zu tun habe).
Wird der SQL insgesamt zusammengebaut, so muss bei der Verbindung bereits eingestellt werden, dass der gesamte SQL-String als UCS2 übergeben wird.
Genau das ist ja meine Frage. Wie "sage" ich der Verbindung, dass ich ucs2 empfangen möchte und ebenso senden werde?
Ich arbeite mit IBM DB2, Cloudscape and Apache Derby Functions (http://de.php.net/manual/de/ref.ibm-db2.php)und finde keinen Weg das gezielt zu steuern.
DB2-Cloudescape hat ja mit AS/400 nix am Hut sondern ist eine ja eine eigene DB.
CCSID's spielen da überhaupt keine Rolle, da ja sowieso alles in Java ist (Unicode ist da Standard).
Die QSYSLOCALE kann separate installiert werden und ist eine Bibliothek.
Man kann dann eine Locale erstelle (z.B. DE_DE.locale) und diese dem USRPRF zuordnen. Desweiteren gibt man im USRPRF dann an, dass die CCSID aus der Locale beim Job angewendet werden soll.
QCCSID und QLANGID sind Systemwerte (WRKSYSVAL).
Wie nun die Verbindungseinstellungen über PHP gemacht kann ich nicht sagen.
Über ODBC kann man in der Konfiguration angeben dass der SQL-String selber als Unicode gesendet werden soll.
Dies betrifft SQL's, die eben zusammengebaut werden, wie:
"select ... from myfile where key='abcd'"
Bei Verwendung von Markern entscheidet der Parametertyp:
"select ... from myfile where key=?"
Der SQL selber muss hierfür nicht in Unicode sein.
Beim Lesen von Resultsets/Recordsets sind die Unicode-Spalten auch automatisch in Unicode, da dies durch die Tabelle bestimmt wird. Eine Umsetzung ist da nicht erforderlich.
DB2-Cloudescape hat ja mit AS/400 nix am Hut sondern ist eine ja eine eigene DB.
Ich kann damit auf die bereits im System vorhandenen Datenbanken zugreifen (und genau dafür ist diese PHP-Extension auch gedacht). Wäre es ein eigenes DB-System, so wären keine Daten vorhanden und man müsste erst Datenbanken/Tabellen anlegen.
CCSID's spielen da überhaupt keine Rolle, da ja sowieso alles in Java ist (Unicode ist da Standard).
...
Beim Lesen von Resultsets/Recordsets sind die Unicode-Spalten auch automatisch in Unicode, da dies durch die Tabelle bestimmt wird. Eine Umsetzung ist da nicht erforderlich.
Das kann ich nicht bestätigen und stimmt so nach meiner bisherigen Forschungsarbeit nicht! Wenn Deine Annahme stimmen würde, dann bekäme ich bei einem SELECT Zeichen in Unicode. Das ist aber nicht der Fall - ich bekomme die Zeichen in ISO 8859-1 geliefert (mein User ist auf CCSID 273 eingestellt).
Intern hat das System, und optional jede Datei, jede Datenbank und jede Tabelle eine eigene CCSID. Ist keine vorgegeben, so greift die CCSID der übergeordneten Instanz.
Je nach zugreifendem Prozess/User, der ebenso eine CCSID besitzt, wandelt die AS400 die Zeichen in den jeweiligen Zeichensatz wenn sie sich unterscheiden und zwar in beide Richtungen (lesen/schreiben).
Dies erscheint auch logisch. Wenn Zeichenketten in einem SQL-Query übergeben werden, dann muss bekannt sein, wie diese interpretiert werden müssen, damit die AS400 weiß von welchem Quellzeichensatz in welchen Zielzeichensatz konvertiert werden muss.
Du benutzt dann nicht die Cloudescape selber sondern nur den DB2-Zugriff zur AS/400.
In diesem Fall hast du natürlich Recht.
Soweit ich bei Cloudescape nachlesen konnte, handelt es sich dabei auch um eine embedded oder auch Servervariante einer in Java geschriebenen Datenbank.
Zu diesem DB2-Connect selber kann ich nichts sagen.
Greife ich aber über ODBC bzw. OLEDB auf die AS/400 zu, werden UCS2-Felder einer Tabelle auch als UCS2 (WChar) im Resultset geliefert.
Beim Schreiben über Command-Objekte mit Parametermarkern und eigener Definition als WChar, werden die Daten auch korrekt als UCS2 in die DB geschrieben.
Eine Umwandlung der Zeichen erfolgt generell nicht.
Für alle anderen CCSID's des Typ's SBCS gilt natürlich die Umsetzung in den entsprechenden Zeichensatz, wobei auf der AS/400 die Job- und DB-CCSID gilt und lokal die Windows-Spracheinstellung (bei mir eben Codepage 1252).
Greife ich aber über ODBC bzw. OLEDB auf die AS/400 zu, werden UCS2-Felder einer Tabelle auch als UCS2 (WChar) im Resultset geliefert.
...
Für alle anderen CCSID's des Typ's SBCS gilt natürlich die Umsetzung in den entsprechenden Zeichensatz
Ah, das könnte der kleine aber feine Unterschied sein. Bisher habe ich noch keine UCS2-Felder definiert, da ja bereits bei den anderen Feldern Konvertierungsprobleme auftreten.
Ein reines UCS2 Feld werde ich gleich einmal testen und Bericht erstatten.
Vielen Dank. ;)
Hier ist auch noch einmal eine Quelle, die Fuerchau's Aussagen noch einmal bestätigen. Vielleicht ist das für den ein oder anderen noch einmal nützlich:
Release Notes (http://support.mdl.ru/Pc_compl/Doc/Db2/v7.1/en/Html/db2ir/db2ir312.htm)
Release Notes (http://support.mdl.ru/Pc_compl/Doc/Db2/v7.1/en/Html/db2ir/db2ir314.htm#HDRCLIREFERENCE)
Es spielen so viele Faktoren eine Rolle, dass ich mittlerweile verunsichert bin, Fehlerquelle für Fehlerquelle ausschließen will und das noch einmal in aller Ruhe durchtesten werde. Drückt mir die Daumen. ;)