Firebird JDBC-Treiberverbindungszeichencodierung

8

Ich habe eine JSF-Anwendung auf Tomcat6 in Fedora 17 mit Firebird als Datenbank ausgeführt und alle Register aus der Datenbank in die Anwendung kommen mit einem Codierungsproblem.

Die Sprache ist brasilianisch portugiesisch, also brauche ich és und ã's und ç und hier haben alle diese Sonderzeichen Probleme.

Die és und ã's aus dem ursprünglichen Quellcode sind in Ordnung, nur die, die direkt aus der Datenbank kommen, machen mir das Problem ...

Irgendeine Idee was ist los?

Hier ist ein Bild, wo dieser seltsame Charakter sein sollte

Das Problem tritt auf, wenn es von der Datenbank wiederhergestellt wird.

    
Vitor Hugo 31.10.2012, 10:57
quelle

3 Antworten

19

Die Verwendung des Abfrageparameters encoding=ISO/UTF/WIN... in der URL der JDBC-Verbindung hat das Problem gelöst.

Zum Beispiel:

%Vor%     
Vitor Hugo 31.10.2012, 17:59
quelle
2

Wenn Sie das Verbindungszeichen in Jaybird nicht angeben (entweder die Eigenschaft encoding mit dem Firebird-Zeichensatznamen oder charSet mit einem Java-Zeichensatznamen), greift Jaybird auf das Firebird-Verbindungskonzept zurück Zeichensatz NONE , was bedeutet, dass der Server keine Zeichen aus der Speicherrepräsentation einer (VAR) CHAR-Spalte transkribiert und seine Bytes unverändert sendet.

Dies bedeutet, dass Jaybird eine Sequenz von Bytes in einem unbekannten Zeichensatz empfängt. Jaybird verwendet dann den Standardzeichensatz Ihrer Java-Installation, um diese Bytes in Zeichenfolgen zu konvertieren. Wenn also der Zeichensatz db (oder Spalte) nicht mit Ihrem Java-Zeichensatz übereinstimmt, kann dies zu falschen Ergebnissen führen. Noch schlimmer: Das Lesen und Schreiben dieser Art von verschiedenen Systemen mit unterschiedlichen Standard-Java-Zeichensätzen kann Gesamtmüll- oder Transliterationsfehler erzeugen.

Die Lösung: Geben Sie immer einen expliziten Verbindungszeichensatz an. Noch besser ist es, sicherzustellen, dass Ihre Datenbank über einen Standardzeichensatz verfügt (oder dass in jeder (VAR)CHAR -Spalte der Zeichensatz explizit definiert ist).

Die nächste Version von Jaybird (2.3) wird wahrscheinlich keine Verbindung herstellen, wenn kein expliziter Verbindungszeichensatz angegeben wurde, um Benutzer dazu zu zwingen, dieses Problem zu berücksichtigen (und wenn sie das alte Verhalten noch wollen, können sie encoding=NONE explizit angeben).

    
Mark Rotteveel 01.11.2012 13:53
quelle
0

Meine 2 Cent, seit ich von Google nach einer Antwort gesucht habe .. Ich hatte ein Problem mit interbase 7.5.80 mit Legacy-Jaybird-Treiber (v1.5). Jede Kodierung, die ich bei einer anderen Verbindung als 'NONE' verwendet habe, führte dazu, dass die Verbindung unterbrochen wurde. Schließlich habe ich 'NONE' weiter verwendet:

%Vor%

Und benutzte getBytes beim Erstellen einer neuen String-Instanz mit einer spezifischen Kodierung:

%Vor%

[rs ist ResultSet natürlich]

Viel Glück!

    
baraka 22.01.2015 12:56
quelle

Tags und Links