Discussion :

[corrector]

Surement de l'UTF8, c'est le plus répandu et le plus utilisé.

Il me semblait que sous Windows UTF-16 était pas mal utilisé aussi.

Et que l'UTF-8 sous Windows est souvent un UTF-8 spécial avec un "BOM" au début.

Et vu que le fichier texte est en clair

C'est à dire?

[Vincent Rogier]

Il me semblait que sous Windows UTF-16 était pas mal utilisé aussi.

Windows NT gère les string nativement en UTF16... mis cela n'a rien a voir avec la facon d'enregistrer un fichier car ce sont les applications qui écrivent les fichiers et donc décident de l'encodage.

Et que l'UTF-8 sous Windows est souvent un UTF-8 spécial avec un "BOM" au début.

Non ! le BOM n'a rien a voir avec Windows directement. Ce sont les applis encore une fois qui décident d'incorporer un BOM... Ce que fait par exemple par défaut notepad sous vista si l'encodage n'est pas ANSI... et ce qu'il ne faisait pas avant...

[Médinoc]

Sauf que l'extension Microsoft que j'ai donnée (ccs=UNICODE dans fopen()) a besoin de la BOM pour savoir, sauf si on met une info plus précise dans le ccs=).

Le problème du "Bush hid the facts" n'arrive jamais dans un texte contenant une BOM: Le problème, c'est justement que notepad prend le texte normal pour de l'unicode sans BOM, car beaucoup d'applications ne la mettent pas (pour certaines raisons, la BOM est même déconseillée en UTF-8 sous nux).

[corrector]

Le problème, c'est justement que notepad prend le texte normal pour de l'unicode sans BOM, car beaucoup d'applications ne la mettent pas (pour certaines raisons, la BOM est même déconseillée en UTF-8 sous nux).

Justement, par définition, je ne vois pas comment on peut mettre un BOM en UTF-8. Tout ce qu'on peut faire, c'est mettre un ZWNBSP au début du fichier.

[Médinoc]

Justement, par définition, je ne vois pas comment on peut mettre un BOM en UTF-8. Tout ce qu'on peut faire, c'est mettre un ZWNBSP au début du fichier.

Ben oui, c'est peut-être un abus de langage, mais on même en UTF-8, on appelle ça une BOM, même si en UTF-8 les bytes sont par définition toujours dans le même ordre.

[corrector]

Ben oui, c'est peut-être un abus de langage, mais on même en UTF-8, on appelle ça une BOM, même si en UTF-8 les bytes sont par définition toujours dans le même ordre.

La question n'est pas si on a besoin de connaitre l'ordre des octets ou pas. Ce n'est pas un problème de besoins, mais de définitions.

En UTF16, il y a un BOM, par définition.

En UTF16LE, il n'y en a pas, par définition.

Si un fichier est en UTF16, mais que tu l'as écrit toi même et que tu sais pertinemment comment tu l'as écrit (mettons, en little-endian), il n'est pas de l'UTF16LE pour autant. C'est toujours de l'UTF16, et il y a un BOM, qu'on en ai besoin ou pas.

En UTF8 il n'y a pas de BOM, pas parce qu'on en pas besoin, mais par définition.

Dire qu'il y a un BOM en UTF8 n'est pas un "abus de langage", c'est tout simplement une contradiction.

[Vincent Rogier]

En UTF16, il y a un BOM, par définition.

Le BOM n'est pas du tout obligatoire !

En UTF16LE, il n'y en a pas, par définition.

Ben si : FF FE

Si un fichier est en UTF16, mais que tu l'as écrit toi même et que tu sais pertinemment comment tu l'as écrit (mettons, en little-endian), il n'est pas de l'UTF16LE pour autant. C'est toujours de l'UTF16, et il y a un BOM, qu'on en ai besoin ou pas.

Faux

En UTF8 il n'y a pas de BOM, pas parce qu'on en pas besoin, mais par définition.

Il peut y en avoir (EF BB BF) mais c'est inutile et génant sous unix


