Il me semblait que sous Windows UTF-16 était pas mal utilisé aussi.Citation:
Envoyé par mchk0123
Et que l'UTF-8 sous Windows est souvent un UTF-8 spécial avec un "BOM" au début.
C'est à dire?Citation:
Envoyé par mchk0123
Version imprimable
Il me semblait que sous Windows UTF-16 était pas mal utilisé aussi.Citation:
Envoyé par mchk0123
Et que l'UTF-8 sous Windows est souvent un UTF-8 spécial avec un "BOM" au début.
C'est à dire?Citation:
Envoyé par mchk0123
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.Citation:
Envoyé par corrector
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...Citation:
Envoyé par corrector
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).
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.Citation:
Envoyé par Médinoc
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.Citation:
Envoyé par corrector
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.Citation:
Envoyé par Médinoc
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.
Le BOM n'est pas du tout obligatoire !Citation:
Envoyé par corrector
Ben si : FF FECitation:
Envoyé par corrector
FauxCitation:
Envoyé par corrector
Il peut y en avoir (EF BB BF) mais c'est inutile et génant sous unixCitation:
Envoyé par corrector
FAQ sur le BOM du Consorsium Unicode => http://unicode.org/faq/utf_bom.html#BOM
Citation:
Envoyé par corrector
Citation:
Envoyé par vicenzo
Citation:
Envoyé par corrector
Citation:
Envoyé par vicenzo
C'est à la fin :Citation:
Envoyé par vicenzo
Citation:
Envoyé par Q: How I should deal with BOMs?, A/4.
Citation:
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 ...
Citation:
Envoyé par corrector
Citation:
Envoyé par vicenzo
Désolé, mais il va falloir me montrer une référence normative pour me convaincre (une FAQ n'est pas normative).Citation:
Envoyé par unicode.org, Byte Order Mark (BOM) FAQ
Ok, sort moi tes référence normatives pour les déclarations que tu as posté :Citation:
Envoyé par corrector
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 !
- 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.
Alors, tes références ?
voici les spécifications Unicode 5.0 au sujet du BOM :
Citation:
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
Supposons qu'il puisse ne pas y en avoir.Citation:
Envoyé par vicenzo
Dis-moi alors comment un programme est censé interpréter de l'UTF-16 sans BOM : en UTF-16BE ou en UTF-16LE?
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.
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?Citation:
Envoyé par vicenzo
Où ai-je dis ca ????Citation:
Envoyé par corrector
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.
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.
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
Nul part en effet.Citation:
Envoyé par vicenzo
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).Citation:
Envoyé par vicenzo
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.)
En fait, plus j'y pense, plus je penche du côté de corrector pour ce point...
A un moment, mon argument logique repose sur le fait que "la donnée D est au format F" permet d'interpréter D (d'écrire un programme qui décode D). A partir de là, on prouve la disjonction mentionnée ci-dessus, l'absence de BOM en UTF-8, le caractère non-optionnel du BOM dans tous les cas.Citation:
Envoyé par Médinoc
Peut-être que tout le désaccord et les difficultés de communication viennent de là.
(Je peux aussi justifier certaines choses sur la base de la norme, mais ça m'intéresse moins.)
Je suis d'accord sur le fait que quand on sait hors-bande qu'un texte est en UTF-8, il n'y a pas de BOM.
Mais dans un texte dont on ignore le type, une "BOM UTF-8" peut signaler en-bande que la suite du texte est en UTF-8...
Edit au sujet du message #23: En effet, ce message saisit parfaitement ma pensée.
Je résume (tu m'arrêtes si je comprends de travers ce que tu voulais dire) : tu as un fichier, c'est de l'UTF-8, ça peut être indiqué à des programmes "hors-bande", mais certains programmes ne savent pas que c'est de l'UTF-8 (ils n'ont pas de canal hors-bande adéquat), donc on met une BOM comme "magic-number" pour identifier le format ("en-bande").Citation:
Envoyé par Médinoc
Donc ces derniers programmes voient une "BOM UTF-8", passent en mode UTF-8, et continuent à lire.
Les autres, qui ont déjà l'information hors-bande, commencent à lire en UTF-8 depuis le début du fichier (puisque la BOM n'est pas obligatoire en UTF-8), décodent les séquences à commencer par celle qui code la BOM, qui est alors considérée comme de l'UTF-8, pas annonçant de l'UTF-8, donc il décode un ZWNBSP, puis le reste du fichier comme précédemment. Tandis que les autres programmes, qui ne savaient pas que c'était de l'UTF-8 n'ont décodé que le reste du fichier. Il y a un caractère (ou code-point) en trop.
Mais ce n'est pas juste un artéfact comme les diacritiques combinant vs. les formes pré-combinées : on peut normaliser, qu'on passe en NFC, NFD, NFKC, NFKD, le ZWNBSP sera toujours là et heureusement parce qu'il a une sémantique, il ne fait pas juste de la figuration, ni du remplissage (sauf quand c'est une BOM, mais un ZWNBSP n'est jamais une BOM puisque l'un est un code-point, l'autre n'est... rien du tout, c'est comme les torchons et les serviettes, faut pas mélanger).
On sent une note de regret...Citation:
Envoyé par Unicode 5.0
En bref, ça risque d'être le bordel.Citation:
Envoyé par Unicode 5.0
Ils sont honnêtes au moins.Citation:
Envoyé par Unicode 5.0
Maintenant, ils essaient de réparer leur erreur.Citation:
Envoyé par Unicode 5.0
Ben oui, mais on ne peut pas remonter le temps.Citation:
Envoyé par Unicode 5.0
En fait, je suis d'accord sur le fond avec eux.