problèmes d'accents/encodage avec la base de données

  • user warning: Table './drupal_www_ori_oai_org/cache_filter' is marked as crashed and last (automatic?) repair failed query: SELECT data, created, headers, expire, serialized FROM cache_filter WHERE cid = '4:f74b61262129c1c3b249e60212cbbe94' in /home/ori-oai/drupal/drupal-6.34/includes/cache.inc on line 27.
  • user warning: Table './drupal_www_ori_oai_org/cache_filter' is marked as crashed and last (automatic?) repair failed query: UPDATE cache_filter SET data = '<div class=\"emailFilter\">Vincent,</p>\n<p>Pour l\'ajout de champs ds le formulaire auteur :<br />\nj\'obtiens un affichage incomplet : manque les libellés de la partie de<br />\ngauche (cf capture écrans en attaché),<br />\naprès avoir</p>\n<p>- modifié \"xforms\\lom-author-light-uvhc\\content-xforms\" (cf ligne<br />\n319-456 ; fichier joint)<br />\npour ajouter 1 bloc avec des champs (<fieldset class=\"collapsible<br />\ncollapsed\">) avant le bloc \"Autres auteur(s) et\n</div>\n', created = 1507747081, expire = 1507833481, headers = '', serialized = 0 WHERE cid = '4:f74b61262129c1c3b249e60212cbbe94' in /home/ori-oai/drupal/drupal-6.34/includes/cache.inc on line 112.
  • user warning: Table './drupal_www_ori_oai_org/cache_filter' is marked as crashed and last (automatic?) repair failed query: SELECT data, created, headers, expire, serialized FROM cache_filter WHERE cid = '4:f74b61262129c1c3b249e60212cbbe94' in /home/ori-oai/drupal/drupal-6.34/includes/cache.inc on line 27.
  • user warning: Table './drupal_www_ori_oai_org/cache_filter' is marked as crashed and last (automatic?) repair failed query: UPDATE cache_filter SET data = '<div class=\"emailFilter\">Vincent,</p>\n<p>Pour l\'ajout de champs ds le formulaire auteur :<br />\nj\'obtiens un affichage incomplet : manque les libellés de la partie de<br />\ngauche (cf capture écrans en attaché),<br />\naprès avoir</p>\n<p>- modifié \"xforms\\lom-author-light-uvhc\\content-xforms\" (cf ligne<br />\n319-456 ; fichier joint)<br />\npour ajouter 1 bloc avec des champs (<fieldset class=\"collapsible<br />\ncollapsed\">) avant le bloc \"Autres auteur(s) et\n</div>\n', created = 1507747081, expire = 1507833481, headers = '', serialized = 0 WHERE cid = '4:f74b61262129c1c3b249e60212cbbe94' in /home/ori-oai/drupal/drupal-6.34/includes/cache.inc on line 112.
  • user warning: Table './drupal_www_ori_oai_org/cache_filter' is marked as crashed and last (automatic?) repair failed query: SELECT data, created, headers, expire, serialized FROM cache_filter WHERE cid = '4:d9b15731c50b9c923b4274380ca3678f' in /home/ori-oai/drupal/drupal-6.34/includes/cache.inc on line 27.
  • user warning: Table './drupal_www_ori_oai_org/cache_filter' is marked as crashed and last (automatic?) repair failed query: UPDATE cache_filter SET data = '<div class=\"emailFilter\">Bonjour,<br />\nJ\'ai installé les dernières versions des modules d\'ori-oai (via svn)<br />\nles instances de tomcat ont étét déployées via le quick-install (les<br />\nvariables CATALINA_OPTS sont bien postionnées).Les bases de données en<br />\ninnodb sont en utf8_general_ci comme indiqués dans la doc.<br />\nOr je constate que lors de l\'insertion de fiches avec des accents, les<br />\ndonnées (fiche xml) du champs xmlContent dans la table<br />\nORI_WORKLFOW_INSTANCE sont tronquées au premier accent rencontré (sans<br />\nerreur lors de l\'insertion mais évidemment cela déclenche une exception<br />\nsi l\'on essaie de rééditer la fiche - xml non valide-). Bizarrement, le<br />\nchamps title est correctement rempli même en cas de présence de<br />\ncaractère accentués.<br />\nEn modifiant le codage du champ d\'utf8 vers latin1, les données sont<br />\nsaisies correctement.<br />\nEst-ce un problème connu ou une erreur de ma part dans l\'installation ?<br />\nj\'ai par ailleurs exactement le mêm problème (avec la même solution de<br />\nchangement d\'encodage) pour le module harvester et le champs setName de<br />\nla table OAI_SET_INFOS. Ce sont dans les deux cas des champs de type<br />\ntext ...<br />\nMerci d\'avance de vos éclaircissements ...</p>\n<p>--<br />\nKaren Raynal<br />\nSCd Université Bordeaux 1</p>\n<p>--<br />\nCe message a été vérifié par MailScanner<br />\npour des virus ou des polluriels et rien de<br />\nsuspect n\'a été trouvé.</p>\n</div>\n', created = 1507747082, expire = 1507833482, headers = '', serialized = 0 WHERE cid = '4:d9b15731c50b9c923b4274380ca3678f' in /home/ori-oai/drupal/drupal-6.34/includes/cache.inc on line 112.
  • user warning: Table './drupal_www_ori_oai_org/cache_filter' is marked as crashed and last (automatic?) repair failed query: SELECT data, created, headers, expire, serialized FROM cache_filter WHERE cid = '4:f5796d15c1ffa33356c9dd08155d175a' in /home/ori-oai/drupal/drupal-6.34/includes/cache.inc on line 27.
  • user warning: Table './drupal_www_ori_oai_org/cache_filter' is marked as crashed and last (automatic?) repair failed query: UPDATE cache_filter SET data = '<div class=\"emailFilter\">Bonjour,</p>\n<p>Je confirme.<br />\nMême problème, même solution.</p>\n<p>Cordialement.</p>\n<p>Karen Raynal a écrit :<br />\n<div class=\"emailFilter_Toggle\">\n<blockquote class=\"emailFilter_Author_0\"><p>> Bonjour,<br />\n> J\'ai installé les dernières versions des modules d\'ori-oai (via svn)<br />\n> les instances de tomcat ont étét déployées via le quick-install (les<br />\n> variables CATALINA_OPTS sont bien postionnées).Les bases de données en<br />\n> innodb sont en utf8_general_ci comme indiqués dans la doc.<br />\n> Or je constate que lors de l\'insertion de fiches avec des accents, les<br />\n> données (fiche xml) du champs xmlContent dans la table<br />\n> ORI_WORKLFOW_INSTANCE sont tronquées au premier accent rencontré (sans<br />\n> erreur lors de l\'insertion mais évidemment cela déclenche une<br />\n> exception si l\'on essaie de rééditer la fiche - xml non valide-).<br />\n> Bizarrement, le champs title est correctement rempli même en cas de<br />\n> présence de caractère accentués.<br />\n> En modifiant le codage du champ d\'utf8 vers latin1, les données sont<br />\n> saisies correctement.<br />\n> Est-ce un problème connu ou une erreur de ma part dans l\'installation ?<br />\n> j\'ai par ailleurs exactement le mêm problème (avec la même solution de<br />\n> changement d\'encodage) pour le module harvester et le champs setName<br />\n> de la table OAI_SET_INFOS. Ce sont dans les deux cas des champs de<br />\n> type text ...<br />\n> Merci d\'avance de vos éclaircissements ...<br />\n><br />\n> --<br />\n> Karen Raynal<br />\n> SCd Université Bordeaux 1<br />\n><br />\n></div>\n</blockquote>\n<p>--<br />\nAlexandre Boisseau</p>\n<p>--<br />\nCe message a été vérifié par MailScanner<br />\npour des virus ou des polluriels et rien de<br />\nsuspect n\'a été trouvé.</p>\n</div>\n', created = 1507747083, expire = 1507833483, headers = '', serialized = 0 WHERE cid = '4:f5796d15c1ffa33356c9dd08155d175a' in /home/ori-oai/drupal/drupal-6.34/includes/cache.inc on line 112.
  • user warning: Table './drupal_www_ori_oai_org/cache_filter' is marked as crashed and last (automatic?) repair failed query: SELECT data, created, headers, expire, serialized FROM cache_filter WHERE cid = '4:3475bf5c71284983aaa10e345088d761' in /home/ori-oai/drupal/drupal-6.34/includes/cache.inc on line 27.
  • user warning: Table './drupal_www_ori_oai_org/cache_filter' is marked as crashed and last (automatic?) repair failed query: UPDATE cache_filter SET data = '<div class=\"emailFilter\">Bonjour,</p>\n<p>Les problème de l\'encodage sont retors... il faut le même à chaque bout<br />\ndu tuyau de la sérialisation / déserialisation, et ce tout au long de la<br />\ncirculation de la donnée, sans quoi on peut s\'attendre à n\'importe quoi.<br />\nLe fait de remettre votre base en iso est un pis-aller, vous risquez de<br />\nvous trimballer un fil à la patte.<br />\nJe dirais a priori que si vous avez une troncation dans une base Mysql<br />\nutf8, et que tout se passe bien quand c\'est en iso-8859-1, c\'est que<br />\nvous (enfin l\'application) ne lui envoyez pas ce qu\'elle attend... Elle<br />\nsemble buter sur le premier caractère non ASCII qui n\'a pas le bon<br />\nencodage...<br />\nIl faut bien vérifier que la JVM qui fait tourner l\'appli a une option<br />\n-Dfile.encoding=UTF-8.</p>\n<p>François</p>\n<p>Alexandre Boisseau a écrit :<br />\n<div class=\"emailFilter_Toggle\">\n<blockquote class=\"emailFilter_Author_0\"><p>> Bonjour,<br />\n><br />\n> Je confirme.<br />\n> Même problème, même solution.<br />\n><br />\n> Cordialement.<br />\n><br />\n> Karen Raynal a écrit :</p></blockquote>\n<blockquote class=\"emailFilter_Author_1\"><p>>> Bonjour,<br />\n>> J\'ai installé les dernières versions des modules d\'ori-oai (via svn)<br />\n>> les instances de tomcat ont étét déployées via le quick-install (les<br />\n>> variables CATALINA_OPTS sont bien postionnées).Les bases de données<br />\n>> en innodb sont en utf8_general_ci comme indiqués dans la doc.<br />\n>> Or je constate que lors de l\'insertion de fiches avec des accents,<br />\n>> les données (fiche xml) du champs xmlContent dans la table<br />\n>> ORI_WORKLFOW_INSTANCE sont tronquées au premier accent rencontré<br />\n>> (sans erreur lors de l\'insertion mais évidemment cela déclenche une<br />\n>> exception si l\'on essaie de rééditer la fiche - xml non valide-).<br />\n>> Bizarrement, le champs title est correctement rempli même en cas de<br />\n>> présence de caractère accentués.<br />\n>> En modifiant le codage du champ d\'utf8 vers latin1, les données sont<br />\n>> saisies correctement.<br />\n>> Est-ce un problème connu ou une erreur de ma part dans l\'installation ?<br />\n>> j\'ai par ailleurs exactement le mêm problème (avec la même solution<br />\n>> de changement d\'encodage) pour le module harvester et le champs<br />\n>> setName de la table OAI_SET_INFOS. Ce sont dans les deux cas des<br />\n>> champs de type text ...<br />\n>> Merci d\'avance de vos éclaircissements ...<br />\n>><br />\n>> --<br />\n>> Karen Raynal<br />\n>> SCd Université Bordeaux 1<br />\n>><br />\n>></p></blockquote>\n<blockquote class=\"emailFilter_Author_0\"><p>></div>\n</blockquote>\n<p>--<br />\nCe message a été vérifié par MailScanner<br />\npour des virus ou des polluriels et rien de<br />\nsuspect n\'a été trouvé.</p>\n</div>\n', created = 1507747083, expire = 1507833483, headers = '', serialized = 0 WHERE cid = '4:3475bf5c71284983aaa10e345088d761' in /home/ori-oai/drupal/drupal-6.34/includes/cache.inc on line 112.
  • user warning: Table './drupal_www_ori_oai_org/cache_filter' is marked as crashed and last (automatic?) repair failed query: SELECT data, created, headers, expire, serialized FROM cache_filter WHERE cid = '4:64486a8f7b022978abceba328d88b6d2' in /home/ori-oai/drupal/drupal-6.34/includes/cache.inc on line 27.
  • user warning: Table './drupal_www_ori_oai_org/cache_filter' is marked as crashed and last (automatic?) repair failed query: UPDATE cache_filter SET data = '<div class=\"emailFilter\">Bonjour,</p>\n<p>Merci de la réponse mais ... je suis à peu près certaine d\'être en UTF8<br />\nd\'un bout à l\'autre de la chaîne ...<br />\nCe qui me surprend, c\'est que l\'insertion de caractères accentués ne<br />\npose problème que dans les champs de type text (les même caractères dans<br />\nle champ title sont correctement insérés ..).<br />\nPar ailleurs, si j\'insère le même enregistrement dans la base de données<br />\ndirectement (sans passer par le workflow ....), il n\'y a aucun problème ...</p>\n<p>Par contre, si je rajoute au fichier de configuration (dans dao.xml par<br />\nexemple) les options useUnicode=true&amp;characterEncoding=UTF-8, tout<br />\nfonctionne normalement !</p>\n<p>Si ça peut servir à quelqu\'un ...</p>\n<p>Karen.</p>\n<div class=\"emailFilter_Toggle\">\n<blockquote class=\"emailFilter_Author_0\"><p>> Bonjour,<br />\n><br />\n> Les problème de l\'encodage sont retors... il faut le même à chaque bout<br />\n> du tuyau de la sérialisation / déserialisation, et ce tout au long de la<br />\n> circulation de la donnée, sans quoi on peut s\'attendre à n\'importe quoi.<br />\n> Le fait de remettre votre base en iso est un pis-aller, vous risquez de<br />\n> vous trimballer un fil à la patte.<br />\n> Je dirais a priori que si vous avez une troncation dans une base Mysql<br />\n> utf8, et que tout se passe bien quand c\'est en iso-8859-1, c\'est que<br />\n> vous (enfin l\'application) ne lui envoyez pas ce qu\'elle attend... Elle<br />\n> semble buter sur le premier caractère non ASCII qui n\'a pas le bon<br />\n> encodage...<br />\n> Il faut bien vérifier que la JVM qui fait tourner l\'appli a une option<br />\n> -Dfile.encoding=UTF-8.<br />\n><br />\n> François<br />\n><br />\n> Alexandre Boisseau a écrit :</p></blockquote>\n<blockquote class=\"emailFilter_Author_1\"><p>>> Bonjour,<br />\n>><br />\n>> Je confirme.<br />\n>> Même problème, même solution.<br />\n>><br />\n>> Cordialement.<br />\n>><br />\n>> Karen Raynal a écrit :</p></blockquote>\n<blockquote class=\"emailFilter_Author_2\"><p>>>> Bonjour,<br />\n>>> J\'ai installé les dernières versions des modules d\'ori-oai (via svn)<br />\n>>> les instances de tomcat ont étét déployées via le quick-install (les<br />\n>>> variables CATALINA_OPTS sont bien postionnées).Les bases de données<br />\n>>> en innodb sont en utf8_general_ci comme indiqués dans la doc.<br />\n>>> Or je constate que lors de l\'insertion de fiches avec des accents,<br />\n>>> les données (fiche xml) du champs xmlContent dans la table<br />\n>>> ORI_WORKLFOW_INSTANCE sont tronquées au premier accent rencontré<br />\n>>> (sans erreur lors de l\'insertion mais évidemment cela déclenche une<br />\n>>> exception si l\'on essaie de rééditer la fiche - xml non valide-).<br />\n>>> Bizarrement, le champs title est correctement rempli même en cas de<br />\n>>> présence de caractère accentués.<br />\n>>> En modifiant le codage du champ d\'utf8 vers latin1, les données sont<br />\n>>> saisies correctement.<br />\n>>> Est-ce un problème connu ou une erreur de ma part dans l\'installation ?<br />\n>>> j\'ai par ailleurs exactement le mêm problème (avec la même solution<br />\n>>> de changement d\'encodage) pour le module harvester et le champs<br />\n>>> setName de la table OAI_SET_INFOS. Ce sont dans les deux cas des<br />\n>>> champs de type text ...<br />\n>>> Merci d\'avance de vos éclaircissements ...<br />\n>>><br />\n>>> --<br />\n>>> Karen Raynal<br />\n>>> SCd Université Bordeaux 1<br />\n>>><br />\n>>></p></blockquote>\n<blockquote class=\"emailFilter_Author_1\"><p>>></p></blockquote>\n<blockquote class=\"emailFilter_Author_0\"><p>> </div>\n</blockquote>\n<p>--<br />\nCe message a été vérifié par MailScanner<br />\npour des virus ou des polluriels et rien de<br />\nsuspect n\'a été trouvé.</p>\n</div>\n', created = 1507747083, expire = 1507833483, headers = '', serialized = 0 WHERE cid = '4:64486a8f7b022978abceba328d88b6d2' in /home/ori-oai/drupal/drupal-6.34/includes/cache.inc on line 112.
