workflow : fiche xml non complète

  • 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:846eaf80b8035ead5c5dbd954e519817' 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 a tous</p>\n<p>J ai fait une presentation d ORI a une autre Ecole militaire et a mon<br />\norganisme<br />\nde tutelle.</p>\n<p>Je n ai pas su repondre a la question suivante ?</p>\n<p>Comment est calculer le Coefficient de pertinence qui est affiché par<br />\nORI-Search ?</p>\n<p>Est ce parametrable ?</p>\n<p>Merci d avance<br />\nCordialement.<br />\nPatrick</p>\n<p>--<br />\nPatrick Jaouen<br />\nEcoles de St-Cyr Coetquidan<br />\nBureau Informatique</p>\n<p>--<br />\nCe message a\n</div>\n', created = 1507745735, expire = 1507832135, headers = '', serialized = 0 WHERE cid = '4:846eaf80b8035ead5c5dbd954e519817' 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:846eaf80b8035ead5c5dbd954e519817' 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 a tous</p>\n<p>J ai fait une presentation d ORI a une autre Ecole militaire et a mon<br />\norganisme<br />\nde tutelle.</p>\n<p>Je n ai pas su repondre a la question suivante ?</p>\n<p>Comment est calculer le Coefficient de pertinence qui est affiché par<br />\nORI-Search ?</p>\n<p>Est ce parametrable ?</p>\n<p>Merci d avance<br />\nCordialement.<br />\nPatrick</p>\n<p>--<br />\nPatrick Jaouen<br />\nEcoles de St-Cyr Coetquidan<br />\nBureau Informatique</p>\n<p>--<br />\nCe message a\n</div>\n', created = 1507745735, expire = 1507832135, headers = '', serialized = 0 WHERE cid = '4:846eaf80b8035ead5c5dbd954e519817' 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:32eea336c22845a8d9ebcbb9a9e70184' 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>Lorsque j\'enregistre un nouveau formulaire dans le module workflow, la<br />\nfiche stockée dans la table ORI_WORKLFOW_INSTANCE au niveau du champs<br />\nxmlContent n\'est pas complète : apparemment elle s\'arrête lorsqu\'elle<br />\nrencontre un caractère accentué : par exemple au niveau d\'une vcards, la<br />\nfiche fini par ORG: Universit lorsque je mets Université dans la vcards<br />\nau niveau du fichier ldapVocabulary.xml du module de vocabulaire. Si<br />\nj\'enlève l\'accent, la fiche est enregistrée dans le workflow s\'arrête<br />\nplus loin, à un autre accent.</p>\n<p>Comment faire pour résoudre ce problème ?</p>\n<p>Lucie</p>\n<p>--<br />\n----------------------------------<br />\nLucie Dengreville<br />\nCentre de Ressources Informatiques<br />\nUniversité Rennes 2 Haute Bretagne<br />\n02.99.14.13.66<br />\n-----------------------------------</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 = 1507745740, expire = 1507832140, headers = '', serialized = 0 WHERE cid = '4:32eea336c22845a8d9ebcbb9a9e70184' 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:504b17034fccba634781f8db14c8e8f0' 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 Lucie,<br />\nTu utilise MySQL (InnoDB) avec une base de données sous quel encodage ?<br />\nL\'encodage par défaut sous MySQL est le latin suédois, as-tu opté pour<br />\nl\'UTF-8 ?<br />\nPeut-être également qu\'il y a un problème d\'encodage à un autre niveau ?<br />\nLe charset par défaut du tomcat du module de vocabulaires ? Le fichier<br />\nde vocabulaires des VCards ?<br />\nLe conseil que l\'on donne est d\'essayer de faire du full UTF-8 au<br />\nmaximum et à tous les niveaux (pour s\'en assurer, ce n\'est pas forcément<br />\névident).<br />\nVincent.</p>\n<p>Lucie Dengreville wrote:<br />\n<div class=\"emailFilter_Toggle\">\n<blockquote class=\"emailFilter_Author_0\"><p>> Bonjour,<br />\n><br />\n> Lorsque j\'enregistre un nouveau formulaire dans le module workflow, la<br />\n> fiche stockée dans la table ORI_WORKLFOW_INSTANCE au niveau du champs<br />\n> xmlContent n\'est pas complète : apparemment elle s\'arrête lorsqu\'elle<br />\n> rencontre un caractère accentué : par exemple au niveau d\'une vcards,<br />\n> la fiche fini par ORG: Universit lorsque je mets Université dans la<br />\n> vcards au niveau du fichier ldapVocabulary.xml du module de<br />\n> vocabulaire. Si j\'enlève l\'accent, la fiche est enregistrée dans le<br />\n> workflow s\'arrête plus loin, à un autre accent.<br />\n><br />\n> Comment faire pour résoudre ce problème ?<br />\n><br />\n> Lucie<br />\n></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 = 1507745742, expire = 1507832142, headers = '', serialized = 0 WHERE cid = '4:504b17034fccba634781f8db14c8e8f0' 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:4891b9628983d18775f66a1717c29cec' 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\">Je reviens sur ce problème :<br />\nCe n\'est qu\'avec un nouveau formulaire que cela se produit ?<br />\nQuel est l\'encodage des fichiers XForms/XML édités voir créés pour<br />\nréaliser ce formulaire ?<br />\n=> sous linux file -i peut par exemple permettre de voir quel encodage<br />\nest utilisé.<br />\nVincent.</p>\n<p>Vincent Bonamy wrote:<br />\n<div class=\"emailFilter_Toggle\">\n<blockquote class=\"emailFilter_Author_0\"><p>> Bonjour Lucie,<br />\n> Tu utilise MySQL (InnoDB) avec une base de données sous quel encodage ?<br />\n> L\'encodage par défaut sous MySQL est le latin suédois, as-tu opté pour<br />\n> l\'UTF-8 ?<br />\n> Peut-être également qu\'il y a un problème d\'encodage à un autre niveau<br />\n> ? Le charset par défaut du tomcat du module de vocabulaires ? Le<br />\n> fichier de vocabulaires des VCards ?<br />\n> Le conseil que l\'on donne est d\'essayer de faire du full UTF-8 au<br />\n> maximum et à tous les niveaux (pour s\'en assurer, ce n\'est pas<br />\n> forcément évident).<br />\n> Vincent.<br />\n><br />\n><br />\n> Lucie Dengreville wrote:</p></blockquote>\n<blockquote class=\"emailFilter_Author_1\"><p>>> Bonjour,<br />\n>><br />\n>> Lorsque j\'enregistre un nouveau formulaire dans le module workflow,<br />\n>> la fiche stockée dans la table ORI_WORKLFOW_INSTANCE au niveau du<br />\n>> champs xmlContent n\'est pas complète : apparemment elle s\'arrête<br />\n>> lorsqu\'elle rencontre un caractère accentué : par exemple au niveau<br />\n>> d\'une vcards, la fiche fini par ORG: Universit lorsque je mets<br />\n>> Université dans la vcards au niveau du fichier ldapVocabulary.xml du<br />\n>> module de vocabulaire. Si j\'enlève l\'accent, la fiche est enregistrée<br />\n>> dans le workflow s\'arrête plus loin, à un autre accent.<br />\n>><br />\n>> Comment faire pour résoudre ce problème ?<br />\n>><br />\n>> Lucie<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 = 1507745742, expire = 1507832142, headers = '', serialized = 0 WHERE cid = '4:4891b9628983d18775f66a1717c29cec' 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:34cb3b2b316cdf2be71389db8e067731' 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\">Ma base de données est en MyIsam mais mes tables sont bien en InnoDB,<br />\navec un encodage utf8_general_ci. Est-ce que celà pourrait provoquer<br />\ncette erreur ?<br />\nce problème se produit même avec un formulaire pour les documents dc,<br />\nque je n\'ai celui-ci pas modifié.<br />\nmes tomcat ont bien CATALINA_OPTS=\"-Dfile.encoding=UTF-8</p>\n<p>Pour les xforms utilisés, l\'encodage n\'est pas défini dans les fichiers<br />\nmain-form.xhtml et content-forms.xml.<br />\nLe fichier xml généré par un formulaire dans le module editor est bien<br />\ncomplet.</p>\n<p>Voici un exemple du xml créé au niveau de la base de données, il semble<br />\nbien encodé en utf-8 :</p>\n<p><?xml version=\"1.0\" encoding=\"UTF-8\"?><lom:lom<br />\nxmlns:lom=\"http://ltsc.ieee.org/xsd/LOM\"<br />\nxmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"<br />\nxsi:schemaLocation=\"http://ltsc.ieee.org/xsd/LOM<br />\nhttp://ltsc.ieee.org/xsd/lomv1.0/lom.xsd\"></p>\n<p> <lom:general><br />\n <lom:identifier><br />\n <lom:catalog>URI</lom:catalog></p>\n<p><lom:entry>http://orioai-1.uhb.fr/uid/uhb-ori-wf-1-null</lom:entry><br />\n </lom:identifier><br />\n <lom:title><br />\n <lom:string language=\"fr\">toto</lom:string><br />\n </lom:title><br />\n <lom:language>fr</lom:language><br />\n <lom:description><br />\n <lom:string language=\"fr\">tutu</lom:string><br />\n </lom:description><br />\n <lom:keyword><br />\n <lom:string language=\"fr\">informatique</lom:string><br />\n </lom:keyword><br />\n <lom:aggregationLevel><br />\n <lom:source>LOMv1.0</lom:source><br />\n <lom:value>1</lom:value><br />\n </lom:aggregationLevel><br />\n </lom:general><br />\n <lom:lifeCycle><br />\n <lom:contribute><br />\n <lom:role><br />\n <lom:source>LOMv1.0</lom:source><br />\n <lom:value>author</lom:value><br />\n </lom:role><br />\n <lom:entity><br />\nBEGIN:VCARD<br />\nVERSION:3.0<br />\nN:Afa;Ma<br />\nFN:Ma Afa<br />\nORG:Universit</p>\n<p>Vincent Bonamy a écrit :<br />\n<div class=\"emailFilter_Toggle\">\n<blockquote class=\"emailFilter_Author_0\"><p>> Je reviens sur ce problème :<br />\n> Ce n\'est qu\'avec un nouveau formulaire que cela se produit ?<br />\n> Quel est l\'encodage des fichiers XForms/XML édités voir créés pour<br />\n> réaliser ce formulaire ?<br />\n> => sous linux file -i peut par exemple permettre de voir quel encodage<br />\n> est utilisé.<br />\n> Vincent.<br />\n><br />\n><br />\n> Vincent Bonamy wrote:</p></blockquote>\n<blockquote class=\"emailFilter_Author_1\"><p>>> Bonjour Lucie,<br />\n>> Tu utilise MySQL (InnoDB) avec une base de données sous quel encodage ?<br />\n>> L\'encodage par défaut sous MySQL est le latin suédois, as-tu opté<br />\n>> pour l\'UTF-8 ?<br />\n>> Peut-être également qu\'il y a un problème d\'encodage à un autre<br />\n>> niveau ? Le charset par défaut du tomcat du module de vocabulaires ?<br />\n>> Le fichier de vocabulaires des VCards ?<br />\n>> Le conseil que l\'on donne est d\'essayer de faire du full UTF-8 au<br />\n>> maximum et à tous les niveaux (pour s\'en assurer, ce n\'est pas<br />\n>> forcément évident).<br />\n>> Vincent.<br />\n>><br />\n>><br />\n>> Lucie Dengreville wrote:</p></blockquote>\n<blockquote class=\"emailFilter_Author_2\"><p>>>> Bonjour,<br />\n>>><br />\n>>> Lorsque j\'enregistre un nouveau formulaire dans le module workflow,<br />\n>>> la fiche stockée dans la table ORI_WORKLFOW_INSTANCE au niveau du<br />\n>>> champs xmlContent n\'est pas complète : apparemment elle s\'arrête<br />\n>>> lorsqu\'elle rencontre un caractère accentué : par exemple au niveau<br />\n>>> d\'une vcards, la fiche fini par ORG: Universit lorsque je mets<br />\n>>> Université dans la vcards au niveau du fichier ldapVocabulary.xml du<br />\n>>> module de vocabulaire. Si j\'enlève l\'accent, la fiche est<br />\n>>> enregistrée dans le workflow s\'arrête plus loin, à un autre accent.<br />\n>>><br />\n>>> Comment faire pour résoudre ce problème ?<br />\n>>><br />\n>>> Lucie<br />\n>>></p></blockquote>\n<blockquote class=\"emailFilter_Author_1\"><p>>></p></blockquote>\n<blockquote class=\"emailFilter_Author_0\"><p>><br />\n></div>\n</blockquote>\n<p>--<br />\n----------------------------------<br />\nLucie Dengreville<br />\nCentre de Ressources Informatiques<br />\nUniversité Rennes 2 Haute Bretagne<br />\n02.99.14.13.66<br />\n-----------------------------------</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 = 1507745742, expire = 1507832142, headers = '', serialized = 0 WHERE cid = '4:34cb3b2b316cdf2be71389db8e067731' 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:08573ccd58c9c69009e0c861e207d5f9' 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\">J\'ai ma locale en fr_FR (LANG=fr_FR ..) sur mon serveur linux, faut-il<br />\nmieux que je change celà en utf8 ?</p>\n<p>Lucie Dengreville a écrit :<br />\n<div class=\"emailFilter_Toggle\">\n<blockquote class=\"emailFilter_Author_0\"><p>> Ma base de données est en MyIsam mais mes tables sont bien en InnoDB,<br />\n> avec un encodage utf8_general_ci. Est-ce que celà pourrait provoquer<br />\n> cette erreur ?<br />\n> ce problème se produit même avec un formulaire pour les documents dc,<br />\n> que je n\'ai celui-ci pas modifié.<br />\n> mes tomcat ont bien CATALINA_OPTS=\"-Dfile.encoding=UTF-8<br />\n><br />\n> Pour les xforms utilisés, l\'encodage n\'est pas défini dans les<br />\n> fichiers main-form.xhtml et content-forms.xml.<br />\n> Le fichier xml généré par un formulaire dans le module editor est bien<br />\n> complet.<br />\n><br />\n> Voici un exemple du xml créé au niveau de la base de données, il<br />\n> semble bien encodé en utf-8 :<br />\n><br />\n> <?xml version=\"1.0\" encoding=\"UTF-8\"?><lom:lom<br />\n> xmlns:lom=\"http://ltsc.ieee.org/xsd/LOM\"<br />\n> xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"<br />\n> xsi:schemaLocation=\"http://ltsc.ieee.org/xsd/LOM<br />\n> http://ltsc.ieee.org/xsd/lomv1.0/lom.xsd\"><br />\n><br />\n> <lom:general><br />\n> <lom:identifier><br />\n> <lom:catalog>URI</lom:catalog><br />\n><br />\n> <lom:entry>http://orioai-1.uhb.fr/uid/uhb-ori-wf-1-null</lom:entry><br />\n> </lom:identifier><br />\n> <lom:title><br />\n> <lom:string language=\"fr\">toto</lom:string><br />\n> </lom:title><br />\n> <lom:language>fr</lom:language> <lom:description><br />\n> <lom:string language=\"fr\">tutu</lom:string><br />\n> </lom:description><br />\n> <lom:keyword><br />\n> <lom:string language=\"fr\">informatique</lom:string><br />\n> </lom:keyword><br />\n> <lom:aggregationLevel><br />\n> <lom:source>LOMv1.0</lom:source><br />\n> <lom:value>1</lom:value><br />\n> </lom:aggregationLevel><br />\n> </lom:general><br />\n> <lom:lifeCycle><br />\n> <lom:contribute><br />\n> <lom:role><br />\n> <lom:source>LOMv1.0</lom:source><br />\n> <lom:value>author</lom:value><br />\n> </lom:role><br />\n> <lom:entity><br />\n> BEGIN:VCARD<br />\n> VERSION:3.0<br />\n> N:Afa;Ma<br />\n> FN:Ma Afa<br />\n> ORG:Universit<br />\n><br />\n><br />\n><br />\n><br />\n><br />\n><br />\n><br />\n> Vincent Bonamy a écrit :</p></blockquote>\n<blockquote class=\"emailFilter_Author_1\"><p>>> Je reviens sur ce problème :<br />\n>> Ce n\'est qu\'avec un nouveau formulaire que cela se produit ?<br />\n>> Quel est l\'encodage des fichiers XForms/XML édités voir créés pour<br />\n>> réaliser ce formulaire ?<br />\n>> => sous linux file -i peut par exemple permettre de voir quel<br />\n>> encodage est utilisé.<br />\n>> Vincent.<br />\n>><br />\n>><br />\n>> Vincent Bonamy wrote:</p></blockquote>\n<blockquote class=\"emailFilter_Author_2\"><p>>>> Bonjour Lucie,<br />\n>>> Tu utilise MySQL (InnoDB) avec une base de données sous quel encodage ?<br />\n>>> L\'encodage par défaut sous MySQL est le latin suédois, as-tu opté<br />\n>>> pour l\'UTF-8 ?<br />\n>>> Peut-être également qu\'il y a un problème d\'encodage à un autre<br />\n>>> niveau ? Le charset par défaut du tomcat du module de vocabulaires ?<br />\n>>> Le fichier de vocabulaires des VCards ?<br />\n>>> Le conseil que l\'on donne est d\'essayer de faire du full UTF-8 au<br />\n>>> maximum et à tous les niveaux (pour s\'en assurer, ce n\'est pas<br />\n>>> forcément évident).<br />\n>>> Vincent.<br />\n>>><br />\n>>><br />\n>>> Lucie Dengreville wrote:</p></blockquote>\n<blockquote class=\"emailFilter_Author_3\"><p>>>>> Bonjour,<br />\n>>>><br />\n>>>> Lorsque j\'enregistre un nouveau formulaire dans le module workflow,<br />\n>>>> la fiche stockée dans la table ORI_WORKLFOW_INSTANCE au niveau du<br />\n>>>> champs xmlContent n\'est pas complète : apparemment elle s\'arrête<br />\n>>>> lorsqu\'elle rencontre un caractère accentué : par exemple au niveau<br />\n>>>> d\'une vcards, la fiche fini par ORG: Universit lorsque je mets<br />\n>>>> Université dans la vcards au niveau du fichier ldapVocabulary.xml<br />\n>>>> du module de vocabulaire. Si j\'enlève l\'accent, la fiche est<br />\n>>>> enregistrée dans le workflow s\'arrête plus loin, à un autre accent.<br />\n>>>><br />\n>>>> Comment faire pour résoudre ce problème ?<br />\n>>>><br />\n>>>> Lucie<br />\n>>>></p></blockquote>\n<blockquote class=\"emailFilter_Author_2\"><p>>>></p></blockquote>\n<blockquote class=\"emailFilter_Author_1\"><p>>><br />\n>></p></blockquote>\n<blockquote class=\"emailFilter_Author_0\"><p>><br />\n></div>\n</blockquote>\n<p>--<br />\n----------------------------------<br />\nLucie Dengreville<br />\nCentre de Ressources Informatiques<br />\nUniversité Rennes 2 Haute Bretagne<br />\n02.99.14.13.66<br />\n-----------------------------------</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 = 1507745742, expire = 1507832142, headers = '', serialized = 0 WHERE cid = '4:08573ccd58c9c69009e0c861e207d5f9' 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:11c3e7013164b36290a0fc7832c9c1f1' 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 Lucie,</p>\n<p>Je ne suis sûr de rien dans ces questions d\'encodage [c\'est de toute<br />\nmanière toujours un vrai casse-tête quand ça ne fonctionne pas ...],<br />\nmais le -Dfile.encoding du CATALINA_OPTS devrait surcharger ta locale je<br />\npense dans le contexte d\'exécution du Tomcat [enfin ... peut-être !] ...<br />\nAussi à trop vouloir forcer l\'encodage, on arrive parfois à coder des<br />\ncodes UTF-8 eux-mêmes en UTF-8 par exemple (!).<br />\nCe que je veux dire c\'est qu\'on se retrouve avec plus de problèmes que<br />\nsi on avait laissé les choses par défaut ...<br />\n=> En bref, je te conseillerai de voir ce que cela fait (pour tests,<br />\nnotamment si tu penses avoir tout vérifié dans le sens ISO-> UTF-8) si<br />\ntu laisses par exemple l\'encodage par défaut de MySQL en ISO [latin]<br />\n(sachant que ce n\'est pas parcequ\'il stocke en ISO qu\'il ne va pas<br />\nrépondre en UTF-8 (!!) [car il peut réencoder les caractères à la volée<br />\négalement peut-être ...]) .</p>\n<p>Maintenant je dis peut-être plein de bêtises (on en arrive à tout<br />\nremettre en cause avec les pbs d\'encodage ...) et si quelqu\'un en sait<br />\nplus ou a tout simplement un avis/piste sur la question, qu\'il n\'hésite<br />\npas à intervenir !</p>\n<p>A bientôt, merci de nous tenir informés,<br />\nVincent.</p>\n<p>Lucie Dengreville wrote:<br />\n<div class=\"emailFilter_Toggle\">\n<blockquote class=\"emailFilter_Author_0\"><p>> J\'ai ma locale en fr_FR (LANG=fr_FR ..) sur mon serveur linux,<br />\n> faut-il mieux que je change celà en utf8 ?<br />\n><br />\n> Lucie Dengreville a écrit :</p></blockquote>\n<blockquote class=\"emailFilter_Author_1\"><p>>> Ma base de données est en MyIsam mais mes tables sont bien en InnoDB,<br />\n>> avec un encodage utf8_general_ci. Est-ce que celà pourrait provoquer<br />\n>> cette erreur ?<br />\n>> ce problème se produit même avec un formulaire pour les documents dc,<br />\n>> que je n\'ai celui-ci pas modifié.<br />\n>> mes tomcat ont bien CATALINA_OPTS=\"-Dfile.encoding=UTF-8<br />\n>><br />\n>> Pour les xforms utilisés, l\'encodage n\'est pas défini dans les<br />\n>> fichiers main-form.xhtml et content-forms.xml.<br />\n>> Le fichier xml généré par un formulaire dans le module editor est<br />\n>> bien complet.<br />\n>><br />\n>> Voici un exemple du xml créé au niveau de la base de données, il<br />\n>> semble bien encodé en utf-8 :<br />\n>><br />\n>> <?xml version=\"1.0\" encoding=\"UTF-8\"?><lom:lom<br />\n>> xmlns:lom=\"http://ltsc.ieee.org/xsd/LOM\"<br />\n>> xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"<br />\n>> xsi:schemaLocation=\"http://ltsc.ieee.org/xsd/LOM<br />\n>> http://ltsc.ieee.org/xsd/lomv1.0/lom.xsd\"><br />\n>><br />\n>> <lom:general><br />\n>> <lom:identifier><br />\n>> <lom:catalog>URI</lom:catalog><br />\n>><br />\n>> <lom:entry>http://orioai-1.uhb.fr/uid/uhb-ori-wf-1-null</lom:entry><br />\n>> </lom:identifier><br />\n>> <lom:title><br />\n>> <lom:string language=\"fr\">toto</lom:string><br />\n>> </lom:title><br />\n>> <lom:language>fr</lom:language> <lom:description><br />\n>> <lom:string language=\"fr\">tutu</lom:string><br />\n>> </lom:description><br />\n>> <lom:keyword><br />\n>> <lom:string language=\"fr\">informatique</lom:string><br />\n>> </lom:keyword><br />\n>> <lom:aggregationLevel><br />\n>> <lom:source>LOMv1.0</lom:source><br />\n>> <lom:value>1</lom:value><br />\n>> </lom:aggregationLevel><br />\n>> </lom:general><br />\n>> <lom:lifeCycle><br />\n>> <lom:contribute><br />\n>> <lom:role><br />\n>> <lom:source>LOMv1.0</lom:source><br />\n>> <lom:value>author</lom:value><br />\n>> </lom:role><br />\n>> <lom:entity><br />\n>> BEGIN:VCARD<br />\n>> VERSION:3.0<br />\n>> N:Afa;Ma<br />\n>> FN:Ma Afa<br />\n>> ORG:Universit<br />\n>><br />\n>><br />\n>><br />\n>><br />\n>><br />\n>><br />\n>><br />\n>> Vincent Bonamy a écrit :</p></blockquote>\n<blockquote class=\"emailFilter_Author_2\"><p>>>> Je reviens sur ce problème :<br />\n>>> Ce n\'est qu\'avec un nouveau formulaire que cela se produit ?<br />\n>>> Quel est l\'encodage des fichiers XForms/XML édités voir créés pour<br />\n>>> réaliser ce formulaire ?<br />\n>>> => sous linux file -i peut par exemple permettre de voir quel<br />\n>>> encodage est utilisé.<br />\n>>> Vincent.<br />\n>>><br />\n>>><br />\n>>> Vincent Bonamy wrote:</p></blockquote>\n<blockquote class=\"emailFilter_Author_3\"><p>>>>> Bonjour Lucie,<br />\n>>>> Tu utilise MySQL (InnoDB) avec une base de données sous quel<br />\n>>>> encodage ?<br />\n>>>> L\'encodage par défaut sous MySQL est le latin suédois, as-tu opté<br />\n>>>> pour l\'UTF-8 ?<br />\n>>>> Peut-être également qu\'il y a un problème d\'encodage à un autre<br />\n>>>> niveau ? Le charset par défaut du tomcat du module de vocabulaires<br />\n>>>> ? Le fichier de vocabulaires des VCards ?<br />\n>>>> Le conseil que l\'on donne est d\'essayer de faire du full UTF-8 au<br />\n>>>> maximum et à tous les niveaux (pour s\'en assurer, ce n\'est pas<br />\n>>>> forcément évident).<br />\n>>>> Vincent.<br />\n>>>><br />\n>>>><br />\n>>>> Lucie Dengreville wrote:</p></blockquote>\n<blockquote class=\"emailFilter_Author_4\"><p>>>>>> Bonjour,<br />\n>>>>><br />\n>>>>> Lorsque j\'enregistre un nouveau formulaire dans le module<br />\n>>>>> workflow, la fiche stockée dans la table ORI_WORKLFOW_INSTANCE au<br />\n>>>>> niveau du champs xmlContent n\'est pas complète : apparemment elle<br />\n>>>>> s\'arrête lorsqu\'elle rencontre un caractère accentué : par exemple<br />\n>>>>> au niveau d\'une vcards, la fiche fini par ORG: Universit lorsque<br />\n>>>>> je mets Université dans la vcards au niveau du fichier<br />\n>>>>> ldapVocabulary.xml du module de vocabulaire. Si j\'enlève l\'accent,<br />\n>>>>> la fiche est enregistrée dans le workflow s\'arrête plus loin, à un<br />\n>>>>> autre accent.<br />\n>>>>><br />\n>>>>> Comment faire pour résoudre ce problème ?<br />\n>>>>><br />\n>>>>> Lucie<br />\n>>>>></p></blockquote>\n<blockquote class=\"emailFilter_Author_3\"><p>>>>></p></blockquote>\n<blockquote class=\"emailFilter_Author_2\"><p>>>><br />\n>>></p></blockquote>\n<blockquote class=\"emailFilter_Author_1\"><p>>><br />\n>></p></blockquote>\n<blockquote class=\"emailFilter_Author_0\"><p>><br />\n></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 = 1507745742, expire = 1507832142, headers = '', serialized = 0 WHERE cid = '4:11c3e7013164b36290a0fc7832c9c1f1' 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:92d1e2ca3db38104eb1766170589aa24' 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\">cas pas de problème d\'encodage.<br />\nPS2: il est très certainement préférable d\'être full UTF-8 du début à la<br />\nfin pour ORI-OAI ou n\'importe quoi d\'autre. Aussi dès l\'installation de<br />\nla machine, choisir la locale en UTF-8 me parait être la bonne pratique.<br />\nMaintenant des problèmes peuvent se poser quand on installe un<br />\napplicatif en utilisant plusieurs machines qui ont des encodages<br />\ndifférents (sur un même parc serveurs, des vieilles machines peuvent<br />\nêtre en ISO, alors que les nouvelles sont en UTF-8 ...)</p>\n<p>=> donc il est certain que si tu as la possibilité de redéfinir ta<br />\nlocale c\'est sans doute mieux ... mais si d\'autres applicatifs tournent<br />\nsur cette machine, ca risque forcément de tout casser ... :-S</p>\n<p>Vincent.</p>\n<p>Vincent Bonamy wrote:<br />\n<div class=\"emailFilter_Toggle\">\n<blockquote class=\"emailFilter_Author_0\"><p>> Bonjour Lucie,<br />\n><br />\n> Je ne suis sûr de rien dans ces questions d\'encodage [c\'est de toute<br />\n> manière toujours un vrai casse-tête quand ça ne fonctionne pas ...],<br />\n> mais le -Dfile.encoding du CATALINA_OPTS devrait surcharger ta locale<br />\n> je pense dans le contexte d\'exécution du Tomcat [enfin ... peut-être<br />\n> !] ...<br />\n> Aussi à trop vouloir forcer l\'encodage, on arrive parfois à coder des<br />\n> codes UTF-8 eux-mêmes en UTF-8 par exemple (!).<br />\n> Ce que je veux dire c\'est qu\'on se retrouve avec plus de problèmes que<br />\n> si on avait laissé les choses par défaut ...<br />\n> => En bref, je te conseillerai de voir ce que cela fait (pour tests,<br />\n> notamment si tu penses avoir tout vérifié dans le sens ISO-> UTF-8) si<br />\n> tu laisses par exemple l\'encodage par défaut de MySQL en ISO [latin]<br />\n> (sachant que ce n\'est pas parcequ\'il stocke en ISO qu\'il ne va pas<br />\n> répondre en UTF-8 (!!) [car il peut réencoder les caractères à la<br />\n> volée également peut-être ...]) .<br />\n><br />\n> Maintenant je dis peut-être plein de bêtises (on en arrive à tout<br />\n> remettre en cause avec les pbs d\'encodage ...) et si quelqu\'un en sait<br />\n> plus ou a tout simplement un avis/piste sur la question, qu\'il<br />\n> n\'hésite pas à intervenir !<br />\n><br />\n> A bientôt, merci de nous tenir informés,<br />\n> Vincent.<br />\n><br />\n><br />\n> Lucie Dengreville wrote:</p></blockquote>\n<blockquote class=\"emailFilter_Author_1\"><p>>> J\'ai ma locale en fr_FR (LANG=fr_FR ..) sur mon serveur linux,<br />\n>> faut-il mieux que je change celà en utf8 ?<br />\n>><br />\n>> Lucie Dengreville a écrit :</p></blockquote>\n<blockquote class=\"emailFilter_Author_2\"><p>>>> Ma base de données est en MyIsam mais mes tables sont bien en<br />\n>>> InnoDB, avec un encodage utf8_general_ci. Est-ce que celà pourrait<br />\n>>> provoquer cette erreur ?<br />\n>>> ce problème se produit même avec un formulaire pour les documents<br />\n>>> dc, que je n\'ai celui-ci pas modifié.<br />\n>>> mes tomcat ont bien CATALINA_OPTS=\"-Dfile.encoding=UTF-8<br />\n>>><br />\n>>> Pour les xforms utilisés, l\'encodage n\'est pas défini dans les<br />\n>>> fichiers main-form.xhtml et content-forms.xml.<br />\n>>> Le fichier xml généré par un formulaire dans le module editor est<br />\n>>> bien complet.<br />\n>>><br />\n>>> Voici un exemple du xml créé au niveau de la base de données, il<br />\n>>> semble bien encodé en utf-8 :<br />\n>>><br />\n>>> <?xml version=\"1.0\" encoding=\"UTF-8\"?><lom:lom<br />\n>>> xmlns:lom=\"http://ltsc.ieee.org/xsd/LOM\"<br />\n>>> xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"<br />\n>>> xsi:schemaLocation=\"http://ltsc.ieee.org/xsd/LOM<br />\n>>> http://ltsc.ieee.org/xsd/lomv1.0/lom.xsd\"><br />\n>>><br />\n>>> <lom:general><br />\n>>> <lom:identifier><br />\n>>> <lom:catalog>URI</lom:catalog><br />\n>>><br />\n>>> <lom:entry>http://orioai-1.uhb.fr/uid/uhb-ori-wf-1-null</lom:entry><br />\n>>> </lom:identifier><br />\n>>> <lom:title><br />\n>>> <lom:string language=\"fr\">toto</lom:string><br />\n>>> </lom:title><br />\n>>> <lom:language>fr</lom:language> <lom:description><br />\n>>> <lom:string language=\"fr\">tutu</lom:string><br />\n>>> </lom:description><br />\n>>> <lom:keyword><br />\n>>> <lom:string language=\"fr\">informatique</lom:string><br />\n>>> </lom:keyword><br />\n>>> <lom:aggregationLevel><br />\n>>> <lom:source>LOMv1.0</lom:source><br />\n>>> <lom:value>1</lom:value><br />\n>>> </lom:aggregationLevel><br />\n>>> </lom:general><br />\n>>> <lom:lifeCycle><br />\n>>> <lom:contribute><br />\n>>> <lom:role><br />\n>>> <lom:source>LOMv1.0</lom:source><br />\n>>> <lom:value>author</lom:value><br />\n>>> </lom:role><br />\n>>> <lom:entity><br />\n>>> BEGIN:VCARD<br />\n>>> VERSION:3.0<br />\n>>> N:Afa;Ma<br />\n>>> FN:Ma Afa<br />\n>>> ORG:Universit<br />\n>>><br />\n>>><br />\n>>><br />\n>>><br />\n>>><br />\n>>><br />\n>>><br />\n>>> Vincent Bonamy a écrit :</p></blockquote>\n<blockquote class=\"emailFilter_Author_3\"><p>>>>> Je reviens sur ce problème :<br />\n>>>> Ce n\'est qu\'avec un nouveau formulaire que cela se produit ?<br />\n>>>> Quel est l\'encodage des fichiers XForms/XML édités voir créés pour<br />\n>>>> réaliser ce formulaire ?<br />\n>>>> => sous linux file -i peut par exemple permettre de voir quel<br />\n>>>> encodage est utilisé.<br />\n>>>> Vincent.<br />\n>>>><br />\n>>>><br />\n>>>> Vincent Bonamy wrote:</p></blockquote>\n<blockquote class=\"emailFilter_Author_4\"><p>>>>>> Bonjour Lucie,<br />\n>>>>> Tu utilise MySQL (InnoDB) avec une base de données sous quel<br />\n>>>>> encodage ?<br />\n>>>>> L\'encodage par défaut sous MySQL est le latin suédois, as-tu opté<br />\n>>>>> pour l\'UTF-8 ?<br />\n>>>>> Peut-être également qu\'il y a un problème d\'encodage à un autre<br />\n>>>>> niveau ? Le charset par défaut du tomcat du module de vocabulaires<br />\n>>>>> ? Le fichier de vocabulaires des VCards ?<br />\n>>>>> Le conseil que l\'on donne est d\'essayer de faire du full UTF-8 au<br />\n>>>>> maximum et à tous les niveaux (pour s\'en assurer, ce n\'est pas<br />\n>>>>> forcément évident).<br />\n>>>>> Vincent.<br />\n>>>>><br />\n>>>>><br />\n>>>>> Lucie Dengreville wrote:</p></blockquote>\n<blockquote class=\"emailFilter_Author_5\"><p>>>>>>> Bonjour,<br />\n>>>>>><br />\n>>>>>> Lorsque j\'enregistre un nouveau formulaire dans le module<br />\n>>>>>> workflow, la fiche stockée dans la table ORI_WORKLFOW_INSTANCE au<br />\n>>>>>> niveau du champs xmlContent n\'est pas complète : apparemment elle<br />\n>>>>>> s\'arrête lorsqu\'elle rencontre un caractère accentué : par<br />\n>>>>>> exemple au niveau d\'une vcards, la fiche fini par ORG: Universit<br />\n>>>>>> lorsque je mets Université dans la vcards au niveau du fichier<br />\n>>>>>> ldapVocabulary.xml du module de vocabulaire. Si j\'enlève<br />\n>>>>>> l\'accent, la fiche est enregistrée dans le workflow s\'arrête plus<br />\n>>>>>> loin, à un autre accent.<br />\n>>>>>><br />\n>>>>>> Comment faire pour résoudre ce problème ?<br />\n>>>>>><br />\n>>>>>> Lucie<br />\n>>>>>></p></blockquote>\n<blockquote class=\"emailFilter_Author_4\"><p>>>>>></p></blockquote>\n<blockquote class=\"emailFilter_Author_3\"><p>>>>><br />\n>>>></p></blockquote>\n<blockquote class=\"emailFilter_Author_2\"><p>>>><br />\n>>></p></blockquote>\n<blockquote class=\"emailFilter_Author_1\"><p>>><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 = 1507745742, expire = 1507832142, headers = '', serialized = 0 WHERE cid = '4:92d1e2ca3db38104eb1766170589aa24' 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:679cbbcead609bdcba0c02573aed63cd' 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\">\nj\'ai mis ma locale en utf-8, j\'ai tout recommencé en refaisant des<br />\ncheckout depuis les repositories pour les modules indexing, vocabulary,<br />\neditor et workflow.Comme je faisais des scp depuis mon poste vers le<br />\nserveur, je me disais que ça pouvait venir des fichiers transféré, du<br />\ncoup j\'ai aussi mis mon encodage eclipse en utf-8.<br />\nMalheureusement mon problème n\'est toujours pas résolu, et je ne vois<br />\npas d\'où ça peut venir.<br />\napparemment le fichier xml transmis par l\'éditeur a l\'air correct car<br />\ndans la base de données du workflow le titre est correctement renseigné<br />\nmême s\'il existe des accents : dans ce cas le fichier xml dans la base<br />\ns\'arrête dès le titre.<br />\nj\'avais déjà réussi à enregistrer des fiches (contenant des accents)<br />\navec la configuration du workflow par défaut.<br />\nC\'est en configurant le workflow, l\'éditeur et le vocabulaire avec le<br />\nworkflow de rennes 2 que le problème est survenu (la création de<br />\nformulaire en passant par l\'éditeur ne posait pas de problème, les<br />\nfiches étaient complètes).<br />\n En reprenant tout depuis le svn , donc avec la configuration par<br />\ndéfaut, j\'ai toujours le problème..</p>\n<p>lucie</p>\n<p>Vincent Bonamy a écrit :<br />\n<div class=\"emailFilter_Toggle\">\n<blockquote class=\"emailFilter_Author_0\"><p>> PS: sur UNIT la base MYSQL est en ISO, à Rennes1 en UTF-8. Dans les 2<br />\n> cas pas de problème d\'encodage.<br />\n> PS2: il est très certainement préférable d\'être full UTF-8 du début à<br />\n> la fin pour ORI-OAI ou n\'importe quoi d\'autre. Aussi dès<br />\n> l\'installation de la machine, choisir la locale en UTF-8 me parait<br />\n> être la bonne pratique.<br />\n> Maintenant des problèmes peuvent se poser quand on installe un<br />\n> applicatif en utilisant plusieurs machines qui ont des encodages<br />\n> différents (sur un même parc serveurs, des vieilles machines peuvent<br />\n> être en ISO, alors que les nouvelles sont en UTF-8 ...)<br />\n><br />\n> => donc il est certain que si tu as la possibilité de redéfinir ta<br />\n> locale c\'est sans doute mieux ... mais si d\'autres applicatifs<br />\n> tournent sur cette machine, ca risque forcément de tout casser ... :-S<br />\n><br />\n> Vincent.<br />\n><br />\n><br />\n> Vincent Bonamy wrote:</p></blockquote>\n<blockquote class=\"emailFilter_Author_1\"><p>>> Bonjour Lucie,<br />\n>><br />\n>> Je ne suis sûr de rien dans ces questions d\'encodage [c\'est de toute<br />\n>> manière toujours un vrai casse-tête quand ça ne fonctionne pas ...],<br />\n>> mais le -Dfile.encoding du CATALINA_OPTS devrait surcharger ta locale<br />\n>> je pense dans le contexte d\'exécution du Tomcat [enfin ... peut-être<br />\n>> !] ...<br />\n>> Aussi à trop vouloir forcer l\'encodage, on arrive parfois à coder des<br />\n>> codes UTF-8 eux-mêmes en UTF-8 par exemple (!).<br />\n>> Ce que je veux dire c\'est qu\'on se retrouve avec plus de problèmes<br />\n>> que si on avait laissé les choses par défaut ...<br />\n>> => En bref, je te conseillerai de voir ce que cela fait (pour tests,<br />\n>> notamment si tu penses avoir tout vérifié dans le sens ISO-> UTF-8)<br />\n>> si tu laisses par exemple l\'encodage par défaut de MySQL en ISO<br />\n>> [latin] (sachant que ce n\'est pas parcequ\'il stocke en ISO qu\'il ne<br />\n>> va pas répondre en UTF-8 (!!) [car il peut réencoder les caractères à<br />\n>> la volée également peut-être ...]) .<br />\n>><br />\n>> Maintenant je dis peut-être plein de bêtises (on en arrive à tout<br />\n>> remettre en cause avec les pbs d\'encodage ...) et si quelqu\'un en<br />\n>> sait plus ou a tout simplement un avis/piste sur la question, qu\'il<br />\n>> n\'hésite pas à intervenir !<br />\n>><br />\n>> A bientôt, merci de nous tenir informés,<br />\n>> Vincent.<br />\n>><br />\n>><br />\n>> Lucie Dengreville wrote:</p></blockquote>\n<blockquote class=\"emailFilter_Author_2\"><p>>>> J\'ai ma locale en fr_FR (LANG=fr_FR ..) sur mon serveur linux,<br />\n>>> faut-il mieux que je change celà en utf8 ?<br />\n>>><br />\n>>> Lucie Dengreville a écrit :</p></blockquote>\n<blockquote class=\"emailFilter_Author_3\"><p>>>>> Ma base de données est en MyIsam mais mes tables sont bien en<br />\n>>>> InnoDB, avec un encodage utf8_general_ci. Est-ce que celà pourrait<br />\n>>>> provoquer cette erreur ?<br />\n>>>> ce problème se produit même avec un formulaire pour les documents<br />\n>>>> dc, que je n\'ai celui-ci pas modifié.<br />\n>>>> mes tomcat ont bien CATALINA_OPTS=\"-Dfile.encoding=UTF-8<br />\n>>>><br />\n>>>> Pour les xforms utilisés, l\'encodage n\'est pas défini dans les<br />\n>>>> fichiers main-form.xhtml et content-forms.xml.<br />\n>>>> Le fichier xml généré par un formulaire dans le module editor est<br />\n>>>> bien complet.<br />\n>>>><br />\n>>>> Voici un exemple du xml créé au niveau de la base de données, il<br />\n>>>> semble bien encodé en utf-8 :<br />\n>>>><br />\n>>>> <?xml version=\"1.0\" encoding=\"UTF-8\"?><lom:lom<br />\n>>>> xmlns:lom=\"http://ltsc.ieee.org/xsd/LOM\"<br />\n>>>> xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"<br />\n>>>> xsi:schemaLocation=\"http://ltsc.ieee.org/xsd/LOM<br />\n>>>> http://ltsc.ieee.org/xsd/lomv1.0/lom.xsd\"><br />\n>>>><br />\n>>>> <lom:general><br />\n>>>> <lom:identifier><br />\n>>>> <lom:catalog>URI</lom:catalog><br />\n>>>><br />\n>>>> <lom:entry>http://orioai-1.uhb.fr/uid/uhb-ori-wf-1-null</lom:entry><br />\n>>>> </lom:identifier><br />\n>>>> <lom:title><br />\n>>>> <lom:string language=\"fr\">toto</lom:string><br />\n>>>> </lom:title><br />\n>>>> <lom:language>fr</lom:language> <lom:description><br />\n>>>> <lom:string language=\"fr\">tutu</lom:string><br />\n>>>> </lom:description><br />\n>>>> <lom:keyword><br />\n>>>> <lom:string language=\"fr\">informatique</lom:string><br />\n>>>> </lom:keyword><br />\n>>>> <lom:aggregationLevel><br />\n>>>> <lom:source>LOMv1.0</lom:source><br />\n>>>> <lom:value>1</lom:value><br />\n>>>> </lom:aggregationLevel><br />\n>>>> </lom:general><br />\n>>>> <lom:lifeCycle><br />\n>>>> <lom:contribute><br />\n>>>> <lom:role><br />\n>>>> <lom:source>LOMv1.0</lom:source><br />\n>>>> <lom:value>author</lom:value><br />\n>>>> </lom:role><br />\n>>>> <lom:entity><br />\n>>>> BEGIN:VCARD<br />\n>>>> VERSION:3.0<br />\n>>>> N:Afa;Ma<br />\n>>>> FN:Ma Afa<br />\n>>>> ORG:Universit<br />\n>>>><br />\n>>>><br />\n>>>><br />\n>>>><br />\n>>>><br />\n>>>><br />\n>>>><br />\n>>>> Vincent Bonamy a écrit :</p></blockquote>\n<blockquote class=\"emailFilter_Author_4\"><p>>>>>> Je reviens sur ce problème :<br />\n>>>>> Ce n\'est qu\'avec un nouveau formulaire que cela se produit ?<br />\n>>>>> Quel est l\'encodage des fichiers XForms/XML édités voir créés pour<br />\n>>>>> réaliser ce formulaire ?<br />\n>>>>> => sous linux file -i peut par exemple permettre de voir quel<br />\n>>>>> encodage est utilisé.<br />\n>>>>> Vincent.<br />\n>>>>><br />\n>>>>><br />\n>>>>> Vincent Bonamy wrote:</p></blockquote>\n<blockquote class=\"emailFilter_Author_5\"><p>>>>>>> Bonjour Lucie,<br />\n>>>>>> Tu utilise MySQL (InnoDB) avec une base de données sous quel<br />\n>>>>>> encodage ?<br />\n>>>>>> L\'encodage par défaut sous MySQL est le latin suédois, as-tu opté<br />\n>>>>>> pour l\'UTF-8 ?<br />\n>>>>>> Peut-être également qu\'il y a un problème d\'encodage à un autre<br />\n>>>>>> niveau ? Le charset par défaut du tomcat du module de<br />\n>>>>>> vocabulaires ? Le fichier de vocabulaires des VCards ?<br />\n>>>>>> Le conseil que l\'on donne est d\'essayer de faire du full UTF-8 au<br />\n>>>>>> maximum et à tous les niveaux (pour s\'en assurer, ce n\'est pas<br />\n>>>>>> forcément évident).<br />\n>>>>>> Vincent.<br />\n>>>>>><br />\n>>>>>><br />\n>>>>>> Lucie Dengreville wrote:</p></blockquote>\n<blockquote class=\"emailFilter_Author_6\"><p>>>>>>>> Bonjour,<br />\n>>>>>>><br />\n>>>>>>> Lorsque j\'enregistre un nouveau formulaire dans le module<br />\n>>>>>>> workflow, la fiche stockée dans la table ORI_WORKLFOW_INSTANCE<br />\n>>>>>>> au niveau du champs xmlContent n\'est pas complète : apparemment<br />\n>>>>>>> elle s\'arrête lorsqu\'elle rencontre un caractère accentué : par<br />\n>>>>>>> exemple au niveau d\'une vcards, la fiche fini par ORG:<br />\n>>>>>>> Universit lorsque je mets Université dans la vcards au niveau du<br />\n>>>>>>> fichier ldapVocabulary.xml du module de vocabulaire. Si j\'enlève<br />\n>>>>>>> l\'accent, la fiche est enregistrée dans le workflow s\'arrête<br />\n>>>>>>> plus loin, à un autre accent.<br />\n>>>>>>><br />\n>>>>>>> Comment faire pour résoudre ce problème ?<br />\n>>>>>>><br />\n>>>>>>> Lucie<br />\n>>>>>>></p></blockquote>\n<blockquote class=\"emailFilter_Author_5\"><p>>>>>>></p></blockquote>\n<blockquote class=\"emailFilter_Author_4\"><p>>>>>><br />\n>>>>></p></blockquote>\n<blockquote class=\"emailFilter_Author_3\"><p>>>>><br />\n>>>></p></blockquote>\n<blockquote class=\"emailFilter_Author_2\"><p>>>><br />\n>>></p></blockquote>\n<blockquote class=\"emailFilter_Author_1\"><p>>></p></blockquote>\n<blockquote class=\"emailFilter_Author_0\"><p>><br />\n></div>\n</blockquote>\n<p>--<br />\n----------------------------------<br />\nLucie Dengreville<br />\nCentre de Ressources Informatiques<br />\nUniversité Rennes 2 Haute Bretagne<br />\n02.99.14.13.66<br />\n-----------------------------------</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 = 1507745742, expire = 1507832142, headers = '', serialized = 0 WHERE cid = '4:679cbbcead609bdcba0c02573aed63cd' 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:09ae01a4ccc12b4e22d0ba55aae66a90' 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\">mon problème parait résolu. Il semble que ce soit un problème au niveau<br />\nde l\'indexing pour lequel le chemin du répertoire indexes n\'était pas<br />\ncorrect.<br />\nj\'avais mis ma base de données en latin 1 mais celà n\'avait rien changé.</p>\n<p>merci en tout cas à Vincent pour ses réponses.</p>\n<p>Lucie</p>\n<p>Lucie Dengreville a écrit :<br />\n<div class=\"emailFilter_Toggle\">\n<blockquote class=\"emailFilter_Author_0\"><p>><br />\n> j\'ai mis ma locale en utf-8, j\'ai tout recommencé en refaisant des<br />\n> checkout depuis les repositories pour les modules indexing,<br />\n> vocabulary, editor et workflow.Comme je faisais des scp depuis mon<br />\n> poste vers le serveur, je me disais que ça pouvait venir des fichiers<br />\n> transféré, du coup j\'ai aussi mis mon encodage eclipse en utf-8.<br />\n> Malheureusement mon problème n\'est toujours pas résolu, et je ne vois<br />\n> pas d\'où ça peut venir.<br />\n> apparemment le fichier xml transmis par l\'éditeur a l\'air correct car<br />\n> dans la base de données du workflow le titre est correctement<br />\n> renseigné même s\'il existe des accents : dans ce cas le fichier xml<br />\n> dans la base s\'arrête dès le titre.<br />\n> j\'avais déjà réussi à enregistrer des fiches (contenant des accents)<br />\n> avec la configuration du workflow par défaut.<br />\n> C\'est en configurant le workflow, l\'éditeur et le vocabulaire avec le<br />\n> workflow de rennes 2 que le problème est survenu (la création de<br />\n> formulaire en passant par l\'éditeur ne posait pas de problème, les<br />\n> fiches étaient complètes).<br />\n> En reprenant tout depuis le svn , donc avec la configuration par<br />\n> défaut, j\'ai toujours le problème..<br />\n><br />\n> lucie<br />\n><br />\n><br />\n><br />\n><br />\n> Vincent Bonamy a écrit :</p></blockquote>\n<blockquote class=\"emailFilter_Author_1\"><p>>> PS: sur UNIT la base MYSQL est en ISO, à Rennes1 en UTF-8. Dans les 2<br />\n>> cas pas de problème d\'encodage.<br />\n>> PS2: il est très certainement préférable d\'être full UTF-8 du début à<br />\n>> la fin pour ORI-OAI ou n\'importe quoi d\'autre. Aussi dès<br />\n>> l\'installation de la machine, choisir la locale en UTF-8 me parait<br />\n>> être la bonne pratique.<br />\n>> Maintenant des problèmes peuvent se poser quand on installe un<br />\n>> applicatif en utilisant plusieurs machines qui ont des encodages<br />\n>> différents (sur un même parc serveurs, des vieilles machines peuvent<br />\n>> être en ISO, alors que les nouvelles sont en UTF-8 ...)<br />\n>><br />\n>> => donc il est certain que si tu as la possibilité de redéfinir ta<br />\n>> locale c\'est sans doute mieux ... mais si d\'autres applicatifs<br />\n>> tournent sur cette machine, ca risque forcément de tout casser ... :-S<br />\n>><br />\n>> Vincent.<br />\n>><br />\n>><br />\n>> Vincent Bonamy wrote:</p></blockquote>\n<blockquote class=\"emailFilter_Author_2\"><p>>>> Bonjour Lucie,<br />\n>>><br />\n>>> Je ne suis sûr de rien dans ces questions d\'encodage [c\'est de toute<br />\n>>> manière toujours un vrai casse-tête quand ça ne fonctionne pas ...],<br />\n>>> mais le -Dfile.encoding du CATALINA_OPTS devrait surcharger ta<br />\n>>> locale je pense dans le contexte d\'exécution du Tomcat [enfin ...<br />\n>>> peut-être !] ...<br />\n>>> Aussi à trop vouloir forcer l\'encodage, on arrive parfois à coder<br />\n>>> des codes UTF-8 eux-mêmes en UTF-8 par exemple (!).<br />\n>>> Ce que je veux dire c\'est qu\'on se retrouve avec plus de problèmes<br />\n>>> que si on avait laissé les choses par défaut ...<br />\n>>> => En bref, je te conseillerai de voir ce que cela fait (pour tests,<br />\n>>> notamment si tu penses avoir tout vérifié dans le sens ISO-> UTF-8)<br />\n>>> si tu laisses par exemple l\'encodage par défaut de MySQL en ISO<br />\n>>> [latin] (sachant que ce n\'est pas parcequ\'il stocke en ISO qu\'il ne<br />\n>>> va pas répondre en UTF-8 (!!) [car il peut réencoder les caractères<br />\n>>> à la volée également peut-être ...]) .<br />\n>>><br />\n>>> Maintenant je dis peut-être plein de bêtises (on en arrive à tout<br />\n>>> remettre en cause avec les pbs d\'encodage ...) et si quelqu\'un en<br />\n>>> sait plus ou a tout simplement un avis/piste sur la question, qu\'il<br />\n>>> n\'hésite pas à intervenir !<br />\n>>><br />\n>>> A bientôt, merci de nous tenir informés,<br />\n>>> Vincent.<br />\n>>><br />\n>>><br />\n>>> Lucie Dengreville wrote:</p></blockquote>\n<blockquote class=\"emailFilter_Author_3\"><p>>>>> J\'ai ma locale en fr_FR (LANG=fr_FR ..) sur mon serveur linux,<br />\n>>>> faut-il mieux que je change celà en utf8 ?<br />\n>>>><br />\n>>>> Lucie Dengreville a écrit :</p></blockquote>\n<blockquote class=\"emailFilter_Author_4\"><p>>>>>> Ma base de données est en MyIsam mais mes tables sont bien en<br />\n>>>>> InnoDB, avec un encodage utf8_general_ci. Est-ce que celà pourrait<br />\n>>>>> provoquer cette erreur ?<br />\n>>>>> ce problème se produit même avec un formulaire pour les documents<br />\n>>>>> dc, que je n\'ai celui-ci pas modifié.<br />\n>>>>> mes tomcat ont bien CATALINA_OPTS=\"-Dfile.encoding=UTF-8<br />\n>>>>><br />\n>>>>> Pour les xforms utilisés, l\'encodage n\'est pas défini dans les<br />\n>>>>> fichiers main-form.xhtml et content-forms.xml.<br />\n>>>>> Le fichier xml généré par un formulaire dans le module editor est<br />\n>>>>> bien complet.<br />\n>>>>><br />\n>>>>> Voici un exemple du xml créé au niveau de la base de données, il<br />\n>>>>> semble bien encodé en utf-8 :<br />\n>>>>><br />\n>>>>> <?xml version=\"1.0\" encoding=\"UTF-8\"?><lom:lom<br />\n>>>>> xmlns:lom=\"http://ltsc.ieee.org/xsd/LOM\"<br />\n>>>>> xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"<br />\n>>>>> xsi:schemaLocation=\"http://ltsc.ieee.org/xsd/LOM<br />\n>>>>> http://ltsc.ieee.org/xsd/lomv1.0/lom.xsd\"><br />\n>>>>><br />\n>>>>> <lom:general><br />\n>>>>> <lom:identifier><br />\n>>>>> <lom:catalog>URI</lom:catalog><br />\n>>>>><br />\n>>>>> <lom:entry>http://orioai-1.uhb.fr/uid/uhb-ori-wf-1-null</lom:entry><br />\n>>>>> </lom:identifier><br />\n>>>>> <lom:title><br />\n>>>>> <lom:string language=\"fr\">toto</lom:string><br />\n>>>>> </lom:title><br />\n>>>>> <lom:language>fr</lom:language> <lom:description><br />\n>>>>> <lom:string language=\"fr\">tutu</lom:string><br />\n>>>>> </lom:description><br />\n>>>>> <lom:keyword><br />\n>>>>> <lom:string language=\"fr\">informatique</lom:string><br />\n>>>>> </lom:keyword><br />\n>>>>> <lom:aggregationLevel><br />\n>>>>> <lom:source>LOMv1.0</lom:source><br />\n>>>>> <lom:value>1</lom:value><br />\n>>>>> </lom:aggregationLevel><br />\n>>>>> </lom:general><br />\n>>>>> <lom:lifeCycle><br />\n>>>>> <lom:contribute><br />\n>>>>> <lom:role><br />\n>>>>> <lom:source>LOMv1.0</lom:source><br />\n>>>>> <lom:value>author</lom:value><br />\n>>>>> </lom:role><br />\n>>>>> <lom:entity><br />\n>>>>> BEGIN:VCARD<br />\n>>>>> VERSION:3.0<br />\n>>>>> N:Afa;Ma<br />\n>>>>> FN:Ma Afa<br />\n>>>>> ORG:Universit<br />\n>>>>><br />\n>>>>><br />\n>>>>><br />\n>>>>><br />\n>>>>><br />\n>>>>><br />\n>>>>><br />\n>>>>> Vincent Bonamy a écrit :</p></blockquote>\n<blockquote class=\"emailFilter_Author_5\"><p>>>>>>> Je reviens sur ce problème :<br />\n>>>>>> Ce n\'est qu\'avec un nouveau formulaire que cela se produit ?<br />\n>>>>>> Quel est l\'encodage des fichiers XForms/XML édités voir créés<br />\n>>>>>> pour réaliser ce formulaire ?<br />\n>>>>>> => sous linux file -i peut par exemple permettre de voir quel<br />\n>>>>>> encodage est utilisé.<br />\n>>>>>> Vincent.<br />\n>>>>>><br />\n>>>>>><br />\n>>>>>> Vincent Bonamy wrote:</p></blockquote>\n<blockquote class=\"emailFilter_Author_6\"><p>>>>>>>> Bonjour Lucie,<br />\n>>>>>>> Tu utilise MySQL (InnoDB) avec une base de données sous quel<br />\n>>>>>>> encodage ?<br />\n>>>>>>> L\'encodage par défaut sous MySQL est le latin suédois, as-tu<br />\n>>>>>>> opté pour l\'UTF-8 ?<br />\n>>>>>>> Peut-être également qu\'il y a un problème d\'encodage à un autre<br />\n>>>>>>> niveau ? Le charset par défaut du tomcat du module de<br />\n>>>>>>> vocabulaires ? Le fichier de vocabulaires des VCards ?<br />\n>>>>>>> Le conseil que l\'on donne est d\'essayer de faire du full UTF-8<br />\n>>>>>>> au maximum et à tous les niveaux (pour s\'en assurer, ce n\'est<br />\n>>>>>>> pas forcément évident).<br />\n>>>>>>> Vincent.<br />\n>>>>>>><br />\n>>>>>>><br />\n>>>>>>> Lucie Dengreville wrote:</p></blockquote>\n<blockquote class=\"emailFilter_Author_7\"><p>>>>>>>>> Bonjour,<br />\n>>>>>>>><br />\n>>>>>>>> Lorsque j\'enregistre un nouveau formulaire dans le module<br />\n>>>>>>>> workflow, la fiche stockée dans la table ORI_WORKLFOW_INSTANCE<br />\n>>>>>>>> au niveau du champs xmlContent n\'est pas complète : apparemment<br />\n>>>>>>>> elle s\'arrête lorsqu\'elle rencontre un caractère accentué : par<br />\n>>>>>>>> exemple au niveau d\'une vcards, la fiche fini par ORG:<br />\n>>>>>>>> Universit lorsque je mets Université dans la vcards au niveau<br />\n>>>>>>>> du fichier ldapVocabulary.xml du module de vocabulaire. Si<br />\n>>>>>>>> j\'enlève l\'accent, la fiche est enregistrée dans le workflow<br />\n>>>>>>>> s\'arrête plus loin, à un autre accent.<br />\n>>>>>>>><br />\n>>>>>>>> Comment faire pour résoudre ce problème ?<br />\n>>>>>>>><br />\n>>>>>>>> Lucie<br />\n>>>>>>>></p></blockquote>\n<blockquote class=\"emailFilter_Author_6\"><p>>>>>>>></p></blockquote>\n<blockquote class=\"emailFilter_Author_5\"><p>>>>>>><br />\n>>>>>></p></blockquote>\n<blockquote class=\"emailFilter_Author_4\"><p>>>>>><br />\n>>>>></p></blockquote>\n<blockquote class=\"emailFilter_Author_3\"><p>>>>><br />\n>>>></p></blockquote>\n<blockquote class=\"emailFilter_Author_2\"><p>>>></p></blockquote>\n<blockquote class=\"emailFilter_Author_1\"><p>>><br />\n>></p></blockquote>\n<blockquote class=\"emailFilter_Author_0\"><p>><br />\n></div>\n</blockquote>\n<p>--<br />\n----------------------------------<br />\nLucie Dengreville<br />\nCentre de Ressources Informatiques<br />\nUniversité Rennes 2 Haute Bretagne<br />\n02.99.14.13.66<br />\n-----------------------------------</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 = 1507745742, expire = 1507832142, headers = '', serialized = 0 WHERE cid = '4:09ae01a4ccc12b4e22d0ba55aae66a90' in /home/ori-oai/drupal/drupal-6.34/includes/cache.inc on line 112.
