Firebird pilote JDBC connexion encodage des caractères

J'ai un JSF application en cours d'exécution sur tomcat6 dans Fedora 17, à l'aide de firebird que la base de données et tous les registres provenant de la base de données de l'application sont à venir avec un problème d'encodage.

La langue est le portugais du brésil, j'ai donc besoin é s et ã et ç et ici l'ensemble de ces caractères spéciaux viennent avec des problèmes.

La é s et ã partir du code source d'origine sont ok, seulement ceux à venir directement à partir de la base de données me causer des ennuis...

Une idée de ce qui se passe?

Heres une image où cet étrange personnage devrait être é

Firebird pilote JDBC connexion encodage des caractères

Le problème arrive quand il récupère à partir de la DB.

JSF 1.x ou 2.x? Qui "trouble" est-ce que tu parles? Veuillez fournir plus de détails. Quels sont les caractères que l'on voit à la place? À quelle étape exactement est-il en montrant des caractères incorrects? Directement après la récupération à partir d'DB dans du code Java? Ou seulement dans le code HTML généré en sortie?
Qu'est-ce que le jeu de caractères par défaut de la bd (ou de la coumns), qu'est-ce que la connexion characterset, est-ce des données provenant d'un BLOB SUB_TYPE TEXTE ou un (VAR)CHAR?
essayé d'ajouter plus d'informations
Vous n'êtes toujours pas clair sur exactement quand il échoue. Veuillez préciser le problème au point de vue du développeur, et non pas dans la perspective de l'utilisateur final. Pour commencer, dans le code directement après avoir récupérer les données de la DB, mettez un debug point d'arrêt ou d'un enregistreur ou d'un système..println de sorte que vous pouvez vérifier si le pilote JDBC a décodé correctement. Notez que vous devez être absolument sûr que votre IDE et l'enregistreur de données/sortie standard de la console en elle-même est aussi utiliser le bon jeu de caractères (c'est à dire que vous devez être en mesure de faire System.out.println("éãç") et de le voir de retour dans la console).
Notez que je suppose que les caractères sont correctement été stockées dans la base de données. Donc, si vous regardez dans la base de données directement à l'aide de quelques DB de l'outil d'administration, ces caractères doit être fine. Sinon, il n'a pas de sens pour le poste comme un JSF problème en premier lieu. Comme vous êtes en utilisant JSF 2.x (qui utilise par elle-même déjà par défaut UTF-8 dans toutes les couches), je pense de plus en plus que le problème est en fait en DB de l'installation ou du pilote JDBC config.

OriginalL'auteur Vitor Hugo | 2012-10-31

  1. 20

    À l'aide de encoding=ISO/UTF/WIN... paramètre de requête dans la connexion JDBC URL a résolu le problème.

    Par exemple:

    jdbc:firebirdsql:url:db?encoding=ISO8859_1
    Merci! Aussi, j'ai eu à traiter avec des & échapper comme ça [jdbc:firebirdsql:url:db?roleName=XYZ&encoding=UTF8] parce que l' ? est très pour le premier paramètre.

    OriginalL'auteur Vitor Hugo

  2. 2

    Lorsque vous ne spécifiez pas la connexion d'un ensemble de caractères dans Jaybird (soit la propriété encoding à l'aide de l'oiseau de feu jeu de caractères de nom, ou charSet avec un Java jeu de caractères du nom), puis Jaybird revient à la Firebird concept de connexion jeu de caractères NONE, ce qui signifie autant de place que le serveur ne sera pas translittérer les caractères à partir de la représentation de stockage d'un (VAR)colonne CHAR et envoie ses octets.

    Cela signifie que Jaybird reçoit une séquence d'octets dans un jeu de caractères inconnu. Jaybird devrez alors utiliser le jeu de caractères par défaut de votre installation de Java pour convertir ces octets à cordes. Donc, si la db (ou colonne) jeu de caractères ne correspond pas à votre Java jeu de caractères, elle peut produire des résultats incorrects. Pire encore: la lecture et l'écriture de cette façon, à partir de différents systèmes avec différents java par défaut des jeux de caractères peuvent produire des poubelles ou la translittération des erreurs.

    La solution: toujours spécifier un lien explicite jeu de caractères. Encore mieux, c'est de s'assurer que votre base de données a un jeu de caractères par défaut (ou que tous les (VAR)CHAR colonne a son jeu de caractères défini de façon explicite).

    La prochaine version de Jaybird (2.3) seront probablement refuser de se connecter si aucun lien explicite jeu de caractères a été spécifié pour forcer les utilisateurs à se pencher sur cette question (et si ils veulent encore l'ancien comportement, puis ils peuvent spécifier explicitement encoding=NONE).

    OriginalL'auteur Mark Rotteveel

  3. 0

    Mes 2 cents depuis que je suis ici par Google à la recherche d'une réponse..
    J'ai eu un problème avec interbase 7.5.80 utilisant les anciens jaybird pilote (v1.5).
    Tout d'encodage que j'ai utilisé sur la connexion autre que "NONE" a donné de délai d'attente d'obtenir une connexion.
    Finalement, j'ai gardé à l'aide de "NONE":

    FBWrappingDataSource dataSource = new FBWrappingDataSource();
dataSource.setDatabase("url");
dataSource.setType("TYPE4");
dataSource.setEncoding("NONE");
dataSource.setLoginTimeout(10);
java.sql.Connection c = dataSource.getConnection("sysdba", "masterkey");

    Et utilisé getBytes tout en créant une nouvelle instance de Chaîne avec un codage spécifique:

    String column = new String(rs.getBytes("column"), "Windows-1255");

    [rs est ResultSet de cours]

    Bonne chance!

    OriginalL'auteur baraka