FAQ sur le BOM du Consorsium Unicode => http://unicode.org/faq/utf_bom.html#BOM

[corrector]

En UTF16LE, il n'y en a pas [de BOM], par définition.

Ben si : FF FE

Si un fichier est en UTF16, mais que tu l'as écrit toi même et que tu sais pertinemment comment tu l'as écrit (mettons, en little-endian), il n'est pas de l'UTF16LE pour autant. C'est toujours de l'UTF16, et il y a un BOM, qu'on en ai besoin ou pas.

Faux

FAQ sur le BOM du Consorsium Unicode => http://unicode.org/faq/utf_bom.html#BOM

C'est à la fin :

Where the precise type of the data stream is known (e.g. Unicode big-endian or Unicode little-endian), the BOM should not be used. In particular, whenever a data stream is declared to be UTF-16BE, UTF-16LE, UTF-32BE or UTF-32LE a BOM must not be used.

[Vincent Rogier]

Where the precise type of the data stream is known

Pour Corrector :

Dans ce cas oui, si tu maitrises la chaine de la création du fichier à sa relecture, ce qui reste un cas particulier.

En gros, cette réponse indique de ne pas utiliser les BOM quand tu n'en a pas besoin ! Rien de plus !

Pour finir, je ne vois pas le lien entre cette citation et le topic du post ...

[corrector]

En UTF8 il n'y a pas de BOM, pas parce qu'on en pas besoin, mais par définition.

Il peut y en avoir (EF BB BF) mais c'est inutile et génant sous unix

FAQ sur le BOM du Consorsium Unicode => http://unicode.org/faq/utf_bom.html#BOM

Q: When a BOM is used, is it only in 16-bit Unicode text?

A: No, a BOM can be used as a signature no matter how the Unicode text is transformed: UTF-16, UTF-8, UTF-7, etc.

Désolé, mais il va falloir me montrer une référence normative pour me convaincre (une FAQ n'est pas normative).

[Vincent Rogier]

Désolé, mais il va falloir me montrer une référence normative pour me convaincre (une FAQ n'est pas normative).

Ok, sort moi tes référence normatives pour les déclarations que tu as posté :

• En UTF16, il y a un BOM, par définition.
• En UTF16LE, il n'y en a pas [de BOM], par définition.
• En UTF8 il n'y a pas de BOM, pas parce qu'on en pas besoin, mais par définition.

Si tu veux vraiment ergoter et apporter des références, crée une discussion sur le sujet, comme ca on ne polluera ce post, car là ça s'écarte du sujet initial !

[Vincent Rogier]

Alors, tes références ?

voici les spécifications Unicode 5.0 au sujet du BOM :

Byte Order Mark (BOM): U+FEFF

For historical reasons, the character U+FEFF used for the byte order mark is named zero
width no-break space. Except for compatibility with versions of Unicode prior to Version
3.2, U+FEFF is not used with the semantics of zero width no-break space (see
Section 16.2, Layout Controls). Instead, its most common and most important usage is in
the following two circumstances:

1. Unmarked Byte Order. Some machine architectures use the so-called bigendian
byte order, while others use the little-endian byte order. When Unicode
text is serialized into bytes, the bytes can go in either order, depending on the
architecture. Sometimes this byte order is not externally marked, which causes
problems in interchange between different systems.

2. Unmarked Character Set. In some circumstances, the character set information
for a stream of coded characters (such as a file) is not available. The only information
available is that the stream contains text, but the precise character set is
not known.

In these two cases, the character U+FEFF is used as a signature to indicate the byte order
and the character set by using the byte serializations described in Section 3.10, Unicode
Encoding Schemes. Because the byte-swapped version U+FFFE is a noncharacter, when an
interpreting process finds U+FFFE as the first character, it signals either that the process
has encountered text that is of the incorrect byte order or that the file is not valid Unicode
text.

In the UTF-16 encoding scheme, U+FEFF at the very beginning of a file or stream explicitly
signals the byte order.

The byte sequences <FE16 FF16> or <FF16 FE16> may also serve as a signature to identify a
file as containing UTF-16 text. Either sequence is exceedingly rare at the outset of text files
using other character encodings, whether single- or multiple-byte, and therefore not
likely to be confused with real text data. For example, in systems that employ ISO Latin-1
(ISO/IEC 8859-1) or the Microsoft Windows ANSI Code Page 1252, the byte sequence
<FE16 FF16> constitutes the string <thorn, y diaeresis> “þÿ”; in systems that employ the
Apple Macintosh Roman character set or the Adobe Standard Encoding, this sequence represents the
sequence <ogonek, hacek> “¤«”; in systems that employ other common IBM
PC code pages (for example, CP 437, 850), this sequence represents <black square, no-break
space> “† ”.

In UTF-8, the BOM corresponds to the byte sequence <EF16 BB16 BF16>. Although there
are never any questions of byte order with UTF-8 text, this sequence can serve as signature
for UTF-8 encoded text where the character set is unmarked. As with a BOM in UTF-16,
this sequence of bytes will be extremely rare at the beginning of text files in other character
encodings. For example, in systems that employ Microsoft Windows ANSI Code Page 1252,
<EF16 BB16 BF16> corresponds to the sequence <i diaeresis, guillemet, inverted question
mark> “ï » ¿”.

For compatibility with versions of the Unicode Standard prior to Version 3.2, the code
point U+FEFF has the word-joining semantics of zero width no-break space when it is not
used as a BOM. In new text, these semantics should be encoded by U+2060 word joiner.
See “Line and Word Breaking” in Section 16.2, Layout Controls, for more information.
Where the byte order is explicitly specified, such as in UTF-16BE or UTF-16LE, then all
U+FEFF characters—even at the very beginning of the text—are to be interpreted as zero
width no-break spaces. Similarly, where Unicode text has known byte order, initial U+FEFF
characters are not required, but for backward compatibility are to be interpreted as zero
width no-break spaces. For example, for strings in an API, the memory architecture of the
processor provides the explicit byte order. For databases and similar structures, it is much
more efficient and robust to use a uniform byte order for the same field (if not the entire
database), thereby avoiding use of the byte order mark.
Systems that use the byte order mark must recognize when an initial U+FEFF signals the
byte order. In those cases, it is not part of the textual content and should be removed before
processing, because otherwise it may be mistaken for a legitimate zero width no-break space.
To represent an initial U+FEFF zero width no-break space in a UTF-16 file, use
U+FEFF twice in a row. The first one is a byte order mark; the second one is the initial zero
width no-break space. See Table 16-4 for a summary of encoding scheme signatures.

Table 16-4. Unicode Encoding Scheme Signatures
Encoding Scheme Signature
UTF-8 EF BB BF
UTF-16 Big-endian FE FF
UTF-16 Little-endian FF FE
UTF-32 Big-endian 00 00 FE FF
UTF-32 Little-endian FF FE 00 00

If U+FEFF had only the semantics of a signature code point, it could be freely deleted from
text without affecting the interpretation of the rest of the text. Carelessly appending files
together, for example, can result in a signature code point in the middle of text. Unfortunately,
U+FEFF also has significance as a character. As a zero width no-break space, it indicates
that line breaks are not allowed between the adjoining characters. Thus U+FEFF
affects the interpretation of text and cannot be freely deleted. The overloading of semantics
for this code point has caused problems for programs and protocols. The new character
U+2060 word joiner has the same semantics in all cases as U+FEFF, except that it cannot
be used as a signature. Implementers are strongly encouraged to use word joiner in those
circumstances whenever word joining semantics are intended.

An initial U+FEFF also takes a characteristic form in other charsets designed for Unicode
text. (The term “charset” refers to a wide range of text encodings, including encoding
schemes as well as compression schemes and text-specific transformation formats.) The
characteristic sequences of bytes associated with an initial U+FEFF can serve as signatures
in those cases, as shown in Table 16-5.

Table 16-5. U+FEFF Signature in Other Charsets
Charset Signature

SCSU 0E FE FF
BOCU-1 FB EE 28
UTF-7 2B 2F 76 38 or
2B 2F 76 39 or
2B 2F 76 2B or
2B 2F 76 2F
UTF-EBCDIC DD 73 66 73

Most signatures can be deleted either before or after conversion of an input stream into a
Unicode encoding form. However, in the case of BOCU-1 and UTF-7, the input byte
sequence must be converted before the initial U+FEFF can be deleted, because stripping
the signature byte sequence without conversion destroys context necessary for the correct
interpretation of subsequent bytes in the input sequence.


Copyright © 1991-2007, Unicode, Inc. The Unicode Standard 5.0 – Electronic edition

[corrector]

Ok, sort moi tes référence normatives pour les déclarations que tu as posté :

• En UTF16, il y a un BOM, par définition.

Supposons qu'il puisse ne pas y en avoir.

Dis-moi alors comment un programme est censé interpréter de l'UTF-16 sans BOM : en UTF-16BE ou en UTF-16LE?

[Vincent Rogier]

C'est justement l'interêt du BOM !!!

Mais, le BOM n'est pas obligatoire dans un flux UTF16.

Comme dis précédemment, si la chaine est maitrisée (création du flux, lecture du flux), il n'est pas nécessaire.

Le BOM est intéressant pour avoir une interopérabilité entre applis mais n'est pas un pré-requis de la norme Unicode pour encoder un flux UTF-xx.

[corrector]

Mais, le BOM n'est pas obligatoire dans un flux UTF16.

Comme dis précédemment, si la chaine est maitrisée (création du flux, lecture du flux), il n'est pas nécessaire.

Justement, si une donnée est produite et consommée entièrement en interne, que c'est de l'"UTF16", qu'on n'utilise pas de BOM parce qu'un sait très bien quel ordre d'octets on a utilisé, alors pourquoi dis-tu qu'elle n'est pas soit en UTF-16LE, soit en UTF-16BE?

[Vincent Rogier]

Jalors pourquoi dis-tu qu'elle n'est pas soit en UTF-16LE, soit en UTF-16BE?

Où ai-je dis ca ????

La seule chose que je te dis depuis le début de ce topic, c'est que le BOM est une fonctionnalité optionnelle et non obligatoire prévue par la norme Unicode pour détecter le type d'encodage d'un flux Unicode.

[Médinoc]

vicenzo: Tu sembles ne pas réaliser que pour corrector, UTF-16 n'est pas l'union de UTF-16 LE et UTF-16 BE, mais un ensemble disjoint:

• UTF-16 LE: On sait "hors-bande" que l'ordre est little-endian.
• UTF-16 BE: On sait "hors-bande" que l'ordre est big-endian.
• UTF-16: Aucune info hors-bande, l'ordre est en tête du texte dans la BOM.

Je ne dirais pas lequel des deux a raison car j'en sais f***** rien.

[Vincent Rogier]

J'ai bien compris la "disjointure" en question...

corrector a affirmé que le BOM était présent "par définition" en UTF16 et pas présent "par définition" en UTF16-LE

J'ai seulement rappelé que le BOM est "par définition" optionnel, quelque soit l'encodage (UTF -XX LE ou BE) .

C'est tout !

Depuis, le topic part en sucette

[corrector]

Où ai-je dis ca ????

Nul part en effet.

La seule chose que je te dis depuis le début de ce topic, c'est que le BOM est une fonctionnalité optionnelle et non obligatoire prévue par la norme Unicode pour détecter le type d'encodage d'un flux Unicode.

En tant que données UTF-16, ce sont des données illisibles. On ne peut les lire qu'en tant qu'UTF-16xx (LE ou BE).

Alors, dire que le format est UTF-16, c'est un peu comme dire que le format est "des octets les uns après les autres". C'est vrai dans un sens, mais on ne peut rien en faire.

(Je dis ceci pour les besoins de l'argument - je n'admets pas quoi que ce soit.)

[Médinoc]

En fait, plus j'y pense, plus je penche du côté de corrector pour ce point...