9 messages / 0 nouveaux
Sujet clos
Dernière contribution
12 juin 2008 - 5:03pm
#1
luciedengreville
workflow : fiche xml non complète
Bonjour,

Lorsque j'enregistre un nouveau formulaire dans le module workflow, la
fiche stockée dans la table ORI_WORKLFOW_INSTANCE au niveau du champs
xmlContent n'est pas complète : apparemment elle s'arrête lorsqu'elle
rencontre un caractère accentué : par exemple au niveau d'une vcards, la
fiche fini par ORG: Universit lorsque je mets Université dans la vcards
au niveau du fichier ldapVocabulary.xml du module de vocabulaire. Si
j'enlève l'accent, la fiche est enregistrée dans le workflow s'arrête
plus loin, à un autre accent.

Comment faire pour résoudre ce problème ?

Lucie

--
----------------------------------
Lucie Dengreville
Centre de Ressources Informatiques
Université Rennes 2 Haute Bretagne
02.99.14.13.66
-----------------------------------

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

Haut
Étiquettes:
12 juin 2008 - 5:16pm
#2
vincentbonamy
Bonjour Lucie,
Tu utilise MySQL (InnoDB) avec une base de données sous quel encodage ?
L'encodage par défaut sous MySQL est le latin suédois, as-tu opté pour
l'UTF-8 ?
Peut-être également qu'il y a un problème d'encodage à un autre niveau ?
Le charset par défaut du tomcat du module de vocabulaires ? Le fichier
de vocabulaires des VCards ?
Le conseil que l'on donne est d'essayer de faire du full UTF-8 au
maximum et à tous les niveaux (pour s'en assurer, ce n'est pas forcément
évident).
Vincent.

