Discussion :

[sebcarrera]

Bonjour à tous,

j'utilise l'outil odtphp afin de remplir des formulaires .odt rapidement via un formulaire écrit en PHP.

Mon problème c'est que je n'arrive pas à récupérer les caractères spéciaux convenablement. Par exemple le mot "Accès" donnera "Accès"

J'utilise cette version d'odtphp disponible sur sourceforge https://sourceforge.net/projects/odt.../odtPHP%201.0/

Pour illustrer mon soucis vous pouvez utiliser le tutoriel6 du pack

voici ce que j'ai comme résultat:

[Watilin]

Bonsoir,
cette image que tu montres, c’est un rendu dans un navigateur ?

[sebcarrera]

Non c'est le rendu de mon .odt

[Watilin]

Je n’ai pas trouvé de documentation (à part une version archivée), on dirait que le site de ODTPHP est mort… C’est jamais bon signe.
On va rester optimistes et supposer qu’il y a un support de différents encodages. Tu dois trouver, d’une manière ou d’une autre, comment configurer ça.

Tout ce que je peux te dire pour l’instant, c’est que la séquence « é » (octets C3, A9) apparaît quand un texte a été encodé en UTF-8 mais interprété selon un encodage à un seul octet (par exemple Windows-1252 ou ISO-8859-1).

Un .odt est écrit en XML. L’encodage d’un fichier XML est presque toujours UTF-8, et d’ailleurs je n’ai rien trouvé dans les specs OpenDocument qui permette de préciser un autre encodage.

Je vais faire une hypothèse : les séquences UTF-8 sont double-encodées, autrement dit le « Ã » et le « © » sont chacun représentés par leur séquences respectives. Je te propose d’ouvrir le .odt avec un éditeur de texte (pas traitement de texte, plutôt le genre pour coder). Le « Ã » peut être représenté en XML par les entités suivantes :

• Ã
• Ã
• Ã

Fais une recherche pour voir si ces entités, ou le « Ã » non échappé, se trouvent dans le code XML. Si c’est le cas, cela confirmera mon hypothèse du double encodage.

Sinon, ça veut dire que le XML est interprété selon un encodage à un octet, et il faudra alors trouver comment, notamment en examinant les métadonnées du document.

[sebcarrera]

Bonjour Watilin,

oui au niveau de la doc c'est mort depuis quelques années j'ai l'impression. C'est dommage c'est un super outil et le seul que j'ai trouvé capable de me créer des fichiers .odt via un formulaire.

J'ai regardé le .xml du fichier .odt et du coup ça serait plutôt ta seconde hypothèse.
Ci-joint le fameux .odt qui a été généré si tu veux y jeter un œil.

e60ffa4e0cc8ec1588b14e28b98b42bc.odt

[sebcarrera]

Au niveau du code de la fonction permettant de remplir mes balises j'ai trouvé ça:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
 /**
     * Assign a template variable to replace
     *
     * @param string $key
     * @param string $value
     * @throws SegmentException
     * @return Segment
     */
    public function setVars($key, $value, $encode = true, $charset = 'ISO-8859') {
        if (strpos($this->xml, $this->odf->getConfig('DELIMITER_LEFT') . $key . $this->odf->getConfig('DELIMITER_RIGHT')) === false) {
            throw new SegmentException("var $key not found in {$this->getName()}");
        }
        $value = $encode ? htmlspecialchars($value) : $value;
        $value = ($charset == 'ISO-8859') ? utf8_encode($value) : $value;
        $this->vars[$this->odf->getConfig('DELIMITER_LEFT') . $key . $this->odf->getConfig('DELIMITER_RIGHT')] = str_replace("\n", "<text:line-break/>", $value);
        return $this;
    }

[Watilin]

J’avais oublié une info importante : il faut dézipper le .odt avant de pouvoir accéder aux .xml dont il est composé. En examinant contents.xml, j’ai trouvé des séquences « é » alors que mon éditeur de texte indique clairement que le fichier est encodé en UTF-8. Ça confirme ma première hypothèse.

Quant à cette fonction setVars, elle contient une instruction utf8_encode($value). Je soupçonne que c’est la source du problème. Essaye de spécifier 'UTF-8' à chaque fois que tu y fais appel, et reviens me dire si ça donne quelque chose d’intéressant.

Edit : étant donné qu’il faut obligatoirement fournir l’argument $encode avec $charset, je te conseille de toujours passer false. En effet, $encode cause un appel à htmlspecialchars, et cette fonction utilise également un encodage en interne. Il vaut mieux que tu appelles toi-même htmlspecialchars si tu en as besoin, en lui passant les bons arguments.

Voici un exemple d’appel à setVars :

Code PHP :

Sélectionner tout - Visualiser dans une fenêtre à part

$odf->setVars('titre', 'Quelques articles de l’encyclopédie Wikipédia', false, 'UTF-8');

[sebcarrera]

Re!
Alors ça a fonctionné effectivement en changeant dans la définition de la fonction setvars le charset en 'UTF-8'. Par contre si je mets False le document généré est corrompu.

public function setVars($key, $value, $encode = true, $charset = 'ISO-8859'

Merci en tout cas ça fonctionne avec ce changement

[Watilin]

Par contre si je mets False le document généré est corrompu.

Pardon, je n’ai pas été assez clair.

Il vaut mieux que tu appelles toi-même htmlspecialchars si tu en as besoin, en lui passant les bons arguments.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
$titre = htmlentities('Quelques articles de l’encyclopédie Wikipédia', ENT_QUOTES | ENT_SUBSTITUTE | ENT_XML1, 'UTF-8');
$odf->setVars('titre', $title, false, 'UTF-8');

La doc : htmlentities.