Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
J'ai une base de données encodée en sql_ascii. Oui je sais c'est pas le mieux mais j'ai pas choisi... 
J'ai installé Ubuntu sur un poste de test et je souhaite maintenant restaurer ma base. Or, Ubuntu étant en utf8 par défaut, j'ai bien sûr un problème avec les caractères accentués. C'est pourquoi j'ai essayé de créer une base encodée en sql_ascii avec la commande :
CREATE DATABASE test --encoding=sql_ascii
Cela me crée bien la base mais quand je fais un \l+, elle est encodée en utf8, ce qui se confirme puisque à la restauration j'ai toujours le problème sur les caractères accentués.
D'après vous, pour quelle raison cette base ne se crée pas en sql_ascii ?
Je vous remercie d'avance...
Arnaud
Hors ligne
Si le code que tu mets est le bon, je vois que tu exécutes la requête « CREATE DATABASE test » et que tu ajoutes un commentaire « encoding=sql_ascii ». Hé oui, -- dans un ordre SQL est un commentaire Du coup, c'est logique qu'il ne prenne pas en compte l'encodage que tu as mal spécifié
Donc soit tu fais un :
CREATE DATABASE test ENCODING sql_asciisoit tu fais un :
createdb test --encoding sql_asciimais en tout cas pas un mix des deux
Guillaume.
Hors ligne
Bonjour,
J'ignorais que j'essayais d'exécuter du commentaire. Merci de l'info.
Mais j'ai toujours un problème en exécutant la ligne :
CREATE DATABASE test ENCODING 'sql_ascii' (sql_ascii entre guillemets sinon il me met une erreur de syntaxe)
Voici le message qui s'affiche après exécution :
ERREUR : L'encodage sql_ascii ne correspond pas à la locale fr_FR.UTF-8 du serveur
DETAIL : Le paramètre LC_CTYPE du serveur nécessite l'encodage UTF8
En fait, je ne souhaite pas changer les locales du serveur (de toute façon j'ai pas réussi à le faire lol) car il y aura d'autres applications et d'autres bases dont l'encodage sera moins exotique que sql_ascii. Ce que je souhaite juste, c'est créer cette base seulement en sql_ascii.
Est-ce possible ? Et si oui quelle est l'astuce pour y parvenir ?
Merci...
Arnaud
Hors ligne
Quelle version de PostgreSQL utilises-tu ?
Guillaume.
Hors ligne
8.3.1
Hors ligne
Étonnant. J'ai une Kubuntu moi-même, et je réussis à avoir un base en encodage SQL_ASCI avec une version 8.3.6 de PostgreSQL. Peut-être faut-il essayer de mettre à jour, mais j'ai un doute que cela corrige ce problème (mais ça corrigera au moins d'autres bugs ).
Guillaume.
Hors ligne
J'ai déjà eu le problème... et trouvé ceci dans la documentation de la 8.3 :
http://docs.postgresql.fr/8.3/multibyte.html
Il existe, cependant une importante restriction : le jeu de caractère de la base de données doit être compatible avec la variable d'environnement LC_CTYPE coté serveur. Quand LC_CTYPE est C ou POSIX, tous les jeux de caractères sont autorisés, mais pour les autres valeurs de LC_CTYPE il n'y a qu'un seul jeux de caractères qui fonctionne correctement. Puisque la variable LC_TYPE est figée par la commmande initdb, l'apparente flexibilité apportée par l'utilisation d'encodages différents dans différentes bases de données est plus théorique que réelle, sauf à choisir la locale C or POSIX (ce qui a pour conséquence de désactiver la gestion des paramètres régionaux). Il est probable que ces mécanismes soient revisités dans une prochaine version de PostgreSQL™.
Mais j'ai l'impression que ce n'est pas si simple :
Sur le cluster que j'ai créée sur mon poste de travail (Windows XP), je peux créer des bases Win1252 et UTF8.
Sur le cluster du serveur redhat, LATIN9 uniquement...
D'ailleurs, j'ai une question subsidiaire : une fois le cluster créé, comment connaître LC_CTYPE?
Hors ligne
Il faut se connecter sur le serveur PostgreSQL (peu importe la base) et rechercher la configuration de la variable lc_ctype :
postgres=# show lc_ctype;
lc_ctype
-------------
fr_FR.UTF-8
(1 ligne)Guillaume.
Hors ligne
Pour en revenir à ce que disait flo, oui, c'est pas si simple. En fait, le plupart du temps, on se moque de l'encodage. On met de l'UTF-8 sur le serveur et on configure le client_encoding à ce que l'application cliente veut. Mais dans le cas de naunau, la situation est plus embêtante. En ayant utilisé sql_ascii, PostgreSQL n'a pas cherché à savoir l'encodage des caractères envoyés. Il y a pu y avoir un client qui a enregistré des données avec l'encodage LATIN9 et d'autres avec l'encodage UTF-8 et d'autres... etc. Du coup, PostgreSQL se plaint quand on essaie de restaurer la base sur un serveur 8.3 avec un encoding autre que sql_ascii. Et donc là, on dit : « bon courage, naunau ».
Guillaume.
Hors ligne
J'avais aussi vu ce chapitre dans la doc de Postgres. N'étant pas très au fait des bases de données, j'ai espéré que malgré mes heures de recherche j'étais passé à côté de LA solution. Manifestement c'est pas le cas et c'est bien dommage pour moi. Suis un 'tit peu dans la mouise quoi...
Merci en tout cas d'avoir pris la peine de répondre. Si j'arrive à trouver une solution acceptable, je ne manquerais pas de venir la poster ici.
Arnaud
Hors ligne
Bonjour,
Je reviens à la charge pour poser ma question sous un autre angle...
Avec tous les éléments que vous avez sur les posts précédents, expliquez-moi comment je peux faire pour créer une base encodée en sql_ascii ou en latin1 ? Je rappelle que sur mon Ubuntu (version 8.04), je ne peux créer que des bases encodées en utf-8. En fait, je suis eprsuadé que si j'arrive à créer cette base sous le bon encodage, mon problème sera résolu. Mais, comme mentioné plus haut, quand je souhaite la créer en sql_ascii (par exemple), il me met un message d'erreur du type :
ERREUR : L'encodage sql_ascii ne correspond pas à la locale fr_FR.UTF-8 du serveur
DETAIL : Le paramètre LC_CTYPE du serveur nécessite l'encodage UTF8
Bref, ne parlons plus de mes caractères accentués, parlons juste des raisons qui peuvent faire que Postgres ne peut pas créer de base encodée différemment qu'en utf-8.
Et je croise les doigts...
Arnaud
Hors ligne
Vu ton problème, utiliser latin1 ne fonctionnera pas. Le meilleur moyen de tester cela est de faire un initdb en latin1, d'y créer ta base et de tenter la restauration. Vu la permissivité de sql_ascii, j'ai peur que cela ne fonctionne pas. Remarque qu'un moyen encore simple de tester ça sans faire l'initdb est d'utiliser recode pour transformer ton dump en de latin1 vers utf-8. Si ça fonctionne, tu auras un dump pour restaurer vers ton cluster UTF8. Fais ça sur une copie, recode fonctionne en inline.
Guillaume.
Hors ligne
Bonjour à tous.
Je me permets de remonter ce topic parce que je me trouve dans le même cas et je souhaiterais savoir s'il y a eu des évolutions.
J'expose un peu mieux mon souci:
Dans le passé, sur une debian, j'ai installé postgres 8.2
J'ai installé un forum fluxbb également. Mais comme celui-ci doit être encodé en iso8859-1, j'ai donc créé une base spécifique avec l'option d'encodage latin1
Hier, j'ai réinstallé mon serveur. J'ai fait un dump de ma base. J'en ai profité pour upgrader postgres et passer en version 8.3.7.
Seulement, lorsque j'essaye de créer une nouvelle base en encodage latin1 j'ai droit à la même erreur que naunau.
Mes locales sont configurées en UTF-8 (pour des raisons évidentes, j'ai pas envie d'en changer) et un show LC_CTYPE me donne fr_FR.UTF-8
J'ai bien l'impression d'être dans une impasse. Même sans la problématique de récupération de données, je crois bien que l'installation d'un forum fluxbb est incompatible avec postgres 8.3 ...
La solution serait peut être de changer LC_CTYPE pour la mettre à C ou POSIX ?... Comment faire, il faut réinitialiser la base ? Je peux le faire à partir de maintenant sans réinstaller postgres (je me fous de perdre les données pour le moment, il n'y a rien dessus).
Merci merci
Hors ligne
Salut,
Peut être que le problème est pris à l'envers. Est-ce vraiment nécessaire que l'encodage soit latin1 pour fluxbb ?
Si oui, est ce qu'un encodage client en latin1 suffit ?
Marc.
Hors ligne
Merci pour ta réponse.
C'est clair que si on suit la logique, c'est au client de s'adapter au serveur. Mais fluxbb, malgré les demandes incessantes des utilisateurs et les version qui défilent est exclusivement codé en iso8859-1 
J'ai consulté différents fils pour basculer en UTF-8 mais c'est très bancal et non recommandé...
D'ailleurs, je ne sais pas comment ce forum fluxbb ici présent fonctionne, si c'est avec une base 8.3, quel encodage ...
Dernière modification par Remigio (29/06/2009 11:36:40)
Hors ligne
Ce n'est pas ce que je veux dire :
Je veux dire que tu peux très bien avoir une base en UTF8, mais que le client lui parle en iso8859-1. C'est à cela que sert le client_encoding :
http://docs.postgresql.fr/8.3/runtime-c … lient.html
=> Tu peux essayer de créer la base en utf8, mais de spécifier que l'utilisateur qui se connecte à la base soit en latin9. Soit avec un alter user toto set client_encoding=latin9 (le plus simple, ça évite de toucher au code de l'application), soit au démarrage de la session, avec une commande SET.
Marc.
Hors ligne
Formidable Marc Cousin, ça marche parfaitement !
Et ça me parait tout à fait logique en plus 
Super merci beaucoup.
Hors ligne
Pour informations, ce forum fonctionne avec un PostgreSQL 8.3.
Guillaume.
Hors ligne
Merci gleu.
Et comment as tu procédé ? La base est encodée en UTF-8 et le client en iso8859-1 ?
Hors ligne
Comme l'a expliqué Marc. Base en UTF-8, client_encoding en ISO8859-1 pour la base (ALTER DATABASE la_base SET client_encoding TO UTF-8;).
Guillaume.
Hors ligne
Ok merci, ça marche aussi très bien chez moi.
Hors ligne
Pages : 1