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.
Die Verwendung des Abfrageparameters encoding=ISO/UTF/WIN...
in der URL der JDBC-Verbindung hat das Problem gelöst.
Zum Beispiel:
%Vor% 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).
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!