Discussion :

[causier]

Bonjour à tous.
Je cherche à créer un fichier en UTF-8.
Le code qui suit est utilisé partout sur le web et ne retourne pas d'erreur.
Le fichier est malheureusement créé au format ISO (vérifié avec PSPAD et avec un utilitaire spécifique).

Merci pour votre aide

Je travaille sous Eclipse (Helios) avec le jdk 1.6.

File fichier = new File( "toto.txt" );
BufferedWriter fileWriter = new BufferedWriter(new OutputStreamWriter(new FileOutputStream(fichier), "UTF-8"));
fileWriter.write( "test" );

[tchize_]

Avec ce que tu écrit dans le fichier, le contenu "biniare" du fichier sera exactement le même, que tu utilise de l'UTF-8 ou de l'iso-8859-1, l'utf-8 et l'iso-8859-1 ont tous les deux été conçus pour que les caractère ascii (7 bits) soient codés tels quels.
Tu ne verra la différence que si tu écrit des caractère accentués, des symboles comme €, du cyrillique, du grec, etc.

[causier]

En effet mais ce n'est qu'un texte exemple.
Le fichier définitif contiendra des caractères différentiateurs.
Le fichier est généré pour un prestataire qui impose le format UTF-8.
Il faut donc que j'y arrive...

[JeitEmgie]

Bonjour à tous.
Je cherche à créer un fichier en UTF-8.
Le code qui suit est utilisé partout sur le web et ne retourne pas d'erreur.
Le fichier est malheureusement créé au format ISO (vérifié avec PSPAD et avec un utilitaire spécifique).

Merci pour votre aide

Je travaille sous Eclipse (Helios) avec le jdk 1.6.

File fichier = new File( "toto.txt" );
BufferedWriter fileWriter = new BufferedWriter(new OutputStreamWriter(new FileOutputStream(fichier), "UTF-8"));
fileWriter.write( "test" );

Votre méthodologie de vérification est tout simplement erronée : les logiciels d'édition de texte se contentent d'annoncer le premier encoding compatible avec le contenu qu'ils lisent et en cas d'ambiguïté ils donnent priorité à l'encoding par défaut de la plate-forme.

Pour forcer un "bête" éditeur de texte à vous annoncer "UTF-8" au lieu de n'importe quel autre encoding qui serait par hasard compatible avec le contenu, vous devez d'abord écrire le BOM UTF-8 en tête du fichier, soit la séquence de bytes : 0xEF,0xBB,0xBF.

Avec çà, même si le contenu est du pur ASCII, l'éditeur de texte (pour peu qu'il ne soit pas trop "bête" et reconnaisse les BOM UTF) va dire "UTF-8" et comme vous spécifiez "UTF-8" dans le BufferedWriter, le jour où il y aura de vrais caractères non ASCII dans le stream, ils seront bien encodés en UTF-8 et il n'y aura pas de problème.

[thelvin]

Pour forcer un "bête" éditeur de texte à vous annoncer "UTF-8" au lieu de n'importe quel autre encoding qui serait par hasard compatible avec le contenu, vous devez d'abord écrire le BOM UTF-8 en tête du fichier, soit la séquence de bytes : 0xEF,0xBB,0xBF.

Ce qui est la même chose qu'insérer le caractère U+FEFF, ce qui est tout de même plus simple :

Code :

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

1
2
3
4
5
6
public static final char BOM = 0xFEFF;
 
// ...
 
fileWriter.write(BOM);
fileWriter.write("test en été");

[tchize_]

ce n'est pas recommandé de mettre un BOM dans de l'utf-8, ca n'a jamais été sa raison d'être

[tchize_]

même si ça marche ici:

Code :

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

public static final char BOM = 0xFEFF;

est une mauvaise pratique pour définir des char. Les char de java ne sont pas 100% utf-16 Pour utiliser une valeur unicode il faut faire

Code :

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

public static final char BOM = '\ufeff';

[thelvin]

ce n'est pas recommandé de mettre un BOM dans de l'utf-8, ca n'a jamais été sa raison d'être

Euh, par qui -_-°*?

En ce qui me concerne je n'aime pas mettre ce machin stupide au début de mes fichiers, mais ce ne sont pas les technologies à préférer (ou exiger) qu'il soit là qui manquent.

Mais on s'éloigne du sujet. Mettre le BOM, ici, sert juste à faire dire à l'éditeur de texte que le fichier est en UTF-8, par ce que s'il n'est pas là, l'éditeur de texte décide unilatéralement que c'est du iso-8859-1. Ceci quel que soit l'encodage réél du fichier.
L'éditeur de texte n'est pas capable de détecter l'encodage du fichier, c'est tout. Pour lui faire dire que c'est du utf-8, il faut lui mettre un BOM. Mais on s'en fout de lui faire dire ça, ce qu'on veut, c'est que ce soit vraiment un fichier en utf-8.

Et pour ça, la méthode

Code :

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

BufferedWriter fileWriter = new BufferedWriter(new OutputStreamWriter(new FileOutputStream(fichier), "UTF-8"));

était la bonne.

[thelvin]

même si ça marche ici:

Code :

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

public static final char BOM = 0xFEFF;

