Discussion:Indicateur d'ordre des octets

Autres discussions [liste]

Admissibilité
Neutralité
Droit d'auteur
Article de qualité
Bon article
Lumière sur
À faire
Archives
Commons

	Tâches à accomplir pour Indicateur d'ordre des octets	aide
	Votre aide est la bienvenue pour corriger les liens, présents dans l'article, vers les pages d'homonymie Flux ⇒ Quelques explications pour effectuer ces corrections. -- 3 février 2021 à 15:33 (CET) Votre aide est la bienvenue pour corriger les arguments inconnus dans les appels de modèle, présents dans l'article : Modèle {{ Ouvrage }} : l'argument « `section=Chapitre 2 - Nouveautés de Debian GNU/Linux 4.0 ↵` » ne fait pas partie des arguments gérés par le modèle {{ Ouvrage }} (dans « Histoire ») -- 9 août 2021 à 14:45 (CEST)

Tout ou partie de cet article est issu de la traduction de l'article sous licence CC-BY-SA « (en) Byte-order mark ».

Consultez l'historique de la page originale pour connaître la liste de ses auteurs.

Cela ne me semble plus être le cas, sauf peut-être pour la section «BOM dans les différents codages unicode.».

Relativement mal écrit[modifier le code]

Pourquoi tant d'italique dans cet article ? Par exemple, « Dans la plupart des codages le BOM est une séquence qui est peu vraisemblablement visible dans la plupart des codages conventionnels ou autres codages unicodes (cela ressemble usuellement à une obscure séquence de codes de contrôles). », c'est une citation, un avis personnel, le témoignage d'un petit frère, de l'écriture automatique ? Et il y a deux fois "Dans la plupart des codages".

« En unicode, une Marque d'ordre des octets [...] est un caractère unicode de code point U+FEFF ». Cette première phrase est fausse comme le démontre le premier tableau, le code du BOM change d'un UTF à l'autre, c'est même le principe si j'ai bien compris.

Le passage sur les problèmes posés au passage à l'UTF8 est un peu hasardeux. MSIE, qui réagit bien différemment d'une version à l'autre, n'est pas le seul navigateur à réagir bizarrement, . Firefox n'encaisse pas tjrs un flux XML UTF+BOM (« Erreur d'analyse XML : instruction de traitement XML ou texte pas au début d'une entité externe »). Je pense qu'il faudrait éviter de nommer des navigateurs alors qu'on ne peut pas être exhaustif, sinon, on va encore déclencher de ridicules guerres saintes…

Omettre le BOM pour le Web est un POV. On pourrait préconiser, au contraire, de toujours le servir, de développer des design qui survivent à l'apparition du BOM sous les vieux navigateurs et de proposer l'UTF-8 comme standard pour que cessent les régionalisations parasites. On pourrait aussi préconiser de toujours développer ses sites pour qu'il puisse y être servi comme ne pas l'être car c'est plus simple que d'être derrière le dos de tout ses collaborateurs.

Lacrymocéphale 9 décembre 2008 à 18:16 (CET)[répondre]

Omettre le BOM est en effet un point de vue, mais c'est un point de vue particulièrement notable, aisé à sourcer via les publications de l'i18n du W3C (exemple). --Lgd (d) 9 décembre 2008 à 19:03 (CET)[répondre]

Bogue[modifier le code]

Le navigateur Microsoft Internet Explorer basculera en affichage XML par exemple^{[réf. nécessaire]}.

Cela ne semble pas être le cas (testé avec Internet Explorer v. 6.0.2800.1106 via wine (IE4Linux)). Demanderait une démonstration (probablement dépendant de certaines versions / conditions). Comme le refnec est là depuis le 25 avril 2008, je supprime le contenu en conformité avec WP:Vérifiabilité. Calimo (d) 2 janvier 2009 à 18:23 (CET)[répondre]

au fil des éditions et suppressions des affirmations non vérifiables, le passage "bogue" a fini par disparaître. Peut-être faudrait-il créer une section spécifique pour les dysfonctionnements dus au BOM sur le web avec utf8, ce qui permettrait de décharger le paragraphe sur l'UTF8… Calimo (d) 2 janvier 2009 à 19:06 (CET)[répondre]

