[NEWSboard IBMi Forum]
Seite 2 von 3 Erste 1 2 3 Letzte
  1. #13
    Registriert seit
    Aug 2003
    Beiträge
    1.488
    @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!

  2. #14
    Registriert seit
    Aug 2003
    Beiträge
    1.488
    Zitat Zitat von Fuerchau Beitrag anzeigen
    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.

  3. #15
    Registriert seit
    Feb 2001
    Beiträge
    18.682
    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.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: http://www.fuerchau.de/software/upload400.htm
    BI? Da war doch noch was: http://www.ftsolutions.de

  4. #16
    Registriert seit
    Aug 2001
    Beiträge
    2.640
    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
    Birgitta Hauser

    Anwendungsmodernisierung, Beratung, Schulungen, Programmierung im Bereich RPG, SQL und Datenbank
    IBM Champion 2020
    Virtuelle SQL und RPG Schulungen

  5. #17
    Registriert seit
    Aug 2003
    Beiträge
    1.488
    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!

  6. #18
    Registriert seit
    Mar 2002
    Beiträge
    4.930
    UTF-16/UCS-2 - Wikipedia, the free encyclopedia
    http://en.wikipedia.org/wiki/Plane_(Unicode)

    Zitat Zitat von andreaspr@aon.at Beitrag anzeigen
    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!
    AS400 Freeware
    http://www.bender-dv.de
    Mit embedded SQL in RPG auf Datenbanken von ADABAS bis XBASE zugreifen
    http://sourceforge.net/projects/appserver4rpg/

  7. #19
    Registriert seit
    Sep 2008
    Beiträge
    67

    Question CCSID 13488 gewünscht, aber nicht möglich - nur CCSID 1208 funktioniert für Felder

    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:
    Code:
    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
    Code:
    [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:
    Code:
    "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.
    Angehängte Dateien Angehängte Dateien

  8. #20
    Registriert seit
    Aug 2003
    Beiträge
    1.488

  9. #21
    Registriert seit
    Sep 2008
    Beiträge
    67
    Zitat Zitat von andreaspr@aon.at Beitrag anzeigen
    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...ighlight=CCSID)

  10. #22
    Registriert seit
    Feb 2001
    Beiträge
    18.682
    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.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: http://www.fuerchau.de/software/upload400.htm
    BI? Da war doch noch was: http://www.ftsolutions.de

  11. #23
    Registriert seit
    Jan 2001
    Beiträge
    779
    Hallo,

    mit der CCSUD 13488 können Queries und SQL umgehen.
    PHP-Code:
    CREATE TABLE /T01P (FNAME VARGRAPHIC 50CCSID 13488 NOT NULL WITH DEFAULT, FNAME2 GRAPHIC 50CCSID 13488 NOT NULL WITH  DEFAULT) 
    gruß
    Michael

  12. #24
    Registriert seit
    Feb 2001
    Beiträge
    18.682
    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.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: http://www.fuerchau.de/software/upload400.htm
    BI? Da war doch noch was: http://www.ftsolutions.de

Ähnliche Themen

  1. Verwendung von Modulen
    Von Stannek im Forum IBM i Hauptforum
    Antworten: 1
    Letzter Beitrag: 23-01-07, 07:36
  2. Allgemeine Berechtigung für Jobs ... IFS Ordner ...
    Von bode im Forum IBM i Hauptforum
    Antworten: 1
    Letzter Beitrag: 30-10-06, 11:10
  3. Druckausgabe mit Unicode
    Von KM im Forum IBM i Hauptforum
    Antworten: 10
    Letzter Beitrag: 12-04-05, 09:57
  4. iSeries und UNICODE
    Von KM im Forum IBM i Hauptforum
    Antworten: 9
    Letzter Beitrag: 03-09-04, 11:46
  5. Verwendung von NULL bzw. NULLIND
    Von MrBonZai im Forum NEWSboard Programmierung
    Antworten: 6
    Letzter Beitrag: 21-06-04, 11:24

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •