-
Allgemeine Verwendung von Unicode
Hallo,
ich beschäftige mich gerade mit dem Unicode-Thema auf der AS/400. Grundsätzlich ist das ganze sehr spannend, habe jedoch ein paar Verständnisfragen:
*) Wenn in einer Tabelle auf einem arabische System Datensätze gespeichert werden und ich importierte mir diese Tabelle auf mein System (CCSID 273, bzw. 1140), können dann diese Zeichen bei mir überhaupt angezeigt werden?
Vlt. sogar gleichzeitig mit Datensätze aus einem Chinesischen und Russischen System?
Benötige ich dafür evtl. zusätzliche Sprachen installiert?
*) Ist denn der Apache auf der AS/400 Unicode fähig?
Denn wir schreiben mittels des QtmhWrStout-Apis, HTML-Code aus RPG an den Client-Browser.
Hat jemand schon erfahrungen mit Unicoe auf verschiedenen Sprach-Systemen?
Danke!
lg Andreas
-
... hier muss man unterscheiden zwischen Anzeige und Datenbank. Was angezeigt werden kann, hängt immer vom Frontend ab. Was abgespeichert werden kann, von der Tabledefinition. Was die Datenbank angeht, ist es nach meiner Erfahrung am Besten die CCSID auf Feldebene zu definieren (ist eh am Besten, da man für Schlüsselfelder kein Unicode, oder Varchar (eine beleibte Oracle Unsitte) verwenden sollte.
Was das Frontend angeht, kann 5250 (fast) immer nur eine Sprache korrekt darstellen und bei Browser Anzeigen sollte man alles crude als Entities schicken. Mit chinesisch und arabisch habe ich mich da allerdings auch noch nicht beschäftigt.
D*B
Zitat von andreaspr@aon.at
Hallo,
ich beschäftige mich gerade mit dem Unicode-Thema auf der AS/400. Grundsätzlich ist das ganze sehr spannend, habe jedoch ein paar Verständnisfragen:
*) Wenn in einer Tabelle auf einem arabische System Datensätze gespeichert werden und ich importierte mir diese Tabelle auf mein System (CCSID 273, bzw. 1140), können dann diese Zeichen bei mir überhaupt angezeigt werden?
Vlt. sogar gleichzeitig mit Datensätze aus einem Chinesischen und Russischen System?
Benötige ich dafür evtl. zusätzliche Sprachen installiert?
*) Ist denn der Apache auf der AS/400 Unicode fähig?
Denn wir schreiben mittels des QtmhWrStout-Apis, HTML-Code aus RPG an den Client-Browser.
Hat jemand schon erfahrungen mit Unicoe auf verschiedenen Sprach-Systemen?
Danke!
lg Andreas
-
Mit dem Unicode in der DB (CCSID 13488) wirst du da keine Probleme bekommen.
Allerdings wird das nur in ILERPG auch unterstützt (Feldtyp C).
In RPG kannst du diese Tabellen nicht verarbeiten.
Ein Problem stellt das API QtmhWrStout dar. Hierfür musst du die Daten in UTF-8 (CCSID 1208) konvertieren und als Zeichensatz für deine HTM-Datei (oder was immer du ausgibst) auch UTF-8 wählen.
-
Ein Dank an die Spezialisten!
Was ist eigentlich der Unterschied zw. CCSID 1200 und 13488? Im Internet findet man nur wenig Informationen über die Unterschiede, außer der Abschluss-Code.
@Bender: Was meinst du genau mit "alles crude als Entities schicken"?
Noch die letzte Frage zum Api QtmhWrStout. Der HTML-Code ist direkt im PGM hinterlegt. Der Parameter vom Api ist CHAR(*). Ist das mit UTF8 kompatible? Auch wenns warscheinlich eine blöde Frage ist.
Vielen Dank für die Hilfe!
-
CCSID 1200 ist UCS2 oder UniCode für Arme und Kranke und CCSID 13488 the real stuff (hoffe ich zumindest).
Mit crude meine ich statt ü @uuml; und so weiter.
Zu dem QtmhWrStout mag jemand anderes Stellung nehmen.
D*B
Zitat von andreaspr@aon.at
Ein Dank an die Spezialisten!
Was ist eigentlich der Unterschied zw. CCSID 1200 und 13488? Im Internet findet man nur wenig Informationen über die Unterschiede, außer der Abschluss-Code.
@Bender: Was meinst du genau mit "alles crude als Entities schicken"?
Noch die letzte Frage zum Api QtmhWrStout. Der HTML-Code ist direkt im PGM hinterlegt. Der Parameter vom Api ist CHAR(*). Ist das mit UTF8 kompatible? Auch wenns warscheinlich eine blöde Frage ist.
Vielen Dank für die Hilfe!
-
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!
Von der DB wird automatisch nur die 13488 unterstützt. Hier wird beim Lesen/Schreiben aus SBCS-Feldern automatisch (mit Verlusten) zwischen Job-CCSID und 13488 gewandelt.
Bei Verwendung des Feldtyps C (ILERPG) bleibt die Kodierung von 13488 erhalten. Für die Konvertierung zwischen den Variablen stehen die Builtin-Funktionen %CHAR (UCS2->SBCS) und % UCS2(SBCS->UCS2) zur Verfügung.
Was die Ausgabe von HTML-Code angeht, so gibt man normalerweise im Kopf das Encoding an, default ist meistens ISO-8859-1, was westeuropäisch ist.
Wenn du UTF-8 in die HTML-Datei schreiben willst, so ist das Encoding im Header auch auf UTF-8 umzustellen.
Um per Programmcode UTF-8 auszugeben musst du hierfür leider Konverierungs-API's bemühen, da die CCSID 1208 direkt von ILERPG nicht unterstützt wird.
Convert a Graphic Character String (CDRCVRT, QTQCVRT) API
iSeries Information Center
-
Ergänzung: mit SQL (CAST, CHAR und GRAPHIC) kann man am einfachsten konvertieren, ich habe bisher noch nichts gefunden, was da nicht ging, unabhängig von der Job CCSID.
D*B
Zitat von Fuerchau
-
Mit CAST kann man zwar in beliebige CCSID's konvertieren, aber alle SBCS-CCSID's werden schlussendlich wieder in die Job-CCSID umgewandelt!
Einzig UCS2/UTF8/UTF16 und 65535 (*HEX) werden nicht umgewandelt.
Mein Job steht auf CCSID 273.
Caste ich z.B. ein Feld von CCSID 273 direkt in 297 werden die Zeichen für den Job wieder in 273 zurückgewandelt.
Möchte ich explizit die Daten anders interpretieren muss ich mittels Zwischenschritt erst in CCSID 65535 casten und dieses Ergebnis in die Zielccsid, was allerdings wieder in die Jobccsid gewandelt wird.
Dies gilt auch für JDBC/ODBC-Verbindungen.
Ein weiteres Problem besteht wohl noch in der Ausgabe auf STDOUT.
Ich nehme mal an, dass die Ausgabe in eine IFS-Datei umgeleitet wird.
Nun erfolgt, je nach CCSID dieser IFS-Datei auch wiederum eine Umwandlung von der Job-CCSID in die IFS-CCSID bzw., wenn die IFS-Datei auch auf z.B. 273 steht, muss spätestens bei der Anzeige in einem Browser die Konvertierung in z.B. 1252 erfolgen.
Wenn hier nun selber UTF-8 ausgegeben wurde weiß das System das ja nicht, nimmt dann eben EBCDIC an und wandelt die UTF-8 von EBCDIC in die Ziel-CCSID, was zu Schrott führen wird.
Hier gibts leider nur die Lösung, IFS-Dateien per IFS-API's zu erstellen, die Datei ohne Codewandlung mit CCSID 1252 zu erstellen und alle Codewandlungen in UTF-8 dann im Programm durchzuführen.
-
Vielen Dank für die vielen Infos!!
Ins IFS wird - nach dem was ich jetzt gelesen habe, Gott sein dank! - nichts geschrieben. Der HTML-Code wird direkt via Web-API zum Client geschickt.
Auf das mit dem CCSID hin und her Casten und dann wieder zurück zur Job-CCSID bin letztens auch beim Testen gestoßen.
Die Perfomance ist da sicher auch nicht zu vernachlässigen, da eine CCSID Translation erst in 6.1 von der SQE unterstützt wird.
Danke nochmals! Jetzt kann ich mir schon ein besseres Bild mit diesem Thema machen.
-
... das mit der SQÈ, das ist alles Marketing Gesülze und bezieht sich in erster Linie auf die Tätigkeit des Optimizers. Durchhänger gibt es, wenn Indexe fehlen, oder das Datenbankdesign Murks ist, alles andere ist Pille Palle!
D*B
Zitat von andreaspr@aon.at
Vielen Dank für die vielen Infos!!
Ins IFS wird - nach dem was ich jetzt gelesen habe, Gott sein dank! - nichts geschrieben. Der HTML-Code wird direkt via Web-API zum Client geschickt.
Auf das mit dem CCSID hin und her Casten und dann wieder zurück zur Job-CCSID bin letztens auch beim Testen gestoßen.
Die Perfomance ist da sicher auch nicht zu vernachlässigen, da eine CCSID Translation erst in 6.1 von der SQE unterstützt wird.
Danke nochmals! Jetzt kann ich mir schon ein besseres Bild mit diesem Thema machen.
-
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/sof...utf8_demo.html
könnte da noch von Interesse sein.
D*B
PS: warum macht man sowas nicht mit Java?
Similar Threads
-
By Stannek in forum IBM i Hauptforum
Antworten: 1
Letzter Beitrag: 23-01-07, 07:36
-
By bode in forum IBM i Hauptforum
Antworten: 1
Letzter Beitrag: 30-10-06, 11:10
-
By KM in forum IBM i Hauptforum
Antworten: 10
Letzter Beitrag: 12-04-05, 09:57
-
By KM in forum IBM i Hauptforum
Antworten: 9
Letzter Beitrag: 03-09-04, 11:46
-
By MrBonZai in forum NEWSboard Programmierung
Antworten: 6
Letzter Beitrag: 21-06-04, 11:24
Berechtigungen
- Neue Themen erstellen: Nein
- Themen beantworten: Nein
- You may not post attachments
- You may not edit your posts
-
Foren-Regeln
|
Erweiterte Foren Suche
Google Foren Suche
Forum & Artikel Update eMail
AS/400 / IBM i
Server Expert Gruppen
Unternehmens IT
|
Kategorien online Artikel
- Big Data, Analytics, BI, MIS
- Cloud, Social Media, Devices
- DMS, Archivierung, Druck
- ERP + Add-ons, Business Software
- Hochverfügbarkeit
- Human Resources, Personal
- IBM Announcements
- IT-Karikaturen
- Leitartikel
- Load`n`go
- Messen, Veranstaltungen
- NEWSolutions Dossiers
- Programmierung
- Security
- Software Development + Change Mgmt.
- Solutions & Provider
- Speicher – Storage
- Strategische Berichte
- Systemmanagement
- Tools, Hot-Tips
Auf dem Laufenden bleiben
|
Bookmarks