Codage fin de ligne

Paul Gaborit

22/05/2007 à 14:40

À (at) Tue, 15 May 2007 11:48:52 +0200,
(Bernd) écrivait (wrote):

Le client que j'utilise pour le codage des pages html me propose
lors de l'enregistrement de chaque page les options:
- unicode,
- Mac,
- windows,
- Unix.

À votre place, je changerais de "client"... Aucune des options
proposées ne correspond à un codage. Unicode est un jeu de caractères
(qu'on peut coder de différentes manière dont, entre autres, l'UTF8 ou
le HTML). Mac est un ordinateur qui supporte plusieurs OS qui
utilisent (par défaut) plusieurs codages (MacRoman, UTF8,
ISO-8859-*). Windows utilise au moins deux grandes familles de codages
différents (DOS et Windows) et dans ces familles, il y a plusieurs
sous-familles. Quant à Unix, il utilisait traditionnellement l'ASCII
ou l'EBCDIC (plus rare) puis toutes les variantes de ISO-8859 et
enfin, plus récemment, l'UTF8 mais sait aussi en utiliser d'autres.

Y-a t'il une précaution à utiliser l'une ou l'autre sachant que les
pages doivent sans doute être lues par tous les environnements
possibles ?

La précaution à prendre est de choisir un codage correspondant à celui
qu'enverra peut-être le serveur HTTP qui diffusera ces pages.