Bis repetitat, les bugs liés à la présence d'une BOM sont documentés par l'i18n du W3C, voir la référence donnée dans la section précédente. La présence de la BOM provoque essentiellement l'affichage de caractère type ï»¿ ou d'une ligne vide imprévue. --Lgd (d) 3 janvier 2009 à 08:43 (CET)[répondre]

Oui pour un récapitulatif des bogues que la présence ou l'absence du BOM engendre. Du moment que sur Wikipedia il n'est pas conseillé ou déconseillé de le mettre.

— En même temps voilà la batterie de tests pour faire ça sérieusement… —

T'as remanié bcp de choses, dis donc, ça a l'air pas mal.

Lacrymocéphale 4 janvier 2009 à 10:01 (CET)[répondre]

J'ai repris l'article en anglais. Il contient en particulier une référence [1] qui dit que le BOM n'est ni requis ni recommandé. J'ai également tenté de revoir un peu le plan pour avoir des paragraphes intermédiaires, en particulier un sur les problèmes liés au BOM dans UTF8 (sur le web ou ailleurs).

Pour [2] c'est une documentation de problèmes très spécifiques liés au BOM en utf8. L'utilisateur ne les rencontrera pas dans la majorité des cas. En tirer qu'il est "conseillé d'omettre le BOM" est une interprétation personelle. Le W3C dit en général les choses clairement, et s'ils devaient le déconseiller, ce serait fait plus clairement que ça, avec le terme "deprecated" ou "recommand*". J'ai cherché sur le site du W3C et leur moteur interne ne trouve que ce document pour les mots clés "BOM" et "UTF-8" ensemble. Pour moi ces deux références sont insuffisantes pour déconseiller cela. Cependant elle référence effectivement l'affirmation précédente (ï»¿ en ISO-8859-1), donc je la déplace et remets une refnec.

Je propose que cela soit reformulé de la manière suivante : « Il n'est donc pas pour le moment recommandé pour les documents UTF-8 destinés au Web » ou quelque chose du genre. À ce moment là, on aura les références pour affirmer cela (elles sont déjà dans l'article, il n'y aura qu'à les répéter).

Calimo (d) 4 janvier 2009 à 10:53 (CET)[répondre]

Les termes "deprecated" ou "recommanded" ont un usage et un sens normatif précis dans le cadre des documents du W3C, qui exclut de manière évidente leur emploi par un document émanant de celui-ci à propos du BOM.

Sinon, il n'y a pas à écrire que la présence d'un BOM serait ou non recommandée. Il y a juste à faire état des quelques points de vue notables, sous la forme « X recommande que... Y considère que... » (R. Ishida dans cet exemple, voir également chez Korpela pour rester dans les classiques). Wikipédia n'est pas un guide pratique. --Lgd (d) 4 janvier 2009 à 11:01 (CET)[répondre]

Je ne vois pas pourquoi le W3C ne pouvait faire une recommandation formelle avec les SHOULD ou les MUST qu'il faut. S'ils ne l'ont pas fait, alors ils ne déconseillent pas. Sans références, alors cela veut dire qu'il faut supprimer cette phrase… Calimo (d) 7 janvier 2009 à 09:47 (CET)[répondre]

UTF-8: Alternatives, contournements, et compatibilité...[modifier le code]

Le point le plus controversé et épineux semble être l'utilisation du BOM dans l'UTF-8.

Il reste que l'article me semble ne pas distinguer ce qui relève du développement logiciel, de ce qui est de l'utilisation d'un ordinateur et de l'expérience utilisateur.

Si l'on dit qu'il est conseillé à l'utilisateur de ne pas enregistrer un fichier sans BOM, cela veux dire qu'il est bien vu qu'un logiciel qui enregistre un fichier texte (exemple éditeur de texte) propose des fonctionnalités ou option d'ajout, de suppression ou de conservation du BOM.

De même, vu que le BOM ne peut pas facilement être vu de l'utilisateur, il est souhaitable qu'un logiciel qui lit deux fichiers dont le texte est identique traite les deux textes à l'identique. La seule modification que la présence du BOM dans un fichier devrait apporter à l'expérience de l'utilisateur est tout au plus une indication indiquant que le BOM est présent ou absent, et non un dysfonctionnement non documenté du logiciel. Dans l'idéal, la présence ou l'absence du BOM dans un fichier texte ne devrait pas avoir d'impact notable sur l'utilisateur.

