Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
comment modifier le codage d'une base de données ?
ma base actuelle est codé en LATIN1 et me pose des problemes que je ne rencontre pas
avec un autre serveur qui possede la meme base mais codé en UTF8,
pouvez vous m'aider s'il vous plait .
Merci d'avance.
Hors ligne
On ne peut pas le modifier. On peut recréer une base ou un cluster dans le nouvel encodage, mais on ne peut pas modifier celui d'une base déjà créée.
Il vous faut donc exporter cette base, en créer une nouvelle, et réimporter dedans
Marc.
Hors ligne
tu peux faire une sauvegarde de ta base qui est en LATIN1 vers UTF8 comme ca :
pg_dump -Fc -f tabase.dump --encoding='UTF8' TABASE
Apres tu dois pouvoir restorer en UTF8 sans probleme.
Hors ligne
Ce n'est même pas nécessaire. Le dump indique son encodage. Si on restaure un dump latin1 dans une base utf8, postgresql fait la conversion tout seul.
Marc.
Hors ligne
Bonjour,
Je souhaitais profiter de la migration vers PostgreSQL 9.0 pour (enfin !) utiliser le module unaccent.
Or, malheureusement, pour des raisons "historiques", le codage actuel de ma base est SQL_ASCII. Les commandes unaccent ne fonctionnent donc pas dessus, ce que je peux comprendre.
J'ai donc tenté de créer une base en UTF8, mais je n'arrive pas y importer mon dump (j'obtiens une suite d'erreurs du style: ERREUR: séquence d'octets invalide pour l'encodage « UTF8 » : 0xe96e6f
CONTEXTE : COPY log_user_backup, ligne 12)
J'ai tenté à partir d'un dump "simple" (pg_dump mabase) et avec la commande suggérée ci-dessus (pg_dump -Fc -f tabase.dump --encoding='UTF8' TABASE), mais rien n'y fait; j'ai toujours la même erreur.
A priori, l'encode actuel de ma base serait ISO-8859-1 (généré essentiellmement à partir de clients Windows), mais si j'essaye de créer une base avec ce type d'encodage, createdb me génère une erreur: l'encodage ISO_8859_5 ne correspond pas à la locale fr_FR.UTF-8. Le paramètre LC_CTYPE choisi nécessite l'encodage UTF8.
Mon cas est-il désespéré ?
Par avance, merci pour votre aide
Hors ligne
Vous devez créer votre base à partir de template0, et non pas à partir de template1.
Guillaume.
Hors ligne
J'ai déjà essayé.
Exemple:
CREATE DATABASE mabase
WITH ENCODING='ISO_8859_5'
TEMPLATE=template0
Erreur: ERREUR: l'encodage ISO_8859_5 ne correspond pas à la locale fr_FR.UTF-8
DETAIL: Le paramètre LC_CTYPE choisi nécessite l'encodage UTF8.
Si j'en crois pgAdmin, pour Collation, j'ai le choix entre C, fr_FT.UTF8 et POSIX. Malheureusement,quelque soit le type choisi parmi ces 3, j'ai toujours la même erreur.
Hors ligne
Bonjour,
ISO_8859_5 est l'alphabet cyrillique. Vous êtes sûr que c'est ce que vous voulez ?
Sinon, il faut aussi préciser un ordre de collation compatible avec l'encoding ('ru_RU' vraisemblablement).
Marc.
Hors ligne
Excusez-moi, vous avez raison. Le charset était mauvais.
Mon serveur WEB utilise actuellement iso-8859-1
J'ai réussi à intégrer mon dump, après l'avoir converti "à la main" en UTF8, comme ceci:
iconv -f WINDOWS-1252 -t UTF-8 -o megalis5.sql ../postgresql/megalis_last.sql
Mais, bien évidemment, l'affichage des caractères accentués devient incohérent.
Mon souhait serait donc de créer une base en définissant explicitement ce charset.
Hors ligne
Je me réponds à moi-même ;-)
Je pense avoir réussi, en exécutant la commande suivante:
CREATE DATABASE MaBase
WITH OWNER = postgres
ENCODING = 'ISO_8859_1'
TABLESPACE = pg_default
TEMPLATE template0
LC_COLLATE = 'POSIX'
LC_CTYPE = 'POSIX'
CONNECTION LIMIT = -1;
En espérant que cette information puisse être utile à d'autres.
Et merci pour votre aide, toujours aussi précieuse et avisée
Dernière modification par jhashe (28/09/2010 10:20:08)
Hors ligne
Ce n'est pas tout à fait bon:
CREATE DATABASE MaBase
WITH OWNER = postgres
ENCODING = 'ISO_8859_1'
TABLESPACE = pg_default
TEMPLATE template0
LC_COLLATE = 'fr_FR'
LC_CTYPE = 'fr_FR'
CONNECTION LIMIT = -1;
C'est important. Surtout si vous tenez à ce que les données soient triées par ordre alphabétique français.
Par ailleurs, le iconv est totalement inutile.
Si la base initiale est SQL_ASCII, mais que vous êtres sûr qu'elle est encodée en LATIN1 (iso-8859-1), LATIN9 (iso8859-15), ou WIN1252 (WINDOWS-1252), il suffit de positionner client_encoding correctement dans la session avant de lancer l'import.
Ensuite, méfiez vous, vous êtes en train de confondre plusieurs encodages différents : LATIN1 et WIN1252 ne sont pas strictement identiques.
Marc.
Hors ligne
Merci pour votre réponse.
Il est vrai qu'en ce qui concerne l'encodage des caractères, je suis un peu perplexe.
Certaines données sont alimentées à partir de clients lourds sous Windows (ce qui me ferait pencher pour du WINDOWS-1252), alors que d'autres sont alimentées par divers sites WEB (iso-8859-1). Mais cela n'avait jamais posé de problème jusque là.
Par contre, j'ai un soucis avec la commande SQL que vous suggérez. Lorsque je la tape, j'obtiens le message d'erreur suivant:
nom de locale 'fr_FR' invalide.
Or, vous avez raison, l'impact sur l'ordre des tris est pourtant particulièrement important.
Mais, mon problème principal provient de la contribution unaccent. Rien ne semble préciser dans la documentation qu'elle ne fonctionne qu'en UTF-8. Or cela semble malheureusement pourtant être le cas. Dans une situation comme la nôtre, où la base est en place depuis des années, est alimentée par de nombreux programmes (des clients lourds, des intranets, des sites web,...), changer le type d'encodage est quasi-impossible (il faudrait modifier tous les process "en même temps", et je ne suis même pas sûr que nous possédions les sources pour chacun d'entre eux).
Ma plus grosse attente concernant la version 9.0 de PostgreSQL concernait pourtant bien ce point fondamental (voir les nombreux messages que j'avais envoyés sur ce même forum). Nous avons en effet commencé à développer des interfaces exploitant T-Search, mais les usages en France font que les internautes "zappent" fréquemment les accents. D'ailleurs, qui accentue correctement les majuscules ? Sans unaccent, le résultat est insatisfaisant (par exemple, je recherche hôtel, mais je ne retrouve pas un article dont le titre est HOTEL DE LA MER, compréhensible d'un point de vue SGBD, mais aberrant d'un point de vue utilisateur)
On peut certes "bidouiller" en stockant une copie (ou mieux, directement le vecteur) du champ sans les accents, mais cela pose d'autres problèmes, notamment le ts_headline utilisé pour afficher des extraits de résultats. En effet, un extrait privé de ces accents est inacceptable pour nos utilisateurs.
J'essaye de me battre avec des convert_to, encode et autres manipulations, mais sans succès.
Bref, mes premières tentatives génèrent quelques frustrations (et c'est peu dire...)
Hors ligne
Nom de locale fr_FR invalide ?
Quel est le système d'exploitation ?
Si c'est linux, que répond locale -a ?
Pour ce qui est de la suite, vous avez intérêt à avoir votre base en UTF8, et positionner le client_encoding correctement sur tous les clients. Ainsi, PostgreSQL s'occupera de la conversion, et enverra les données dans le bon encodage aux clients, tout en ayant la possibilité de tout stocker.
Marc.
Hors ligne
Je suis sous Debian Lenny (avec un petit bout de sid pour Postgresql-9.0)
locale -a répond:
C
fr_FR.utf8
POSIX
J'ai tenté un:
create database megalis6 with owner=postgres encoding='LATIN1' tablespace=pg_default TEMPLATE template0 LC_COLLATE='fr_FR.utf8' LC_CTYPE='fr_FR.utf8';
mais j'obtiens une nouvelle erreur:
l'encodage LATIN1 ne correspond pas à la locale fr_FR.utf8
Le paramètre LC_CTYPE choisi nécessite l'encodage UTF8.
Mais votre dernier message suggère une piste plus intéressante, à savoir le "client encoding"
Les clients lourds utilisent ODBC pour accéder à PostgreSQL. Ce paramètre se configure-t-il dans la zone "Connect Settings" du driver ODBC ? (je ne vois pas d'autre endroit possible). Que faut-il y renseigner ?
De même, nos outils WEB sont développés en PHP, et utilisent la couche d'abstraction ADODB.
Savez-vous ou positionner ce paramètre ?
A titre d'exemple, voici un extrait de la connexion actuelle:
$MM_mabase_HOSTNAME = "192.168.10.199";
$MM_mabase_DATABASE = "postgres7:mabase";
$MM_mabase_DBTYPE = preg_replace("/:.*$/", "", $MM_mabase_DATABASE);
$MM_mabase_DATABASE = preg_replace("/^.*?:/", "", $MM_mabase_DATABASE);
$MM_mabase_USERNAME = "postgres";
$MM_mabase_PASSWORD = "MonMotPasse";
$MM_mabase_LOCALE = "Fr";
$MM_mabase_MSGLOCALE = "Fr";
$MM_mabase_CTYPE = "P";
$KT_locale = $MM_mabase_MSGLOCALE;
$KT_dlocale = $MM_mabase_LOCALE;
$KT_serverFormat = "%Y-%m-%d %H:%M:%S";
$QUB_Caching = "false";
Hors ligne
Bonjour,
Le problème, c'est que vous n'avez pas la locale correspondant à fr_FR et LATIN1 (son nom c'est fr_FR)
essayez dpkg-reconfigure -plow locales
Il devrait vous redemaner la liste de locales à générer. Vous pourrez ensuite les utiliser.
Pour ce qui est du paramétrage ODBC aucune idée de comment on y règle l'encodage. Je pense qu'il met la bonne valeur tout seul. Vu que jusque là vous étiez paramétré en 'ASCII' au niveau de la base, il n'y avait aucun transcodage entre le client et le serveur.
Marc.
Hors ligne
Bonjour,
Le paramètre "client encoding" fonctionne effectivement très bien :-)
Sous Windows, pour le fixer, quand on crée la connexion ODBC, il faut cliquer sur le bouton Datasource, puis sur la page 2, dans la zone Connect Setting, il suffit de rajouter SET CLIENT_ENCODING TO 'WIN1252';
En PHP, avec ADODB, après l'établissement de la connexion, il faut ajouter la ligne suivante:
$maSource->SetCharSet("WIN1252");
Bref, l'horizon s'éclaircit.
Merci pour votre aide !
Hors ligne
Bonjour,
apres quelques jour d'absence...
en fait le serveur ne voulait pas d'UTF8 du tout.
donc solution radicale :
reinstallation de postgres;
puis importation des données dans une base en utf8
merci pour votre collaboration à tous!
Hors ligne
Pages : 1