Après, l'HTML est suffisament bien conçu pour qu'on puisse tout écrire
avec le codage ASCII qui est commun à presque tous les codages (sauf
l'EBCDIC).

--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>

Pierre Goiffon

23/05/2007 à 09:35

Paul Gaborit wrote:

Le client que j'utilise pour le codage des pages html me propose
lors de l'enregistrement de chaque page les options:
- unicode,
- Mac,
- windows,
- Unix.

À votre place, je changerais de "client"... Aucune des options
proposées ne correspond à un codage.

Enormément d'éditeurs adoptent des raccourcis pas très heureux. Unicode
par exemple est très employé pour UTF-16 (généralement LE), sur les
Windows occidentaux on a aussi Windows ou EOM pour Windows-1252, etc...

Là ce qui semble assez étrange c'est que visiblement on mélange le saut
de ligne avec le codage, ce qui ne devrait pas avoir de rapport ! Il
serait intéressant de voir ce que la documentation du produit en dit...

Après, l'HTML est suffisament bien conçu pour qu'on puisse tout écrire
avec le codage ASCII qui est commun à presque tous les codages (sauf
l'EBCDIC).

IBM avait créé Ebcdic et c'est le plus connu des "concurrents" à Ascii,
mais il y a aussi une kyrielle de codages propres à certaines
plateformes plus ou moins exotiques et pas du tout basés sur Ascii !

ASM

23/05/2007 à 10:41

Pierre Goiffon a écrit :

Paul Gaborit wrote:
Le client que j'utilise pour le codage des pages html me propose
lors de l'enregistrement de chaque page les options:
- unicode,
- Mac,
- windows,
- Unix.

À votre place, je changerais de "client"... Aucune des options
proposées ne correspond à un codage.

(...)

Là ce qui semble assez étrange c'est que visiblement on mélange le saut
de ligne avec le codage, ce qui ne devrait pas avoir de rapport ! Il
serait intéressant de voir ce que la documentation du produit en dit...

Heu ... cet éditeur n'est pas limité au html ... il peut aussi traiter
toute une kirielle de langages (php, laText, et de programmation)

Il n'y a pas à lire la doc, il y a 2 fonctionnements :
- 1 dédié aux plateformes (on peut choisir : Mac, Dos, Unix)
- 1 dédié à l'unicode
plus possibilité d'option des charsets pour n'importe quel choix ci-dessus.
Le problème étant qu'on peu pré-gerer le nombre de ces options : ne
laisser que les 3 ou 4 charsets principaux ou aller jusqu'à la totalité
des charsets connus.
On peut, peut-être, déplorer que le logiciel permette à la fois d'avoir
'unicode' *et* 'plate-formes' ? Il suffit néanmoins de cocher 'unicode'
et 'utf-8' par exemple pour se libérer des soucis de retour chariot
(avec la conséquence d'un fichier plus lourd).

Après, l'HTML est suffisament bien conçu pour qu'on puisse tout écrire
avec le codage ASCII qui est commun à presque tous les codages (sauf
l'EBCDIC).

Je n'ai jamais vu un brouteur râler à propos d'un retour-chariot mal
fagoté (ils digèrent très bien les 3 options/modes de retour)

Sinon, normalement le logiciel BBEdit est suffisamment intelligent pour
avertir si on utilise des caratères non connus du charset utilisé (ie:
ISO-8859-1).
On se sert alors de la palette de toutes les entités-html pour remplacer
ceux-ci.

--
Stephane Moriaux et son (moins) vieux Mac déjà dépassé

Pierre Goiffon

23/05/2007 à 12:10

ASM wrote:

Le client que j'utilise pour le codage des pages html me propose
lors de l'enregistrement de chaque page les options:
- unicode,
- Mac,
- windows,
- Unix.

À votre place, je changerais de "client"... Aucune des options
proposées ne correspond à un codage.

(...)
Là ce qui semble assez étrange c'est que visiblement on mélange le
saut de ligne avec le codage, ce qui ne devrait pas avoir de rapport !

Il n'y a pas à lire la doc, il y a 2 fonctionnements :
- 1 dédié aux plateformes (on peut choisir : Mac, Dos, Unix)
- 1 dédié à l'unicode
plus possibilité d'option des charsets pour n'importe quel choix ci-dessus.

Stéphane, aurais tu lu de travers ? Il serait en effet logique que l'on
ait un groupe d'options dédié aux sauts de ligne, et un autre au codage.

Moi à la simple vue de ces options je comprend Mac/Windows/Unix comme
les options de saut de ligne, alors que Unicode à un codage (UTF-16) :
il n'y a pas de format de saut de ligne particulier à Unicode, c'est un
non sens. Maintenant on peut aussi imaginer que ces 4 options soient des
charset en plus des sauts de ligne... Mais dans ce cas, à quel codage
correspondent Mac/Windows/Unix ?

Dans tous les cas il y a confusion possible, moi ça ne me parait pas
clair et j'irai de suite lire la doc.

Paul Gaborit

23/05/2007 à 15:29

À (at) Wed, 23 May 2007 09:35:07 +0200,
Pierre Goiffon écrivait (wrote):

Enormément d'éditeurs adoptent des raccourcis pas très
heureux. Unicode par exemple est très employé pour UTF-16
(généralement LE), sur les Windows occidentaux on a aussi Windows ou
EOM pour Windows-1252, etc...

Je connais les raccourcis pris par de nombreux softs par faciliter la
compréhension... Mais ceux qui sont bien faits précisent en général la
référence exacte quelque part. Du genre :

- Unicode (UTF-8)
- Unix (ISO-8859-1)
- Windows (CP1252)
etc.

Là ce qui semble assez étrange c'est que visiblement on mélange le
saut de ligne avec le codage, ce qui ne devrait pas avoir de rapport !
Il serait intéressant de voir ce que la documentation du produit en
dit...

Effectivement les caractères LF et CR existent dans tous les codages
évoqués. Ce qui change c'est leur interprétation. Et c'est indépendant
du codage lui-même.

Après, l'HTML est suffisament bien conçu pour qu'on puisse tout écrire
avec le codage ASCII qui est commun à presque tous les codages (sauf
l'EBCDIC).

IBM avait créé Ebcdic et c'est le plus connu des "concurrents" à
Ascii, mais il y a aussi une kyrielle de codages propres à certaines
plateformes plus ou moins exotiques et pas du tout basés sur Ascii !

Certes (je me souviens même d'une machine LISP qui utilisait des
caractères codés sur 9 bits! ). Ici, je reparlais de l'EBCDIC parce
que je l'avais évoqué au début de mon message. Mais, effectivement, ma
formulation n'était pas claire et pouvait laisser croire qu'il n'y
aurait que l'EBCDIC qui n'est pas 'compatible' ASCII.

--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>

ASM

23/05/2007 à 15:38

Pierre Goiffon a écrit :

ASM wrote:
Le client que j'utilise pour le codage des pages html me propose
lors de l'enregistrement de chaque page les options:
- unicode,
- Mac,
- windows,
- Unix.

À votre place, je changerais de "client"... Aucune des options
proposées ne correspond à un codage.

(...)
Là ce qui semble assez étrange c'est que visiblement on mélange le
saut de ligne avec le codage, ce qui ne devrait pas avoir de rapport !

Il n'y a pas à lire la doc, il y a 2 fonctionnements :
- 1 dédié aux plateformes (on peut choisir : Mac, Dos, Unix)
- 1 dédié à l'unicode
plus possibilité d'option des charsets pour n'importe quel choix
ci-dessus.

Stéphane, aurais tu lu de travers ?

Sans nul doute, sans nul doute ! Je ne suis pas très attentif :-)

Renseignement complémentaire :
on ne peut choisir "unicode" si on n'a pas préalablement sélectionné
utf-8 ou utf-16 ou l'un des charsets liés à l'unicode.

Il serait en effet logique que l'on
ait un groupe d'options dédié aux sauts de ligne, et un autre au codage.

Mais ... je rapporte ce que je vois dans le soft et ... ce n'est pas
prévu comme ça ... de prime abord.
Cependant, avec un peu d'attention, on voit que les 2 choix
'unicode/plate-formes' sont bien séparés.
Néanmoins, la sélection dans l'un des mondes n'annule pas apparemment la
possibilité de sélection simultanée dans l'autre ce qui trouble la
comprenette du mécanisme.

Moi à la simple vue de ces options je comprend Mac/Windows/Unix comme
les options de saut de ligne, alors que Unicode à un codage (UTF-16) :
il n'y a pas de format de saut de ligne particulier à Unicode, c'est un
non sens.

toutafé

De là à savoir comment est bidouillé le code final du fichier ...
je ne saurais dire car je n'ai pas d'outil pour me le montrer.

Maintenant on peut aussi imaginer que ces 4 options soient des
charset en plus des sauts de ligne... Mais dans ce cas, à quel codage
correspondent Mac/Windows/Unix ?

Je subodore que ce ne sont que les différents sauts de ligne, je
subodore, je pense, je crois, il me semble ...

Tout ce que je sais est que le même fichier dans l'un ou l'autre mode
"Mac, Dos, Unix" fait exactement le même nombre d'octets.
(contrairement à l'unicode, plus volumineux)

Dans tous les cas il y a confusion possible, moi ça ne me parait pas
clair et j'irai de suite lire la doc.

La doc est en anglais :-(
(le soft aussi, mais on arrive à s'y faire)

Ha! Première fois que j'ouvre la doc (c'qui faut pas faire tt d'même!)
et je trouve ça pour ce menu d'options :
"The File pop-up menu contains commands that let you set linebreak
options, specify what state information is saved, and set
Unicode file options if applicable."

ce qui rejoint mon impression de comment ça doit/semble fonctionner,
encore que ... "let you ... *and* set unicode"

Sinon on a aussi par ailleurs :
"Convert to ASCII"
"This command will convert certain eight-bit Mac Roman characters
(characters whose decimal values are greater than 128 and less than 255)
to 7-bit (printable ASCII range) equivalents. Converted characters
include umlauted and accented vowels, ligatures, typographer's quotes,
and various specialized punctuation forms. This conversion may
entail expansion to multiple characters; for example, in the case of
ligatures."

Ainsi que toute une foultitude de possibilités à s'y perdre.

Enfin, si ça intéresse vraiment qqu'un,
le manuel (6Mo) (en pas français) est ici :
http://ftp.barebones.com/pub/manual/BBEdit_85_User_Manual.pdf
et le tuto là :
http://www.barebones.com/support/bbedit/BBEdit_Tutorial.dmg
(image disk MacOS X de 2,5Mo)

--
Stephane Moriaux et son (moins) vieux Mac déjà dépassé

Pierre Goiffon a écrit :

ASM wrote:

Le client que j'utilise pour le codage des pages html me propose
lors de l'enregistrement de chaque page les options:
- unicode,
- Mac,
- windows,
- Unix.

À votre place, je changerais de "client"... Aucune des options
proposées ne correspond à un codage.

(...)

Là ce qui semble assez étrange c'est que visiblement on mélange le
saut de ligne avec le codage, ce qui ne devrait pas avoir de rapport !

Il n'y a pas à lire la doc, il y a 2 fonctionnements :
- 1 dédié aux plateformes (on peut choisir : Mac, Dos, Unix)
- 1 dédié à l'unicode
plus possibilité d'option des charsets pour n'importe quel choix
ci-dessus.

Stéphane, aurais tu lu de travers ?

Sans nul doute, sans nul doute ! Je ne suis pas très attentif :-)

Renseignement complémentaire :
on ne peut choisir "unicode" si on n'a pas préalablement sélectionné
utf-8 ou utf-16 ou l'un des charsets liés à l'unicode.

Il serait en effet logique que l'on
ait un groupe d'options dédié aux sauts de ligne, et un autre au codage.

Mais ... je rapporte ce que je vois dans le soft et ... ce n'est pas
prévu comme ça ... de prime abord.
Cependant, avec un peu d'attention, on voit que les 2 choix
'unicode/plate-formes' sont bien séparés.
Néanmoins, la sélection dans l'un des mondes n'annule pas apparemment la
possibilité de sélection simultanée dans l'autre ce qui trouble la
comprenette du mécanisme.

Moi à la simple vue de ces options je comprend Mac/Windows/Unix comme
les options de saut de ligne, alors que Unicode à un codage (UTF-16) :
il n'y a pas de format de saut de ligne particulier à Unicode, c'est un
non sens.

toutafé

De là à savoir comment est bidouillé le code final du fichier ...
je ne saurais dire car je n'ai pas d'outil pour me le montrer.

Maintenant on peut aussi imaginer que ces 4 options soient des
charset en plus des sauts de ligne... Mais dans ce cas, à quel codage
correspondent Mac/Windows/Unix ?

Je subodore que ce ne sont que les différents sauts de ligne, je
subodore, je pense, je crois, il me semble ...

Tout ce que je sais est que le même fichier dans l'un ou l'autre mode
"Mac, Dos, Unix" fait exactement le même nombre d'octets.
(contrairement à l'unicode, plus volumineux)

Dans tous les cas il y a confusion possible, moi ça ne me parait pas
clair et j'irai de suite lire la doc.

La doc est en anglais :-(
(le soft aussi, mais on arrive à s'y faire)

Ha! Première fois que j'ouvre la doc (c'qui faut pas faire tt d'même!)
et je trouve ça pour ce menu d'options :
"The File pop-up menu contains commands that let you set linebreak
options, specify what state information is saved, and set
Unicode file options if applicable."

ce qui rejoint mon impression de comment ça doit/semble fonctionner,
encore que ... "let you ... *and* set unicode"

Sinon on a aussi par ailleurs :
"Convert to ASCII"
"This command will convert certain eight-bit Mac Roman characters
(characters whose decimal values are greater than 128 and less than 255)
to 7-bit (printable ASCII range) equivalents. Converted characters
include umlauted and accented vowels, ligatures, typographer's quotes,
and various specialized punctuation forms. This conversion may
entail expansion to multiple characters; for example, in the case of
ligatures."

Ainsi que toute une foultitude de possibilités à s'y perdre.

Enfin, si ça intéresse vraiment qqu'un,
le manuel (6Mo) (en pas français) est ici :
http://ftp.barebones.com/pub/manual/BBEdit_85_User_Manual.pdf
et le tuto là :
http://www.barebones.com/support/bbedit/BBEdit_Tutorial.dmg
(image disk MacOS X de 2,5Mo)

--
Stephane Moriaux et son (moins) vieux Mac déjà dépassé

Vous avez filtré cet utilisateur ! Consultez son message

Pierre Goiffon a écrit :

ASM wrote:
Le client que j'utilise pour le codage des pages html me propose
lors de l'enregistrement de chaque page les options:
- unicode,
- Mac,
- windows,
- Unix.

À votre place, je changerais de "client"... Aucune des options
proposées ne correspond à un codage.

(...)
Là ce qui semble assez étrange c'est que visiblement on mélange le
saut de ligne avec le codage, ce qui ne devrait pas avoir de rapport !

Il n'y a pas à lire la doc, il y a 2 fonctionnements :
- 1 dédié aux plateformes (on peut choisir : Mac, Dos, Unix)
- 1 dédié à l'unicode
plus possibilité d'option des charsets pour n'importe quel choix
ci-dessus.

Stéphane, aurais tu lu de travers ?

Sans nul doute, sans nul doute ! Je ne suis pas très attentif :-)

Renseignement complémentaire :
on ne peut choisir "unicode" si on n'a pas préalablement sélectionné
utf-8 ou utf-16 ou l'un des charsets liés à l'unicode.

Il serait en effet logique que l'on
ait un groupe d'options dédié aux sauts de ligne, et un autre au codage.

Mais ... je rapporte ce que je vois dans le soft et ... ce n'est pas
prévu comme ça ... de prime abord.
Cependant, avec un peu d'attention, on voit que les 2 choix
'unicode/plate-formes' sont bien séparés.
Néanmoins, la sélection dans l'un des mondes n'annule pas apparemment la
possibilité de sélection simultanée dans l'autre ce qui trouble la
comprenette du mécanisme.

Moi à la simple vue de ces options je comprend Mac/Windows/Unix comme
les options de saut de ligne, alors que Unicode à un codage (UTF-16) :
il n'y a pas de format de saut de ligne particulier à Unicode, c'est un
non sens.

toutafé

De là à savoir comment est bidouillé le code final du fichier ...
je ne saurais dire car je n'ai pas d'outil pour me le montrer.

Maintenant on peut aussi imaginer que ces 4 options soient des
charset en plus des sauts de ligne... Mais dans ce cas, à quel codage
correspondent Mac/Windows/Unix ?

Je subodore que ce ne sont que les différents sauts de ligne, je
subodore, je pense, je crois, il me semble ...

Tout ce que je sais est que le même fichier dans l'un ou l'autre mode
"Mac, Dos, Unix" fait exactement le même nombre d'octets.
(contrairement à l'unicode, plus volumineux)

Dans tous les cas il y a confusion possible, moi ça ne me parait pas
clair et j'irai de suite lire la doc.

La doc est en anglais :-(
(le soft aussi, mais on arrive à s'y faire)

Ha! Première fois que j'ouvre la doc (c'qui faut pas faire tt d'même!)
et je trouve ça pour ce menu d'options :
"The File pop-up menu contains commands that let you set linebreak
options, specify what state information is saved, and set
Unicode file options if applicable."

ce qui rejoint mon impression de comment ça doit/semble fonctionner,
encore que ... "let you ... *and* set unicode"

Sinon on a aussi par ailleurs :
"Convert to ASCII"
"This command will convert certain eight-bit Mac Roman characters
(characters whose decimal values are greater than 128 and less than 255)
to 7-bit (printable ASCII range) equivalents. Converted characters
include umlauted and accented vowels, ligatures, typographer's quotes,
and various specialized punctuation forms. This conversion may
entail expansion to multiple characters; for example, in the case of
ligatures."

Ainsi que toute une foultitude de possibilités à s'y perdre.

Enfin, si ça intéresse vraiment qqu'un,
le manuel (6Mo) (en pas français) est ici :
http://ftp.barebones.com/pub/manual/BBEdit_85_User_Manual.pdf
et le tuto là :
http://www.barebones.com/support/bbedit/BBEdit_Tutorial.dmg
(image disk MacOS X de 2,5Mo)

--
Stephane Moriaux et son (moins) vieux Mac déjà dépassé

Codage fin de ligne

6 réponses

Veuillez sélectionner un problème