C'est d'ailleurs, me semble-t-il ce que font tous les logiciels modernes et biens conçus.

Remarques sur les trois modifications de Mickaël Delahaye jusqu'au 4 septembre[modifier le code]

l'explication de sans chasse devrait intervenir à la première utilisation de l'expression
existence d'une faute d'accord sujet verbe dans l'article: «elle n'est pas reconnue par tous les logiciels et posent donc des problèmes de compatibilité.»
l'affichage de trois caractère inattendus “ ï»¿ ” en début d'une page web s'accompagnera également d'un mauvais affichage des autres caractères non-ascii.
le titre n'est pas très bon, et si le concept dont parle l'article était bien à l'origine un indicateur d'ordre des octets, à la lecture de l'article, on comprend plutôt qu'il s'agit d'un indicateur de représentation des données Unicode. On pourrait garder le titre actuel, et la formulation indicateur d'ordre des octets en introduction et là où c'est pertinent, vu qu'il s'agit d'une traduction du titre officiel, mais la traduction systématique de BOM par indicateur d'ordre des octets me semble inapproprié, du mois sous sa forme systématique. Il faudrait trouver une appellation plus parlante et moins contr'intuitive, pour utiliser dans les autre cas. Quelque chose comme «indicateur» ou «indicateur de représentation» me semblerait moins confus.
La suppression du mot toujours change le sens:
Le standard Unicode n'impose pas l'indicateur d'ordre des octets en début de flux de données Unicode, c'est le cas en particulier pour UTF-8, où l'indicateur est facultatif.

Le standard Unicode impose l'indicateur d'ordre des octets en début de flux de données Unicode, lorsqu'il s'agit de données sur 16 bits et que l'ordre des octets n'ets pas connu, me semble-t-il.
Il reste un BOM dans après traduction

⁓

Je note que cet indicateur est parfois considéré comme une marque de polarité [3]84.100.0.8 (d) 22 septembre 2012 à 12:08 (CEST)[répondre]

Phrase inexplicable[modifier le code]

« Dans la plupart des codages le BOM est une séquence qui est peu vraisemblablement visible dans la plupart des codages conventionnels ou autres codages unicodes (cela ressemble usuellement à une obscure séquence de codes de contrôles). » Cette phrase manque désespérément de clarté et répérition de "la plupart des codages" est inutile. Elle même de sens d'ailleurs: "la plupart des codages" n'ont pas tous des BOM (l'ASCII est encore très utilisé et n'a pas de BOM (mauvais exemple, je sais)). Le cas des "autres codages unicodes" est couvert par l'intro et par la section "Usages"; inutile donc de re-mentionner. Quand au "peu vraisemblablement visible" et au "essemble usuellement à...", c'est idiot je dirais: le BOM est une indication technique, nullement destinée à être vue par l'utilisateur; et s'il en vient à les voir, c'est qu'il est conscient de ce qu'il fait (généralement on y fait attention que en programmation). Les BOM, par défaut, ne sont jamais visible.

Je suggère donc la suppression de cette phrase. --Gravgun (d) 3 août 2013 à 17:47 (CEST)[répondre]

Tentative d'Explication de la phrase inexplicable[modifier le code]

En supposant qu'ici le BOM désigne un BOM UTF-8 (soit la chaîne d'octets composée des trois octets: EF BB BF).

« Dans la plupart des codages le BOM» signifie alors les séquences suivantes:

00 00 FE FF (UTF-32);
FF FE 00 00 (UTF-32) ;
FE FF (UTF-16) ;
FF FE (UTF-16) ;
EF BB BF (UTF-8)

«séquence qui est peu vraisemblablement visible dans la plupart des codages conventionnels ou autres codages unicodes» signifie qu'il est très peu probable que les séquences décrites ci dessus puisent se retrouver dans un texte quelconque, et cela quelque puisse-être la codage en octets sous-jascent aux dits caractères de ce texte. Les exceptions sont alors le je cite: «Bush hid the facts» ( http://en.inforapid.org/index.php?search=Bush%20hid%20the%20facts ).

«cela ressemble usuellement à une obscure séquence de codes de contrôles» signifie alors que cela ressemble à du mojibake, comme l'assez commun ï»¿