View Full Version : Allgemeine Verwendung von Unicode
Dafür verwendest du nicht VARCHAR sonder VARGRAPHIC oder NVARCHAR.
Hallo Andreas, danke für die schnelle Antwort. Ich habe im DDL Statement auf NVARCHAR abgeändert u. die Angabe der CCSID weggelassen. Per SQL klappt es weiterhin, per WRKQRY oder DFU werden die Werte auch wieder unleserlich dargestellt. Kann dann RPG dann damit umgehen? (Habe jetzt kein Testprogramm zur Hand).
"Hierfür gibt es native Unterstützung im ILERPG. Der Feldtyp ist "C" und mittels %UCS2 sowie %CHAR kann ich zwischen UCS2 und SBSC(*JOB) konvertieren." (Zitat Fuerchau, http://newsolutions.de/forum-systemi-as400-i5-iseries/threads/19794-VARCHAR-Felder(UTF-8)-und-ILE-RPG?highlight=CCSID)
Wenn die Inhalte in Query usw. falsch dargestellt werden, steht die Job-CCSID meist auf *HEX.
Von NVARCHAR (VARGRAPHIC, CCSID 13488, UCS2) in die JOB-CCSID klappt automatisch.
Von CCSID-1208 klappt das leider nicht. Hier muss die "leserliche" Konvertierung programmiert werden (Cast in SQL, API iConv(), o.ä.).
UCS2 wird native von ILERPG als Feldart "C" unterstützt.
Hallo,
mit der CCSUD 13488 können Queries und SQL umgehen.
CREATE TABLE /T01P (FNAME VARGRAPHIC ( 50) CCSID 13488 NOT NULL WITH DEFAULT, FNAME2 GRAPHIC ( 50) CCSID 13488 NOT NULL WITH DEFAULT)
gruß
Michael
Ja, aber auch nur dann, wenn der Job auf einer gültigen CCSID ungleich 65535 steht.
Sonst gibt's wieder Schrott auf dem Schirm.
Dem ILERPG ist die CCSID egal wenn die Variable vom Typ C ist, allerdings: der Move/Eval in eine A-Variable liefert dann auch Schrott.
Danke soweit, jetzt bin ich schon ein gutes Stück weiter.
Ja so wie es für mich aussieht, ist meine JOBID leider 65535
Sprachen-ID . . . . . . . . . . . . . . . . . . . : DEU
Landes- oder Regions-ID . . . . . . . . . . . . . : DE
ID des codierten Zeichensatzes (CCSID) . . . . . : 65535
Standard-ID des codierten Zeichensatzes . . . . . : 273
Steuerung für Zeichen-ID . . . . . . . . . . . . : *DEVD
Hätten die vorherigen Versuche auch funktioniert, wenn hier die ID ungleich 65535 gewesen wäre oder funktioniert die Darstellung trotzdem nur mit VarGraphic korrekt?
Kann ich den Wert (temporär) abändern, wenn ja, wie? Welcher Wert ist für wohl für meinen Fall sinnvoll - 13488? Darzustellen sollten deutschsprachige Inhalte und Osteuropäische Zeichen sein.
Zur Info noch: Das SQL-DDL Statement mit Vargraphic u. CCSID 13488 lies sich ausführen.
Danke soweit, jetzt bin ich schon ein gutes Stück weiter.
Ja so wie es für mich aussieht, ist meine JOBID leider 65535
Sprachen-ID . . . . . . . . . . . . . . . . . . . : DEU
Landes- oder Regions-ID . . . . . . . . . . . . . : DE
ID des codierten Zeichensatzes (CCSID) . . . . . : 65535
Standard-ID des codierten Zeichensatzes . . . . . : 273
Steuerung für Zeichen-ID . . . . . . . . . . . . : *DEVD
Hätten die vorherigen Versuche auch funktioniert, wenn hier die ID ungleich 65535 gewesen wäre oder funktioniert die Darstellung trotzdem nur mit VarGraphic korrekt?
Kann ich den Wert (temporär) abändern, wenn ja, wie? Welcher Wert ist für wohl für meinen Fall sinnvoll - 13488? Darzustellen sollten deutschsprachige Inhalte und Osteuropäische Zeichen sein.
Zur Info noch: Das SQL-DDL Statement mit Vargraphic u. CCSID 13488 lies sich ausführen.
Hallo,
wenn man mit Zeichensätzen arbeitet wird ja wohl kein Job im System auf 65535 stehen.
Für die interaktive Session kann der Befehl CHGJOB für das setzen der CCSID verwendet werden
gruß
Michael
"Wenn man mit Zeichensätzen arbeitet..."
Dies ist keine Kann-Bedingung!
Bei SQL Create Table erhält automatisch jedes Zeichenfeld die "Standard ID".
Bei Create PF per DDS erhält die PF die "Standard ID".
In der Terminal-Session muss eine Hostcodepage ausgewählt werden.
Die Systemtabellen (QSYS, QUSRSYS, QSYS2) haben alle die CCSID der Primär-Sprache des Systems.
Seit (ich glaube V7R1) werden einige Basistabellen in der QSYS in UCS2 ausgeliefert und somit in den QSYS2-Views ebenso.
Somit sollte seit Anbeginn der AS/400 immer mit der korrekten QCCSID zur Primärsprache ein System eingestellt sein. Dann gibt es die wenigsten Probleme.
STRSQL, WRKQRY arbeiten bei der Ausgabe in SBCS da der Bildschirm per Default kein UCS2 unterstützt. Also werden UCS2-Daten in die Job-CCSID (nicht die Standard-ID!) umgewandelt und angezeigt. Bei Job-CCSID 65535 findet grundsätzlich keine Codewandlung statt, die Daten werden binär angezeigt.
CCSID's für UTF-8/16 werden leider native für Codewandlung nicht unterstützt.
Hallo zusammen,
ich greife das Thema Unicode / 5250 nochmals an dieser Stelle auf.
Was habe ich bisher:
- Meine Datenbanken sind mit CCSID 13488 per DDS erstellt.
- das DSPF besitzt seinerseits Graphics Felder mit CCSID 13488 20
Das ganze wird nun über ILR-RPG hin und her geschoben. Zur Anzeige wird der 5250 Emulator der iAccess Solutions V1.1.8.0 64-Bit verwendet. Mit der Schriftart "WT SansDuo J" kann ich jetzt die meisten Schriften darstellen (West-/Osteuropa, Arabisch, Russisch ...)
Was mir leider nicht gelingen will sind die asiatischen Schriftzeichen. Japanisch geht teilweise aber Chinesisch oder Thailändisch funktioniert leider kein Zeichen.
Wie bekomme ich denn ALLE Zeichen mit einer Einstellung des Emulators dargestellt? Sollte doch mittlerweile möglich sein, oder ?!?
PS: Es sollen alle Sprachen aus der DB angezeigt UND geschrieben werden können
Viele Grüße Sascha
Das liegt leider immer noch an den Fonts!
Diejenigen, die Schriften entwickeln, stürzen sichhalt nur auf genau das, was gebraucht wird.
Somit gibt es tatsächlich wohl kaum eine Schrift die wirklich alles enthält.
Per Windows "Zeichentabelle" kann man das schön sehen.
Nun haben Anwendungen wie Office/Web u.ä. eben kein Problem damit, für jedes Zeichen einen speziellen Font auszuwählen.
Bei der 5250 geht das leider nicht.
Aber vielleicht hilft dir dies ja weiter:
https://page-online.de/typografie/eine-schrift-fuer-die-ganze-welt/
Das Hauptproblem wird u.U. sein, dass die meisten Schriften ja wegen proportional ggf. ungeeignet sind.
Langfristig solltest du dann 13488 durch 1200 und bei SQL statt graphic mit nchar/nvarchar arbeiten.