Lucie Dengreville wrote:

> Bonjour,
>
> Lorsque j'enregistre un nouveau formulaire dans le module workflow, la
> fiche stockée dans la table ORI_WORKLFOW_INSTANCE au niveau du champs
> xmlContent n'est pas complète : apparemment elle s'arrête lorsqu'elle
> rencontre un caractère accentué : par exemple au niveau d'une vcards,
> la fiche fini par ORG: Universit lorsque je mets Université dans la
> vcards au niveau du fichier ldapVocabulary.xml du module de
> vocabulaire. Si j'enlève l'accent, la fiche est enregistrée dans le
> workflow s'arrête plus loin, à un autre accent.
>
> Comment faire pour résoudre ce problème ?
>
> Lucie
>

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

Haut
12 juin 2008 - 5:28pm
(Répondre à #2) #3
vincentbonamy
Je reviens sur ce problème :
Ce n'est qu'avec un nouveau formulaire que cela se produit ?
Quel est l'encodage des fichiers XForms/XML édités voir créés pour
réaliser ce formulaire ?
=> sous linux file -i peut par exemple permettre de voir quel encodage
est utilisé.
Vincent.

Vincent Bonamy wrote:

> Bonjour Lucie,
> Tu utilise MySQL (InnoDB) avec une base de données sous quel encodage ?
> L'encodage par défaut sous MySQL est le latin suédois, as-tu opté pour
> l'UTF-8 ?
> Peut-être également qu'il y a un problème d'encodage à un autre niveau
> ? Le charset par défaut du tomcat du module de vocabulaires ? Le
> fichier de vocabulaires des VCards ?
> Le conseil que l'on donne est d'essayer de faire du full UTF-8 au
> maximum et à tous les niveaux (pour s'en assurer, ce n'est pas
> forcément évident).
> Vincent.
>
>
> Lucie Dengreville wrote:

>> Bonjour,
>>
>> Lorsque j'enregistre un nouveau formulaire dans le module workflow,
>> la fiche stockée dans la table ORI_WORKLFOW_INSTANCE au niveau du
>> champs xmlContent n'est pas complète : apparemment elle s'arrête
>> lorsqu'elle rencontre un caractère accentué : par exemple au niveau
>> d'une vcards, la fiche fini par ORG: Universit lorsque je mets
>> Université dans la vcards au niveau du fichier ldapVocabulary.xml du
>> module de vocabulaire. Si j'enlève l'accent, la fiche est enregistrée
>> dans le workflow s'arrête plus loin, à un autre accent.
>>
>> Comment faire pour résoudre ce problème ?
>>
>> Lucie
>>

>

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

Haut
13 juin 2008 - 1:14pm
(Répondre à #3) #4
luciedengreville
Ma base de données est en MyIsam mais mes tables sont bien en InnoDB,
avec un encodage utf8_general_ci. Est-ce que celà pourrait provoquer
cette erreur ?
ce problème se produit même avec un formulaire pour les documents dc,
que je n'ai celui-ci pas modifié.
mes tomcat ont bien CATALINA_OPTS="-Dfile.encoding=UTF-8

Pour les xforms utilisés, l'encodage n'est pas défini dans les fichiers
main-form.xhtml et content-forms.xml.
Le fichier xml généré par un formulaire dans le module editor est bien
complet.

Voici un exemple du xml créé au niveau de la base de données, il semble
bien encodé en utf-8 :

xmlns:lom="http://ltsc.ieee.org/xsd/LOM"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://ltsc.ieee.org/xsd/LOM
http://ltsc.ieee.org/xsd/lomv1.0/lom.xsd">



URI

http://orioai-1.uhb.fr/uid/uhb-ori-wf-1-null


toto

fr

tutu


informatique


LOMv1.0
1





LOMv1.0
author


BEGIN:VCARD
VERSION:3.0
N:Afa;Ma
FN:Ma Afa
ORG:Universit

Vincent Bonamy a écrit :

> Je reviens sur ce problème :
> Ce n'est qu'avec un nouveau formulaire que cela se produit ?
> Quel est l'encodage des fichiers XForms/XML édités voir créés pour
> réaliser ce formulaire ?
> => sous linux file -i peut par exemple permettre de voir quel encodage
> est utilisé.
> Vincent.
>
>
> Vincent Bonamy wrote:

>> Bonjour Lucie,
>> Tu utilise MySQL (InnoDB) avec une base de données sous quel encodage ?
>> L'encodage par défaut sous MySQL est le latin suédois, as-tu opté
>> pour l'UTF-8 ?
>> Peut-être également qu'il y a un problème d'encodage à un autre
>> niveau ? Le charset par défaut du tomcat du module de vocabulaires ?
>> Le fichier de vocabulaires des VCards ?
>> Le conseil que l'on donne est d'essayer de faire du full UTF-8 au
>> maximum et à tous les niveaux (pour s'en assurer, ce n'est pas
>> forcément évident).
>> Vincent.
>>
>>
>> Lucie Dengreville wrote:

>>> Bonjour,
>>>
>>> Lorsque j'enregistre un nouveau formulaire dans le module workflow,
>>> la fiche stockée dans la table ORI_WORKLFOW_INSTANCE au niveau du
>>> champs xmlContent n'est pas complète : apparemment elle s'arrête
>>> lorsqu'elle rencontre un caractère accentué : par exemple au niveau
>>> d'une vcards, la fiche fini par ORG: Universit lorsque je mets
>>> Université dans la vcards au niveau du fichier ldapVocabulary.xml du
>>> module de vocabulaire. Si j'enlève l'accent, la fiche est
>>> enregistrée dans le workflow s'arrête plus loin, à un autre accent.
>>>
>>> Comment faire pour résoudre ce problème ?
>>>
>>> Lucie
>>>

>>

>
>

--
----------------------------------
Lucie Dengreville
Centre de Ressources Informatiques
Université Rennes 2 Haute Bretagne
02.99.14.13.66
-----------------------------------

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

Haut
13 juin 2008 - 2:37pm
(Répondre à #4) #5
luciedengreville
J'ai ma locale en fr_FR (LANG=fr_FR ..) sur mon serveur linux, faut-il
mieux que je change celà en utf8 ?

Lucie Dengreville a écrit :

> Ma base de données est en MyIsam mais mes tables sont bien en InnoDB,
> avec un encodage utf8_general_ci. Est-ce que celà pourrait provoquer
> cette erreur ?
> ce problème se produit même avec un formulaire pour les documents dc,
> que je n'ai celui-ci pas modifié.
> mes tomcat ont bien CATALINA_OPTS="-Dfile.encoding=UTF-8
>
> Pour les xforms utilisés, l'encodage n'est pas défini dans les
> fichiers main-form.xhtml et content-forms.xml.
> Le fichier xml généré par un formulaire dans le module editor est bien
> complet.
>
> Voici un exemple du xml créé au niveau de la base de données, il
> semble bien encodé en utf-8 :
>
> > xmlns:lom="http://ltsc.ieee.org/xsd/LOM"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://ltsc.ieee.org/xsd/LOM
> http://ltsc.ieee.org/xsd/lomv1.0/lom.xsd">
>
>
>
> URI
>
> http://orioai-1.uhb.fr/uid/uhb-ori-wf-1-null
>
>
> toto
>
> fr
> tutu
>
>
> informatique
>
>
> LOMv1.0
> 1
>
>
>
>
>
> LOMv1.0
> author
>
>
> BEGIN:VCARD
> VERSION:3.0
> N:Afa;Ma
> FN:Ma Afa
> ORG:Universit
>
>
>
>
>
>
>
> Vincent Bonamy a écrit :

>> Je reviens sur ce problème :
>> Ce n'est qu'avec un nouveau formulaire que cela se produit ?
>> Quel est l'encodage des fichiers XForms/XML édités voir créés pour
>> réaliser ce formulaire ?
>> => sous linux file -i peut par exemple permettre de voir quel
>> encodage est utilisé.
>> Vincent.
>>
>>
>> Vincent Bonamy wrote:

>>> Bonjour Lucie,
>>> Tu utilise MySQL (InnoDB) avec une base de données sous quel encodage ?
>>> L'encodage par défaut sous MySQL est le latin suédois, as-tu opté
>>> pour l'UTF-8 ?
>>> Peut-être également qu'il y a un problème d'encodage à un autre
>>> niveau ? Le charset par défaut du tomcat du module de vocabulaires ?
>>> Le fichier de vocabulaires des VCards ?
>>> Le conseil que l'on donne est d'essayer de faire du full UTF-8 au
>>> maximum et à tous les niveaux (pour s'en assurer, ce n'est pas
>>> forcément évident).
>>> Vincent.
>>>
>>>
>>> Lucie Dengreville wrote:

>>>> Bonjour,
>>>>
>>>> Lorsque j'enregistre un nouveau formulaire dans le module workflow,
>>>> la fiche stockée dans la table ORI_WORKLFOW_INSTANCE au niveau du
>>>> champs xmlContent n'est pas complète : apparemment elle s'arrête
>>>> lorsqu'elle rencontre un caractère accentué : par exemple au niveau
>>>> d'une vcards, la fiche fini par ORG: Universit lorsque je mets
>>>> Université dans la vcards au niveau du fichier ldapVocabulary.xml
>>>> du module de vocabulaire. Si j'enlève l'accent, la fiche est
>>>> enregistrée dans le workflow s'arrête plus loin, à un autre accent.
>>>>
>>>> Comment faire pour résoudre ce problème ?
>>>>
>>>> Lucie
>>>>

>>>

>>
>>

>
>

--
----------------------------------
Lucie Dengreville
Centre de Ressources Informatiques
Université Rennes 2 Haute Bretagne
02.99.14.13.66
-----------------------------------

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

Haut
16 juin 2008 - 2:00pm
(Répondre à #5) #6
vincentbonamy
Bonjour Lucie,

Je ne suis sûr de rien dans ces questions d'encodage [c'est de toute
manière toujours un vrai casse-tête quand ça ne fonctionne pas ...],
mais le -Dfile.encoding du CATALINA_OPTS devrait surcharger ta locale je
pense dans le contexte d'exécution du Tomcat [enfin ... peut-être !] ...
Aussi à trop vouloir forcer l'encodage, on arrive parfois à coder des
codes UTF-8 eux-mêmes en UTF-8 par exemple (!).
Ce que je veux dire c'est qu'on se retrouve avec plus de problèmes que
si on avait laissé les choses par défaut ...
=> En bref, je te conseillerai de voir ce que cela fait (pour tests,
notamment si tu penses avoir tout vérifié dans le sens ISO-> UTF-8) si
tu laisses par exemple l'encodage par défaut de MySQL en ISO [latin]
(sachant que ce n'est pas parcequ'il stocke en ISO qu'il ne va pas
répondre en UTF-8 (!!) [car il peut réencoder les caractères à la volée
également peut-être ...]) .

Maintenant je dis peut-être plein de bêtises (on en arrive à tout
remettre en cause avec les pbs d'encodage ...) et si quelqu'un en sait
plus ou a tout simplement un avis/piste sur la question, qu'il n'hésite
pas à intervenir !

A bientôt, merci de nous tenir informés,
Vincent.

Lucie Dengreville wrote:

> J'ai ma locale en fr_FR (LANG=fr_FR ..) sur mon serveur linux,
> faut-il mieux que je change celà en utf8 ?
>
> Lucie Dengreville a écrit :

>> Ma base de données est en MyIsam mais mes tables sont bien en InnoDB,
>> avec un encodage utf8_general_ci. Est-ce que celà pourrait provoquer
>> cette erreur ?
>> ce problème se produit même avec un formulaire pour les documents dc,
>> que je n'ai celui-ci pas modifié.
>> mes tomcat ont bien CATALINA_OPTS="-Dfile.encoding=UTF-8
>>
>> Pour les xforms utilisés, l'encodage n'est pas défini dans les
>> fichiers main-form.xhtml et content-forms.xml.
>> Le fichier xml généré par un formulaire dans le module editor est
>> bien complet.
>>
>> Voici un exemple du xml créé au niveau de la base de données, il
>> semble bien encodé en utf-8 :
>>
>> >> xmlns:lom="http://ltsc.ieee.org/xsd/LOM"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>> xsi:schemaLocation="http://ltsc.ieee.org/xsd/LOM
>> http://ltsc.ieee.org/xsd/lomv1.0/lom.xsd">
>>
>>
>>
>> URI
>>
>> http://orioai-1.uhb.fr/uid/uhb-ori-wf-1-null
>>
>>
>> toto
>>
>> fr
>> tutu
>>
>>
>> informatique
>>
>>
>> LOMv1.0
>> 1
>>
>>
>>
>>
>>
>> LOMv1.0
>> author
>>
>>
>> BEGIN:VCARD
>> VERSION:3.0
>> N:Afa;Ma
>> FN:Ma Afa
>> ORG:Universit
>>
>>
>>
>>
>>
>>
>>
>> Vincent Bonamy a écrit :

>>> Je reviens sur ce problème :
>>> Ce n'est qu'avec un nouveau formulaire que cela se produit ?
>>> Quel est l'encodage des fichiers XForms/XML édités voir créés pour
>>> réaliser ce formulaire ?
>>> => sous linux file -i peut par exemple permettre de voir quel
>>> encodage est utilisé.
>>> Vincent.
>>>
>>>
>>> Vincent Bonamy wrote:

>>>> Bonjour Lucie,
>>>> Tu utilise MySQL (InnoDB) avec une base de données sous quel
>>>> encodage ?
>>>> L'encodage par défaut sous MySQL est le latin suédois, as-tu opté
>>>> pour l'UTF-8 ?
>>>> Peut-être également qu'il y a un problème d'encodage à un autre
>>>> niveau ? Le charset par défaut du tomcat du module de vocabulaires
>>>> ? Le fichier de vocabulaires des VCards ?
>>>> Le conseil que l'on donne est d'essayer de faire du full UTF-8 au
>>>> maximum et à tous les niveaux (pour s'en assurer, ce n'est pas
>>>> forcément évident).
>>>> Vincent.
>>>>
>>>>
>>>> Lucie Dengreville wrote:

>>>>> Bonjour,
>>>>>
>>>>> Lorsque j'enregistre un nouveau formulaire dans le module
>>>>> workflow, la fiche stockée dans la table ORI_WORKLFOW_INSTANCE au
>>>>> niveau du champs xmlContent n'est pas complète : apparemment elle
>>>>> s'arrête lorsqu'elle rencontre un caractère accentué : par exemple
>>>>> au niveau d'une vcards, la fiche fini par ORG: Universit lorsque
>>>>> je mets Université dans la vcards au niveau du fichier
>>>>> ldapVocabulary.xml du module de vocabulaire. Si j'enlève l'accent,
>>>>> la fiche est enregistrée dans le workflow s'arrête plus loin, à un
>>>>> autre accent.
>>>>>
>>>>> Comment faire pour résoudre ce problème ?
>>>>>
>>>>> Lucie
>>>>>

>>>>

>>>
>>>

>>
>>

>
>

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

Haut
16 juin 2008 - 2:08pm
(Répondre à #6) #7
vincentbonamy
cas pas de problème d'encodage.
PS2: il est très certainement préférable d'être full UTF-8 du début à la
fin pour ORI-OAI ou n'importe quoi d'autre. Aussi dès l'installation de
la machine, choisir la locale en UTF-8 me parait être la bonne pratique.
Maintenant des problèmes peuvent se poser quand on installe un
applicatif en utilisant plusieurs machines qui ont des encodages
différents (sur un même parc serveurs, des vieilles machines peuvent
être en ISO, alors que les nouvelles sont en UTF-8 ...)

=> donc il est certain que si tu as la possibilité de redéfinir ta
locale c'est sans doute mieux ... mais si d'autres applicatifs tournent
sur cette machine, ca risque forcément de tout casser ... :-S

Vincent.

Vincent Bonamy wrote:

> Bonjour Lucie,
>
> Je ne suis sûr de rien dans ces questions d'encodage [c'est de toute
> manière toujours un vrai casse-tête quand ça ne fonctionne pas ...],
> mais le -Dfile.encoding du CATALINA_OPTS devrait surcharger ta locale
> je pense dans le contexte d'exécution du Tomcat [enfin ... peut-être
> !] ...
> Aussi à trop vouloir forcer l'encodage, on arrive parfois à coder des
> codes UTF-8 eux-mêmes en UTF-8 par exemple (!).
> Ce que je veux dire c'est qu'on se retrouve avec plus de problèmes que
> si on avait laissé les choses par défaut ...
> => En bref, je te conseillerai de voir ce que cela fait (pour tests,
> notamment si tu penses avoir tout vérifié dans le sens ISO-> UTF-8) si
> tu laisses par exemple l'encodage par défaut de MySQL en ISO [latin]
> (sachant que ce n'est pas parcequ'il stocke en ISO qu'il ne va pas
> répondre en UTF-8 (!!) [car il peut réencoder les caractères à la
> volée également peut-être ...]) .
>
> Maintenant je dis peut-être plein de bêtises (on en arrive à tout
> remettre en cause avec les pbs d'encodage ...) et si quelqu'un en sait
> plus ou a tout simplement un avis/piste sur la question, qu'il
> n'hésite pas à intervenir !
>
> A bientôt, merci de nous tenir informés,
> Vincent.
>
>
> Lucie Dengreville wrote:

>> J'ai ma locale en fr_FR (LANG=fr_FR ..) sur mon serveur linux,
>> faut-il mieux que je change celà en utf8 ?
>>
>> Lucie Dengreville a écrit :

>>> Ma base de données est en MyIsam mais mes tables sont bien en
>>> InnoDB, avec un encodage utf8_general_ci. Est-ce que celà pourrait
>>> provoquer cette erreur ?
>>> ce problème se produit même avec un formulaire pour les documents
>>> dc, que je n'ai celui-ci pas modifié.
>>> mes tomcat ont bien CATALINA_OPTS="-Dfile.encoding=UTF-8
>>>
>>> Pour les xforms utilisés, l'encodage n'est pas défini dans les
>>> fichiers main-form.xhtml et content-forms.xml.
>>> Le fichier xml généré par un formulaire dans le module editor est
>>> bien complet.
>>>
>>> Voici un exemple du xml créé au niveau de la base de données, il
>>> semble bien encodé en utf-8 :
>>>
>>> >>> xmlns:lom="http://ltsc.ieee.org/xsd/LOM"
>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>> xsi:schemaLocation="http://ltsc.ieee.org/xsd/LOM
>>> http://ltsc.ieee.org/xsd/lomv1.0/lom.xsd">
>>>
>>>
>>>
>>> URI
>>>
>>> http://orioai-1.uhb.fr/uid/uhb-ori-wf-1-null
>>>
>>>
>>> toto
>>>
>>> fr
>>> tutu
>>>
>>>
>>> informatique
>>>
>>>
>>> LOMv1.0
>>> 1
>>>
>>>
>>>
>>>
>>>
>>> LOMv1.0
>>> author
>>>
>>>
>>> BEGIN:VCARD
>>> VERSION:3.0
>>> N:Afa;Ma
>>> FN:Ma Afa
>>> ORG:Universit
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Vincent Bonamy a écrit :

>>>> Je reviens sur ce problème :
>>>> Ce n'est qu'avec un nouveau formulaire que cela se produit ?
>>>> Quel est l'encodage des fichiers XForms/XML édités voir créés pour
>>>> réaliser ce formulaire ?
>>>> => sous linux file -i peut par exemple permettre de voir quel
>>>> encodage est utilisé.
>>>> Vincent.
>>>>
>>>>
>>>> Vincent Bonamy wrote:

>>>>> Bonjour Lucie,
>>>>> Tu utilise MySQL (InnoDB) avec une base de données sous quel
>>>>> encodage ?
>>>>> L'encodage par défaut sous MySQL est le latin suédois, as-tu opté
>>>>> pour l'UTF-8 ?
>>>>> Peut-être également qu'il y a un problème d'encodage à un autre
>>>>> niveau ? Le charset par défaut du tomcat du module de vocabulaires
>>>>> ? Le fichier de vocabulaires des VCards ?
>>>>> Le conseil que l'on donne est d'essayer de faire du full UTF-8 au
>>>>> maximum et à tous les niveaux (pour s'en assurer, ce n'est pas
>>>>> forcément évident).
>>>>> Vincent.
>>>>>
>>>>>
>>>>> Lucie Dengreville wrote:

>>>>>> Bonjour,
>>>>>>
>>>>>> Lorsque j'enregistre un nouveau formulaire dans le module
>>>>>> workflow, la fiche stockée dans la table ORI_WORKLFOW_INSTANCE au
>>>>>> niveau du champs xmlContent n'est pas complète : apparemment elle
>>>>>> s'arrête lorsqu'elle rencontre un caractère accentué : par
>>>>>> exemple au niveau d'une vcards, la fiche fini par ORG: Universit
>>>>>> lorsque je mets Université dans la vcards au niveau du fichier
>>>>>> ldapVocabulary.xml du module de vocabulaire. Si j'enlève
>>>>>> l'accent, la fiche est enregistrée dans le workflow s'arrête plus
>>>>>> loin, à un autre accent.
>>>>>>
>>>>>> Comment faire pour résoudre ce problème ?
>>>>>>
>>>>>> Lucie
>>>>>>

>>>>>

>>>>
>>>>

>>>
>>>

>>
>>

>

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

Haut
16 juin 2008 - 4:43pm
(Répondre à #7) #8
luciedengreville
j'ai mis ma locale en utf-8, j'ai tout recommencé en refaisant des
checkout depuis les repositories pour les modules indexing, vocabulary,
editor et workflow.Comme je faisais des scp depuis mon poste vers le
serveur, je me disais que ça pouvait venir des fichiers transféré, du
coup j'ai aussi mis mon encodage eclipse en utf-8.
Malheureusement mon problème n'est toujours pas résolu, et je ne vois
pas d'où ça peut venir.
apparemment le fichier xml transmis par l'éditeur a l'air correct car
dans la base de données du workflow le titre est correctement renseigné
même s'il existe des accents : dans ce cas le fichier xml dans la base
s'arrête dès le titre.
j'avais déjà réussi à enregistrer des fiches (contenant des accents)
avec la configuration du workflow par défaut.
C'est en configurant le workflow, l'éditeur et le vocabulaire avec le
workflow de rennes 2 que le problème est survenu (la création de
formulaire en passant par l'éditeur ne posait pas de problème, les
fiches étaient complètes).
En reprenant tout depuis le svn , donc avec la configuration par
défaut, j'ai toujours le problème..

lucie

Vincent Bonamy a écrit :

> PS: sur UNIT la base MYSQL est en ISO, à Rennes1 en UTF-8. Dans les 2
> cas pas de problème d'encodage.
> PS2: il est très certainement préférable d'être full UTF-8 du début à
> la fin pour ORI-OAI ou n'importe quoi d'autre. Aussi dès
> l'installation de la machine, choisir la locale en UTF-8 me parait
> être la bonne pratique.
> Maintenant des problèmes peuvent se poser quand on installe un
> applicatif en utilisant plusieurs machines qui ont des encodages
> différents (sur un même parc serveurs, des vieilles machines peuvent
> être en ISO, alors que les nouvelles sont en UTF-8 ...)
>
> => donc il est certain que si tu as la possibilité de redéfinir ta
> locale c'est sans doute mieux ... mais si d'autres applicatifs
> tournent sur cette machine, ca risque forcément de tout casser ... :-S
>
> Vincent.
>
>
> Vincent Bonamy wrote:

>> Bonjour Lucie,
>>
>> Je ne suis sûr de rien dans ces questions d'encodage [c'est de toute
>> manière toujours un vrai casse-tête quand ça ne fonctionne pas ...],
>> mais le -Dfile.encoding du CATALINA_OPTS devrait surcharger ta locale
>> je pense dans le contexte d'exécution du Tomcat [enfin ... peut-être
>> !] ...
>> Aussi à trop vouloir forcer l'encodage, on arrive parfois à coder des
>> codes UTF-8 eux-mêmes en UTF-8 par exemple (!).
>> Ce que je veux dire c'est qu'on se retrouve avec plus de problèmes
>> que si on avait laissé les choses par défaut ...
>> => En bref, je te conseillerai de voir ce que cela fait (pour tests,
>> notamment si tu penses avoir tout vérifié dans le sens ISO-> UTF-8)
>> si tu laisses par exemple l'encodage par défaut de MySQL en ISO
>> [latin] (sachant que ce n'est pas parcequ'il stocke en ISO qu'il ne
>> va pas répondre en UTF-8 (!!) [car il peut réencoder les caractères à
>> la volée également peut-être ...]) .
>>
>> Maintenant je dis peut-être plein de bêtises (on en arrive à tout
>> remettre en cause avec les pbs d'encodage ...) et si quelqu'un en
>> sait plus ou a tout simplement un avis/piste sur la question, qu'il
>> n'hésite pas à intervenir !
>>
>> A bientôt, merci de nous tenir informés,
>> Vincent.
>>
>>
>> Lucie Dengreville wrote:

>>> J'ai ma locale en fr_FR (LANG=fr_FR ..) sur mon serveur linux,
>>> faut-il mieux que je change celà en utf8 ?
>>>
>>> Lucie Dengreville a écrit :

>>>> Ma base de données est en MyIsam mais mes tables sont bien en
>>>> InnoDB, avec un encodage utf8_general_ci. Est-ce que celà pourrait
>>>> provoquer cette erreur ?
>>>> ce problème se produit même avec un formulaire pour les documents
>>>> dc, que je n'ai celui-ci pas modifié.
>>>> mes tomcat ont bien CATALINA_OPTS="-Dfile.encoding=UTF-8
>>>>
>>>> Pour les xforms utilisés, l'encodage n'est pas défini dans les
>>>> fichiers main-form.xhtml et content-forms.xml.
>>>> Le fichier xml généré par un formulaire dans le module editor est
>>>> bien complet.
>>>>
>>>> Voici un exemple du xml créé au niveau de la base de données, il
>>>> semble bien encodé en utf-8 :
>>>>
>>>> >>>> xmlns:lom="http://ltsc.ieee.org/xsd/LOM"
>>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>>> xsi:schemaLocation="http://ltsc.ieee.org/xsd/LOM
>>>> http://ltsc.ieee.org/xsd/lomv1.0/lom.xsd">
>>>>
>>>>
>>>>
>>>> URI
>>>>
>>>> http://orioai-1.uhb.fr/uid/uhb-ori-wf-1-null
>>>>
>>>>
>>>> toto
>>>>
>>>> fr
>>>> tutu
>>>>
>>>>
>>>> informatique
>>>>
>>>>
>>>> LOMv1.0
>>>> 1
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> LOMv1.0
>>>> author
>>>>
>>>>
>>>> BEGIN:VCARD
>>>> VERSION:3.0
>>>> N:Afa;Ma
>>>> FN:Ma Afa
>>>> ORG:Universit
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Vincent Bonamy a écrit :

>>>>> Je reviens sur ce problème :
>>>>> Ce n'est qu'avec un nouveau formulaire que cela se produit ?
>>>>> Quel est l'encodage des fichiers XForms/XML édités voir créés pour
>>>>> réaliser ce formulaire ?
>>>>> => sous linux file -i peut par exemple permettre de voir quel
>>>>> encodage est utilisé.
>>>>> Vincent.
>>>>>
>>>>>
>>>>> Vincent Bonamy wrote:

>>>>>> Bonjour Lucie,
>>>>>> Tu utilise MySQL (InnoDB) avec une base de données sous quel
>>>>>> encodage ?
>>>>>> L'encodage par défaut sous MySQL est le latin suédois, as-tu opté
>>>>>> pour l'UTF-8 ?
>>>>>> Peut-être également qu'il y a un problème d'encodage à un autre
>>>>>> niveau ? Le charset par défaut du tomcat du module de
>>>>>> vocabulaires ? Le fichier de vocabulaires des VCards ?
>>>>>> Le conseil que l'on donne est d'essayer de faire du full UTF-8 au
>>>>>> maximum et à tous les niveaux (pour s'en assurer, ce n'est pas
>>>>>> forcément évident).
>>>>>> Vincent.
>>>>>>
>>>>>>
>>>>>> Lucie Dengreville wrote:

>>>>>>> Bonjour,
>>>>>>>
>>>>>>> Lorsque j'enregistre un nouveau formulaire dans le module
>>>>>>> workflow, la fiche stockée dans la table ORI_WORKLFOW_INSTANCE
>>>>>>> au niveau du champs xmlContent n'est pas complète : apparemment
>>>>>>> elle s'arrête lorsqu'elle rencontre un caractère accentué : par
>>>>>>> exemple au niveau d'une vcards, la fiche fini par ORG:
>>>>>>> Universit lorsque je mets Université dans la vcards au niveau du
>>>>>>> fichier ldapVocabulary.xml du module de vocabulaire. Si j'enlève
>>>>>>> l'accent, la fiche est enregistrée dans le workflow s'arrête
>>>>>>> plus loin, à un autre accent.
>>>>>>>
>>>>>>> Comment faire pour résoudre ce problème ?
>>>>>>>
>>>>>>> Lucie
>>>>>>>

>>>>>>

>>>>>
>>>>>

>>>>
>>>>

>>>
>>>

>>

>
>

--
----------------------------------
Lucie Dengreville
Centre de Ressources Informatiques
Université Rennes 2 Haute Bretagne
02.99.14.13.66
-----------------------------------

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

Haut
17 juin 2008 - 10:38am
(Répondre à #8) #9
luciedengreville
mon problème parait résolu. Il semble que ce soit un problème au niveau
de l'indexing pour lequel le chemin du répertoire indexes n'était pas
correct.
j'avais mis ma base de données en latin 1 mais celà n'avait rien changé.

merci en tout cas à Vincent pour ses réponses.

Lucie

Lucie Dengreville a écrit :

>
> j'ai mis ma locale en utf-8, j'ai tout recommencé en refaisant des
> checkout depuis les repositories pour les modules indexing,
> vocabulary, editor et workflow.Comme je faisais des scp depuis mon
> poste vers le serveur, je me disais que ça pouvait venir des fichiers
> transféré, du coup j'ai aussi mis mon encodage eclipse en utf-8.
> Malheureusement mon problème n'est toujours pas résolu, et je ne vois
> pas d'où ça peut venir.
> apparemment le fichier xml transmis par l'éditeur a l'air correct car
> dans la base de données du workflow le titre est correctement
> renseigné même s'il existe des accents : dans ce cas le fichier xml
> dans la base s'arrête dès le titre.
> j'avais déjà réussi à enregistrer des fiches (contenant des accents)
> avec la configuration du workflow par défaut.
> C'est en configurant le workflow, l'éditeur et le vocabulaire avec le
> workflow de rennes 2 que le problème est survenu (la création de
> formulaire en passant par l'éditeur ne posait pas de problème, les
> fiches étaient complètes).
> En reprenant tout depuis le svn , donc avec la configuration par
> défaut, j'ai toujours le problème..
>
> lucie
>
>
>
>
> Vincent Bonamy a écrit :

>> PS: sur UNIT la base MYSQL est en ISO, à Rennes1 en UTF-8. Dans les 2
>> cas pas de problème d'encodage.
>> PS2: il est très certainement préférable d'être full UTF-8 du début à
>> la fin pour ORI-OAI ou n'importe quoi d'autre. Aussi dès
>> l'installation de la machine, choisir la locale en UTF-8 me parait
>> être la bonne pratique.
>> Maintenant des problèmes peuvent se poser quand on installe un
>> applicatif en utilisant plusieurs machines qui ont des encodages
>> différents (sur un même parc serveurs, des vieilles machines peuvent
>> être en ISO, alors que les nouvelles sont en UTF-8 ...)
>>
>> => donc il est certain que si tu as la possibilité de redéfinir ta
>> locale c'est sans doute mieux ... mais si d'autres applicatifs
>> tournent sur cette machine, ca risque forcément de tout casser ... :-S
>>
>> Vincent.
>>
>>
>> Vincent Bonamy wrote:

>>> Bonjour Lucie,
>>>
>>> Je ne suis sûr de rien dans ces questions d'encodage [c'est de toute
>>> manière toujours un vrai casse-tête quand ça ne fonctionne pas ...],
>>> mais le -Dfile.encoding du CATALINA_OPTS devrait surcharger ta
>>> locale je pense dans le contexte d'exécution du Tomcat [enfin ...
>>> peut-être !] ...
>>> Aussi à trop vouloir forcer l'encodage, on arrive parfois à coder
>>> des codes UTF-8 eux-mêmes en UTF-8 par exemple (!).
>>> Ce que je veux dire c'est qu'on se retrouve avec plus de problèmes
>>> que si on avait laissé les choses par défaut ...
>>> => En bref, je te conseillerai de voir ce que cela fait (pour tests,
>>> notamment si tu penses avoir tout vérifié dans le sens ISO-> UTF-8)
>>> si tu laisses par exemple l'encodage par défaut de MySQL en ISO
>>> [latin] (sachant que ce n'est pas parcequ'il stocke en ISO qu'il ne
>>> va pas répondre en UTF-8 (!!) [car il peut réencoder les caractères
>>> à la volée également peut-être ...]) .
>>>
>>> Maintenant je dis peut-être plein de bêtises (on en arrive à tout
>>> remettre en cause avec les pbs d'encodage ...) et si quelqu'un en
>>> sait plus ou a tout simplement un avis/piste sur la question, qu'il
>>> n'hésite pas à intervenir !
>>>
>>> A bientôt, merci de nous tenir informés,
>>> Vincent.
>>>
>>>
>>> Lucie Dengreville wrote:

>>>> J'ai ma locale en fr_FR (LANG=fr_FR ..) sur mon serveur linux,
>>>> faut-il mieux que je change celà en utf8 ?
>>>>
>>>> Lucie Dengreville a écrit :

>>>>> Ma base de données est en MyIsam mais mes tables sont bien en
>>>>> InnoDB, avec un encodage utf8_general_ci. Est-ce que celà pourrait
>>>>> provoquer cette erreur ?
>>>>> ce problème se produit même avec un formulaire pour les documents
>>>>> dc, que je n'ai celui-ci pas modifié.
>>>>> mes tomcat ont bien CATALINA_OPTS="-Dfile.encoding=UTF-8
>>>>>
>>>>> Pour les xforms utilisés, l'encodage n'est pas défini dans les
>>>>> fichiers main-form.xhtml et content-forms.xml.
>>>>> Le fichier xml généré par un formulaire dans le module editor est
>>>>> bien complet.
>>>>>
>>>>> Voici un exemple du xml créé au niveau de la base de données, il
>>>>> semble bien encodé en utf-8 :
>>>>>
>>>>> >>>>> xmlns:lom="http://ltsc.ieee.org/xsd/LOM"
>>>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>>>> xsi:schemaLocation="http://ltsc.ieee.org/xsd/LOM
>>>>> http://ltsc.ieee.org/xsd/lomv1.0/lom.xsd">
>>>>>
>>>>>
>>>>>
>>>>> URI
>>>>>
>>>>> http://orioai-1.uhb.fr/uid/uhb-ori-wf-1-null
>>>>>
>>>>>
>>>>> toto
>>>>>
>>>>> fr
>>>>> tutu
>>>>>
>>>>>
>>>>> informatique
>>>>>
>>>>>
>>>>> LOMv1.0
>>>>> 1
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> LOMv1.0
>>>>> author
>>>>>
>>>>>
>>>>> BEGIN:VCARD
>>>>> VERSION:3.0
>>>>> N:Afa;Ma
>>>>> FN:Ma Afa
>>>>> ORG:Universit
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Vincent Bonamy a écrit :

>>>>>> Je reviens sur ce problème :
>>>>>> Ce n'est qu'avec un nouveau formulaire que cela se produit ?
>>>>>> Quel est l'encodage des fichiers XForms/XML édités voir créés
>>>>>> pour réaliser ce formulaire ?
>>>>>> => sous linux file -i peut par exemple permettre de voir quel
>>>>>> encodage est utilisé.
>>>>>> Vincent.
>>>>>>
>>>>>>
>>>>>> Vincent Bonamy wrote:

>>>>>>> Bonjour Lucie,
>>>>>>> Tu utilise MySQL (InnoDB) avec une base de données sous quel
>>>>>>> encodage ?
>>>>>>> L'encodage par défaut sous MySQL est le latin suédois, as-tu
>>>>>>> opté pour l'UTF-8 ?
>>>>>>> Peut-être également qu'il y a un problème d'encodage à un autre
>>>>>>> niveau ? Le charset par défaut du tomcat du module de
>>>>>>> vocabulaires ? Le fichier de vocabulaires des VCards ?
>>>>>>> Le conseil que l'on donne est d'essayer de faire du full UTF-8
>>>>>>> au maximum et à tous les niveaux (pour s'en assurer, ce n'est
>>>>>>> pas forcément évident).
>>>>>>> Vincent.
>>>>>>>
>>>>>>>
>>>>>>> Lucie Dengreville wrote:

>>>>>>>> Bonjour,
>>>>>>>>
>>>>>>>> Lorsque j'enregistre un nouveau formulaire dans le module
>>>>>>>> workflow, la fiche stockée dans la table ORI_WORKLFOW_INSTANCE
>>>>>>>> au niveau du champs xmlContent n'est pas complète : apparemment
>>>>>>>> elle s'arrête lorsqu'elle rencontre un caractère accentué : par
>>>>>>>> exemple au niveau d'une vcards, la fiche fini par ORG:
>>>>>>>> Universit lorsque je mets Université dans la vcards au niveau
>>>>>>>> du fichier ldapVocabulary.xml du module de vocabulaire. Si
>>>>>>>> j'enlève l'accent, la fiche est enregistrée dans le workflow
>>>>>>>> s'arrête plus loin, à un autre accent.
>>>>>>>>
>>>>>>>> Comment faire pour résoudre ce problème ?
>>>>>>>>
>>>>>>>> Lucie
>>>>>>>>

>>>>>>>

>>>>>>
>>>>>>

>>>>>
>>>>>

>>>>
>>>>

>>>

>>
>>

>
>

--
----------------------------------
Lucie Dengreville
Centre de Ressources Informatiques
Université Rennes 2 Haute Bretagne
02.99.14.13.66
-----------------------------------

--
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 : Pourquoi mon Repository ne veut-il pas fonctionner ??? Sujet suivant : workflow ajout archive ›