4 messages / 0 nouveaux
Sujet clos
Dernière contribution
15 octobre 2008 - 2:24pm
#1
karenraynal
problèmes d'accents/encodage avec la base de données
Bonjour,
J'ai installé les dernières versions des modules d'ori-oai (via svn)
les instances de tomcat ont étét déployées via le quick-install (les
variables CATALINA_OPTS sont bien postionnées).Les bases de données en
innodb sont en utf8_general_ci comme indiqués dans la doc.
Or je constate que lors de l'insertion de fiches avec des accents, les
données (fiche xml) du champs xmlContent dans la table
ORI_WORKLFOW_INSTANCE sont tronquées au premier accent rencontré (sans
erreur lors de l'insertion mais évidemment cela déclenche une exception
si l'on essaie de rééditer la fiche - xml non valide-). Bizarrement, le
champs title est correctement rempli même en cas de présence de
caractère accentués.
En modifiant le codage du champ d'utf8 vers latin1, les données sont
saisies correctement.
Est-ce un problème connu ou une erreur de ma part dans l'installation ?
j'ai par ailleurs exactement le mêm problème (avec la même solution de
changement d'encodage) pour le module harvester et le champs setName de
la table OAI_SET_INFOS. Ce sont dans les deux cas des champs de type
text ...
Merci d'avance de vos éclaircissements ...

--
Karen Raynal
SCd Université Bordeaux 1

--
Ce message a été vérifié par MailScanner
pour des virus ou des polluriels et rien de
suspect n'a été trouvé.

Haut
Étiquettes:
16 octobre 2008 - 11:55am
#2
alexandreboisseau (non vérifié)
Bonjour,

Je confirme.
Même problème, même solution.

Cordialement.

Karen Raynal a écrit :

> Bonjour,
> J'ai installé les dernières versions des modules d'ori-oai (via svn)
> les instances de tomcat ont étét déployées via le quick-install (les
> variables CATALINA_OPTS sont bien postionnées).Les bases de données en
> innodb sont en utf8_general_ci comme indiqués dans la doc.
> Or je constate que lors de l'insertion de fiches avec des accents, les
> données (fiche xml) du champs xmlContent dans la table
> ORI_WORKLFOW_INSTANCE sont tronquées au premier accent rencontré (sans
> erreur lors de l'insertion mais évidemment cela déclenche une
> exception si l'on essaie de rééditer la fiche - xml non valide-).
> Bizarrement, le champs title est correctement rempli même en cas de
> présence de caractère accentués.
> En modifiant le codage du champ d'utf8 vers latin1, les données sont
> saisies correctement.
> Est-ce un problème connu ou une erreur de ma part dans l'installation ?
> j'ai par ailleurs exactement le mêm problème (avec la même solution de
> changement d'encodage) pour le module harvester et le champs setName
> de la table OAI_SET_INFOS. Ce sont dans les deux cas des champs de
> type text ...
> Merci d'avance de vos éclaircissements ...
>
> --
> Karen Raynal
> SCd Université Bordeaux 1
>
>

--
Alexandre Boisseau

--
Ce message a été vérifié par MailScanner
pour des virus ou des polluriels et rien de
suspect n'a été trouvé.

Haut
16 octobre 2008 - 12:19pm
(Répondre à #2) #3
francoisjannin
Bonjour,

Les problème de l'encodage sont retors... il faut le même à chaque bout
du tuyau de la sérialisation / déserialisation, et ce tout au long de la
circulation de la donnée, sans quoi on peut s'attendre à n'importe quoi.
Le fait de remettre votre base en iso est un pis-aller, vous risquez de
vous trimballer un fil à la patte.
Je dirais a priori que si vous avez une troncation dans une base Mysql
utf8, et que tout se passe bien quand c'est en iso-8859-1, c'est que
vous (enfin l'application) ne lui envoyez pas ce qu'elle attend... Elle
semble buter sur le premier caractère non ASCII qui n'a pas le bon
encodage...
Il faut bien vérifier que la JVM qui fait tourner l'appli a une option
-Dfile.encoding=UTF-8.

François

Alexandre Boisseau a écrit :

> Bonjour,
>
> Je confirme.
> Même problème, même solution.
>
> Cordialement.
>
> Karen Raynal a écrit :

>> Bonjour,
>> J'ai installé les dernières versions des modules d'ori-oai (via svn)
>> les instances de tomcat ont étét déployées via le quick-install (les
>> variables CATALINA_OPTS sont bien postionnées).Les bases de données
>> en innodb sont en utf8_general_ci comme indiqués dans la doc.
>> Or je constate que lors de l'insertion de fiches avec des accents,
>> les données (fiche xml) du champs xmlContent dans la table
>> ORI_WORKLFOW_INSTANCE sont tronquées au premier accent rencontré
>> (sans erreur lors de l'insertion mais évidemment cela déclenche une
>> exception si l'on essaie de rééditer la fiche - xml non valide-).
>> Bizarrement, le champs title est correctement rempli même en cas de
>> présence de caractère accentués.
>> En modifiant le codage du champ d'utf8 vers latin1, les données sont
>> saisies correctement.
>> Est-ce un problème connu ou une erreur de ma part dans l'installation ?
>> j'ai par ailleurs exactement le mêm problème (avec la même solution
>> de changement d'encodage) pour le module harvester et le champs
>> setName de la table OAI_SET_INFOS. Ce sont dans les deux cas des
>> champs de type text ...
>> Merci d'avance de vos éclaircissements ...
>>
>> --
>> Karen Raynal
>> SCd Université Bordeaux 1
>>
>>

>

--
Ce message a été vérifié par MailScanner
pour des virus ou des polluriels et rien de
suspect n'a été trouvé.

Haut
16 octobre 2008 - 4:00pm
(Répondre à #3) #4
karenraynal
Bonjour,

Merci de la réponse mais ... je suis à peu près certaine d'être en UTF8
d'un bout à l'autre de la chaîne ...
Ce qui me surprend, c'est que l'insertion de caractères accentués ne
pose problème que dans les champs de type text (les même caractères dans
le champ title sont correctement insérés ..).
Par ailleurs, si j'insère le même enregistrement dans la base de données
directement (sans passer par le workflow ....), il n'y a aucun problème ...

Par contre, si je rajoute au fichier de configuration (dans dao.xml par
exemple) les options useUnicode=true&characterEncoding=UTF-8, tout
fonctionne normalement !

Si ça peut servir à quelqu'un ...

Karen.

> Bonjour,
>
> Les problème de l'encodage sont retors... il faut le même à chaque bout
> du tuyau de la sérialisation / déserialisation, et ce tout au long de la
> circulation de la donnée, sans quoi on peut s'attendre à n'importe quoi.
> Le fait de remettre votre base en iso est un pis-aller, vous risquez de
> vous trimballer un fil à la patte.
> Je dirais a priori que si vous avez une troncation dans une base Mysql
> utf8, et que tout se passe bien quand c'est en iso-8859-1, c'est que
> vous (enfin l'application) ne lui envoyez pas ce qu'elle attend... Elle
> semble buter sur le premier caractère non ASCII qui n'a pas le bon
> encodage...
> Il faut bien vérifier que la JVM qui fait tourner l'appli a une option
> -Dfile.encoding=UTF-8.
>
> François
>
> Alexandre Boisseau a écrit :

>> Bonjour,
>>
>> Je confirme.
>> Même problème, même solution.
>>
>> Cordialement.
>>
>> Karen Raynal a écrit :

>>> Bonjour,
>>> J'ai installé les dernières versions des modules d'ori-oai (via svn)
>>> les instances de tomcat ont étét déployées via le quick-install (les
>>> variables CATALINA_OPTS sont bien postionnées).Les bases de données
>>> en innodb sont en utf8_general_ci comme indiqués dans la doc.
>>> Or je constate que lors de l'insertion de fiches avec des accents,
>>> les données (fiche xml) du champs xmlContent dans la table
>>> ORI_WORKLFOW_INSTANCE sont tronquées au premier accent rencontré
>>> (sans erreur lors de l'insertion mais évidemment cela déclenche une
>>> exception si l'on essaie de rééditer la fiche - xml non valide-).
>>> Bizarrement, le champs title est correctement rempli même en cas de
>>> présence de caractère accentués.
>>> En modifiant le codage du champ d'utf8 vers latin1, les données sont
>>> saisies correctement.
>>> Est-ce un problème connu ou une erreur de ma part dans l'installation ?
>>> j'ai par ailleurs exactement le mêm problème (avec la même solution
>>> de changement d'encodage) pour le module harvester et le champs
>>> setName de la table OAI_SET_INFOS. Ce sont dans les deux cas des
>>> champs de type text ...
>>> Merci d'avance de vos éclaircissements ...
>>>
>>> --
>>> Karen Raynal
>>> SCd Université Bordeaux 1
>>>
>>>

>>

>

--
Ce message a été vérifié par MailScanner
pour des virus ou des polluriels et rien de
suspect n'a été trouvé.

Haut

Options d'affichage des commentaires

Sélectionnez la méthode d'affichage des commentaires que vous préférez, puis cliquez sur « Enregistrer les paramètres » pour activer vos changements.
Sujet clos
‹ Sujet précédent : Module search: navigation Sujet suivant : Editeur : Ajout champs formulaire auteur 2 ›