est une mauvaise pratique pour définir des char. Les char de java ne sont pas 100% utf-16 Pour utiliser une valeur unicode il faut faire

Code :

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

public static final char BOM = '\ufeff';

? Quelle importance, quelle différence ?

[tchize_]

le BOM, dans le stéandard unicode, sert à indiquer l'ordre des octets dans l'encodage, utf-8 est indépendant de cet ordre, le BOM ne sert en pratique à rien pour l'UTF-8 et le standard ne l'oblige ni ne le recommande pour l'utf-8.

De plus, par exemple, le BOM pose des problèmes avec le shebang, pour la concaténation brute de fichiers, avec les codes source php, etc


pour la notation, comme je l'ai dit, les char java, ce n'est pas de l'utf-16. Bien que la grande majorité des int Oxzzzz aient les même bits que le char \uzzzz correspondant, ce n'est pas le cas de tous. Il vaut donc mieux préférer prendre l'habitude pour faire des séquences unicode la notation \uxxxx

[causier]

Merci à tous pour vos précieux renseignements.
J'ai demandé au prestataire de ma valider le fichier complet.

Le contenu est bien codé en UTF-8. Mon pb est donc résolu.

C'est donc la classe java qui omet de renseigner le BOM.

[thelvin]

C'est donc la classe java qui omet de renseigner le BOM.

? Personne n'omet rien du tout.
Déjà, comme discuté au-dessus, la légitimité de mettre un BOM est hautement discutable.
Ensuite, même si tu veux en mettre un, Java est bien obligé de tenir compte des gens qui ne veulent pas de ce truc. Par conséquent, si tu le veux, tu le mets toi-même, c'est normal.

le BOM, dans le stéandard unicode, sert à indiquer l'ordre des octets dans l'encodage, utf-8 est indépendant de cet ordre, le BOM ne sert en pratique à rien pour l'UTF-8 et le standard ne l'oblige ni ne le recommande pour l'utf-8.

Unicode n'est jamais qu'une manière de digitaliser les scripts d'écriture humaine. Il y a une limite à ce qu'ils ont légitimité à recommander ou pas. En général, c'est plutôt l'état de l'art qui recommande ou non.

De plus, par exemple, le BOM pose des problèmes avec le shebang, pour la concaténation brute de fichiers, avec les codes source php, etc

C'est un prêté pour un rendu nous sommes d'accord. Et personnellement, je suis plutôt de l'avis de ne pas mettre de BOM. Mais ce n'est pas une raison pour passer l'autre côté sous silence.

pour la notation, comme je l'ai dit, les char java, ce n'est pas de l'utf-16. Bien que la grande majorité des int Oxzzzz aient les même bits que le char \uzzzz correspondant, ce n'est pas le cas de tous. Il vaut donc mieux préférer prendre l'habitude pour faire des séquences unicode la notation \uxxxx

? Un contre-exemple dans l'intervalle 0x0 - 0xFFFF ?

La JSTL JLS dit-elle explicitement que la conversion int <-> char repose sur autre chose que considérer que le int est le code point unicode du char ?

[tchize_]

effectivement, je viens relire la JLS, c'est les valeurs supérieures à \uffff donc non représentables par un seul char qui posent problème uniquement, dans ma mémoire il avaient bidouillé aussi deux trois trucs dans le range inférieur, mais ma mémorie doit être défaillante

[JeitEmgie]

"Use of a BOM is neither required nor recommended for UTF-8, but may be encountered in contexts where UTF-8 data is converted from other encoding forms that use a BOM or where the BOM is used as a UTF-8 signature"

Dans le cas présent, mettre les 3 bytes en tête du fichier, avait pour premier intérêt de démontrer que se baser sur ce que prétend un éditeur de texte basique n'a aucune valeur de "preuve" quant à l'encoding du fichier quand ces 3 bytes ne sont pas là. (et quand ils sont là, ce n'est qu'une "annonce", encore faut-il que les séquences de bytes >0x7F respectent la norme UTF-8…)

Par contre, l'intérêt de les mettre ou non dans les fichiers générés en "production", dépendra uniquement du work flow qui manipulera les fichiers par la suite : soit les mettre apportera quelque chose en permettant d'améliorer un traitement grâce à ce critère univoque simple, soit au contraire il provoquera des problèmes de compatibilité car certains logiciels en aval ne seront pas compatibles avec ce "BOM" (improprement nommé pour l'UTF-8 soit, mais c'est ainsi qu'on le trouve nommé un peu partout - y compris dans le texte du standard - même si c'est un abus de langage…) : l'utiliser ou non, c'est donc principalement une question de contexte et d'utilité ou non.

En général, si les fichiers de sortie peuvent aller n'importe où… on omet le BOM UTF-8, ça évite les problèmes avec les logiciels "simplistes" ou "vieillots" (et avec leurs utilisateurs).
Et comme le dit tchize, de nombreux langages de programmation et d'outils shell n'apprécient pas trop, voire pas du tout, le BOM dans leurs fichiers sources.
(Mais l'utilitaire "file" reconnaît parfaitement un tel fichier texte et affiche : "UTF-8 Unicode (with BOM) text"… )