Discussion :

[tintin72]

Bonjour,

J'aimerais avoir confirmation sur un point au sujet
de la création de fichiers encodés en UTF8 avec fopen
et fwrite.

Je sais que le sujet a été mainte fois évoqué mais c'est
tellement embrouillé et complexe qu'un petit éclaircissement
ne serait pas de trop. J'ai souvent lu par exemple qu'il fallait ajouter
l'option b (binary) a fopen mais apparemment ça ne fonctionne pas.

Ce que je cherche à faire c'est que mon script php puisse créé des fichiers txt encodés en UTF8. J'ai donc fais le test suivant:

Code :

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

1
2
3
4
5
6
7
8
9
10
<?php
 
$file = 'fichier.txt';
$str = 'éàè';
 
$f = fopen($file, 'w');
fwrite($f, $str);
fclose($f);
 
?>

J'ai tout d'abord encodé le fichier contenant ce script en latin-1 (iso-8859, je
travail avec Vim).
Après avoir lancé le script, le fichier créé (fichier.txt) pèse 3 octets.
C'est donc qu'il est encodé en iso-8859.
Puis j'ai encodé le fichier contenant le script en UTF8, et là le fichier
créé pèse maintenant 6 octets. Il est donc encodé en UTF8.

D'où ma conclusion qui est que l'encodage d'un fichier lors de sa création
avec fopen ou fwrite dépends de l'encodage du fichier contenant le script, et
pas d'une option de fopen.

Est ce que j'ai bon ?


Merci pour vos éclaircissements.

[julp]

Oui. Sinon, si le script (il contient en dur les données à écrire) est lui-même encodé dans un encodage X et qu'on désire avoir ces données dans le fichier dans l'encodage Y, il faudra les convertir (utf8_[en|de]code ou plus large avec des extensions comme iconv, mbstring, etc).

Par contre, à la lecture de celui-ci, il faudra bien prendre en compte son encodage et le convertir si nécessaire car ne serait pas adapté à nos besoins.

C'est potentiellement plus compliqué, car les "entrées/sorties" PHP n'utilisent pas forcément toutes un même encodage (le script lui-même, "stdout" elle-même - éventuellement dépendant d'une déclaration, extensions particulières (DOM, SimpleXML, XML[Reader|Writer], etc)).

Cependant, un fichier n'a aucun encodage associé : cette information n'est pas stockée (indirectement via un BOM pour certains) et il n'y a aucun contrôle, on pourrait très bien écrire des données d'encodages différents (mode append par exemple).

L'option b c'est pour s'assurer que les caractères de fin de ligne (\n) ne sont pas traduits.

[tintin72]

Merci pour ces informations.

Oui, à la base un fichier vide ou ne contenant que des caractères ASCII sera lu exactement pareil en iso ou en utf8, on peut donc dire qu'il n'a pas d'encodage bien défini.
Le seul moyen d'être explicite dans ce cas est d'utiliser le BOM,
(mais il est fortement déconseillé de le faire en ce qui nous concerne).

C'est dès que l'on utilise des accents que le bazar commence.
Le distingo est très subtil et on s'emmêle vite les pinceaux.

Aussi, si quelqu'un a d'autres remarques éclairantes à ce sujet qu'il n'hésite
pas elles seront les bienvenues.