Firebird JDBC-Treiber, connection-character-encoding
Ich habe eine JSF-Anwendung läuft auf tomcat6 in Fedora 17 mit firebird als Datenbank-und alle Register aus der Datenbank kommen zur Anwendung kommen-mit einem encoding-problem.
Die Sprache ist brasilianisches Portugiesisch, so muss ich mich é s und ã s und ç und hier alle diese Sonderzeichen kommen mit Problemen.
Den é ' s und ã s aus dem original-Quellcode sind ok, nur diejenigen, die kommen direkt aus der Datenbank verursacht mir die Mühe...
Irgendeine Idee was Los ist?
Hier ein Bild, wo dieser komische Zeichen sollte é
Das problem passiert, wenn er erholt sich von der DB.
- JSF-1.x oder 2.x? Die "Probleme" genau redest du? Bitte mehr Details. Welche Zeichen sehen Sie stattdessen? Bei welchem Schritt genau es zeigt falsche Zeichen? Direkt nach dem abrufen von DB in Java-code? Oder nur in der generierten HTML-Ausgabe?
- Was ist der Standard-Zeichensatz der DB (oder der bestimmten Spalten), was ist die Verbindung characterset, werden diese Daten aus einem BLOB SUB_TYPE TEXT oder einem (VAR)CHAR?
- habe versucht, weitere Informationen hinzufügen
- Du bist immer noch nicht klar, Wann genau es scheitert. Bitte erläutern Sie das problem in der Perspektive eines Entwicklers, nicht in enduser-Perspektive. Um zu beginnen, im code direkt nach dem abrufen der Daten aus der DB, setzen Sie einen debug Haltepunkt oder ein logger oder ein system.aus.println, so dass Sie untersuchen können, wenn der JDBC-Treiber hat, decodiert es richtig. Beachten Sie, dass sollten Sie unbedingt darauf achten, dass Ihre IDE und der logger/stdout der Konsole selbst auch mit dem richtigen charset (D. H. Sie müssen in der Lage sein zu tun
System.out.println("éãç")
und sehen Sie es als-ist in der Konsole). - Beachten Sie, dass ich davon ausgehen, dass die Zeichen werden richtig gespeichert in der DB. Also wenn man sich in die DB direkt mit einigen DB-admin-tool, werden diese Zeichen sollten nur schön Aussehen. Sonst hat es keinen Sinn zu posten, wie eine JSF-problem in den ersten Platz. Wie bist du mit JSF 2.x (die bereits standardmäßig UTF-8 in allen Schichten), ich denke mehr und mehr, dass das problem tatsächlich in der DB setup-oder JDBC-Treiber-Konfiguration.
- Hier, an meinem Projekt, die Daten werden korrekt gespeichert und korrekt gerendert, ohne ein problem. Dies ist ein TOMCAT problem und es kann nur sein, weil alles andere OK ist, es sei denn, bei der Ausführung auf die Standard-installation von Tomcat auf linux-client-server... Vielleicht sollte ich entfernen, die anderen tags
- Wenn Sie nicht angeben, eine Verbindung characterset, dann Jaybird wird, verwenden Sie NONE, was bedeutet, dass die bytes von dem server konvertiert werden mithilfe der Java-Standard-characterset. Wenn das also nicht der gleiche wie der Standard-characterset auf den anderen server, dann können Sie unterschiedliche Ergebnisse erhalten.
- Dank mark, die mir geholfen haben das problem zu lösen...
- Victor, Sie halten scheitern zu erarbeiten, dieses problem in der Perspektive eines Entwicklers und halten Sie die Schuld Tomcat. In Zukunft Fragen sind, bitte verbringen Sie ein wenig mehr Aufwand in debugging/logging/tracking.
- Ich hören Sie Balus und ich muss zugeben, für mich ist es mehr eine Sprache, die Schwierigkeit zu erarbeiten, als wirklich Zeit damit verbracht, zu verstehen,... ich entschuldige mich dafür, und ich werde weiter daran gearbeitet. (Ich bin auch eine Menge zu lernen hier)
Du musst angemeldet sein, um einen Kommentar abzugeben.
Mit
encoding=ISO/UTF/WIN...
query-parameter im JDBC-Verbindungs-URL hat das problem gelöst.Beispiel:
Wenn Sie nicht geben Sie die Verbindungs-Zeichensatz in Jaybird (entweder Eigentum
encoding
mit der Firebird-character-set-name, odercharSet
mit einem Java-character-set-name), dann Jaybird fällt zurück auf die Firebird Konzept der Verbindung ZeichensatzNONE
, was so viel bedeutet wie, dass der server nicht transliterate Zeichen aus der speicherdarstellung eines (VAR)CHAR-Spalte und sendet die bytes so wie Sie ist.Dies bedeutet, dass Jaybird erhält eine Folge von bytes in einer unbekannten Zeichensatz. Jaybird werden dann mit den default-Zeichensatz, der Ihre Java-installation zu konvertieren, diese bytes zu strings. Also, wenn die db (oder Spalte) Zeichensatz stimmt nicht mit Ihrer Java-Zeichensatz, dann kann es zu falschen Ergebnissen führen. Noch schlimmer: Lesen und schreiben auf diese Weise aus verschiedenen Systemen mit verschiedenen Standard-java-Zeichensätze können produzieren totalen Müll oder transliteration Fehler.
Die Lösung: geben Sie immer eine explizite Verbindung Zeichensatz. Noch besser ist es, stellen Sie sicher, dass Ihre Datenbank hat einen Standard-Zeichensatz (oder, dass jeder
(VAR)CHAR
Spalte hat seinen Zeichensatz explizit definiert).Die nächste version von Jaybird (2.3) wird sich wahrscheinlich weigern, zu schließen, wenn keine explizite Verbindung Zeichensatz angegeben wurde, Benutzer zu zwingen, dieses Thema zu erörtern (und wenn Sie wollen immer noch das alte Verhalten, dann können Sie explizit angeben
encoding=NONE
).My 2 cents, da ich hier per Google nach einer Antwort zu suchen..
Ich hatte ein Problem mit interbase 7.5.80 mit legacy-jaybird-Treiber (v1.5).
Jede Codierung, die ich für die Verbindung verwendet anderes als 'NONE' endete mit dem timeout immer eine Verbindung.
Schließlich hielt ich mit 'NONE':
Und verwendet getBytes beim erstellen Sie eine neue String-Instanz mit einem bestimmten encoding:
[rs ist ResultSet natürlich]
Glück!