message : "lines ending with only a carriage..."

jz

01/02/2004 à 19:10

abitbol wrote:

Merci, j'ai trouvé une solution à mon problème.
Mais je ne comprends pas, c'est en transfert avec détection auto ou en
ASCII que les fichiers sont mal transféré avec mon client ftp(filezilla).
En revanche, ca marche si le transfert est en binaire
C'est donc le contraire?!!
Je n'ai donc pas tout compris ou ya une erreur dans ce post, mais j'ai enfin
une solution.
...

Seul le mode binaire assure l'intégrité d'un transfert ftp, et un
transfert en mode binaire n'a jamais empéché les échanges de texte.
Bien que ce soit le mode par défaut de bien des clients ftp, le
transfert "en mode ascii" est une hérésie qui ne devrait plus exister.

L'utilisation de ftp a évolué avec les réseaux, et il est de plus en
plus rare aujourd'hui de transférer des "fichiers texte purs". C'était
justifié il y a bien longtemps, quand il fallait tout passer en 7bits
pour les communications et que la compression était trop coûteuse pour
les machines de l'époque. C'est complètement ridicule aujourd'hui.

Si le codage des fins de ligne d'un fichier est différent entre deux
machines, c'est à l'éditeur de se débrouiller pour que l'affichage soit
correct (c'est vraiment facile). D'ailleurs ils le font à peu près tous
maintenant, sauf notepad, mais on ne peut quand même pas parler
décemment d'éditeur pour ce machin.

Jacques

James Kanze

01/02/2004 à 21:29

jz writes:

|> abitbol wrote:

|> > Merci, j'ai trouvé une solution à mon problème. Mais je
|> > ne comprends pas, c'est en transfert avec détection auto ou en
|> > ASCII que les fichiers sont mal transféré avec mon client
|> > ftp(filezilla). En revanche, ca marche si le transfert est en
|> > binaire C'est donc le contraire?!!

|> > Je n'ai donc pas tout compris ou ya une erreur dans ce post, mais
|> > j'ai enfin une solution. ...

|> Seul le mode binaire assure l'intégrité d'un transfert ftp, et
|> un transfert en mode binaire n'a jamais empéché les
|> échanges de texte.

Le transfert, non, mais le résultat n'est pas forcement exploitable
comme texte sur la machine qui le reçoit.

|> Bien que ce soit le mode par défaut de bien des clients ftp, le
|> transfert "en mode ascii" est une hérésie qui ne devrait plus
|> exister.

|> L'utilisation de ftp a évolué avec les réseaux, et il est
|> de plus en plus rare aujourd'hui de transférer des "fichiers
|> texte purs".

C'est vrai. Ça ne veut pas dire que la mode ASCII doit
disparaître, mais je conçois volentier qu'elle ne doit pas être
le défaut.

|> C'était justifié il y a bien longtemps, quand il fallait tout
|> passer en 7bits pour les communications et que la compression
|> était trop coûteuse pour les machines de l'époque. C'est
|> complètement ridicule aujourd'hui.

C'était surtout justifié parce que les différentes machines
utilisaient des codes de caractères différents -- mode ASCII
convertit toujours tout en Internet ASCII (y compris CRLF comme fin de
ligne, même si les deux machines soient Unix). Le problème existe
encore, même si tu ne le rencontres pas souvent.

Ceci dit, il faudrait peut-être rédéfinir ce qu'on entend par
« texte », parce qu'un fichier en ISO 8859-15 ne compte pas comme
texte pour le protocol.

|> Si le codage des fins de ligne d'un fichier est différent entre
|> deux machines, c'est à l'éditeur de se débrouiller pour que
|> l'affichage soit correct (c'est vraiment facile).

Et que faire avec les machines EBCDIC, où les
« enregistrements » définissent des lignes (pas de caractère
de fin de ligne). Il n'y a pas que Windows et Unix sur la terre.

|> D'ailleurs ils le font à peu près tous maintenant, sauf
|> notepad, mais on ne peut quand même pas parler décemment
|> d'éditeur pour ce machin.

Et quels éditeurs de texte des IBM 390 connais-tu ?

--
James Kanze mailto:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93

jz <jz@jz.jz> writes:

|> abitbol wrote:

|> > Merci, j'ai trouvé une solution à mon problème. Mais je
|> > ne comprends pas, c'est en transfert avec détection auto ou en
|> > ASCII que les fichiers sont mal transféré avec mon client
|> > ftp(filezilla). En revanche, ca marche si le transfert est en
|> > binaire C'est donc le contraire?!!

|> > Je n'ai donc pas tout compris ou ya une erreur dans ce post, mais
|> > j'ai enfin une solution. ...

|> Seul le mode binaire assure l'intégrité d'un transfert ftp, et
|> un transfert en mode binaire n'a jamais empéché les
|> échanges de texte.

Le transfert, non, mais le résultat n'est pas forcement exploitable
comme texte sur la machine qui le reçoit.

|> Bien que ce soit le mode par défaut de bien des clients ftp, le
|> transfert "en mode ascii" est une hérésie qui ne devrait plus
|> exister.

|> L'utilisation de ftp a évolué avec les réseaux, et il est
|> de plus en plus rare aujourd'hui de transférer des "fichiers
|> texte purs".

C'est vrai. Ça ne veut pas dire que la mode ASCII doit
disparaître, mais je conçois volentier qu'elle ne doit pas être
le défaut.

|> C'était justifié il y a bien longtemps, quand il fallait tout
|> passer en 7bits pour les communications et que la compression
|> était trop coûteuse pour les machines de l'époque. C'est
|> complètement ridicule aujourd'hui.

C'était surtout justifié parce que les différentes machines
utilisaient des codes de caractères différents -- mode ASCII
convertit toujours tout en Internet ASCII (y compris CRLF comme fin de
ligne, même si les deux machines soient Unix). Le problème existe
encore, même si tu ne le rencontres pas souvent.

Ceci dit, il faudrait peut-être rédéfinir ce qu'on entend par
« texte », parce qu'un fichier en ISO 8859-15 ne compte pas comme
texte pour le protocol.

|> Si le codage des fins de ligne d'un fichier est différent entre
|> deux machines, c'est à l'éditeur de se débrouiller pour que
|> l'affichage soit correct (c'est vraiment facile).

Et que faire avec les machines EBCDIC, où les
« enregistrements » définissent des lignes (pas de caractère
de fin de ligne). Il n'y a pas que Windows et Unix sur la terre.

|> D'ailleurs ils le font à peu près tous maintenant, sauf
|> notepad, mais on ne peut quand même pas parler décemment
|> d'éditeur pour ce machin.

Et quels éditeurs de texte des IBM 390 connais-tu ?

--
James Kanze mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93

Vous avez filtré cet utilisateur ! Consultez son message

jz writes:

|> abitbol wrote:

|> > Merci, j'ai trouvé une solution à mon problème. Mais je
|> > ne comprends pas, c'est en transfert avec détection auto ou en
|> > ASCII que les fichiers sont mal transféré avec mon client
|> > ftp(filezilla). En revanche, ca marche si le transfert est en
|> > binaire C'est donc le contraire?!!

|> > Je n'ai donc pas tout compris ou ya une erreur dans ce post, mais
|> > j'ai enfin une solution. ...

|> Seul le mode binaire assure l'intégrité d'un transfert ftp, et
|> un transfert en mode binaire n'a jamais empéché les
|> échanges de texte.

Le transfert, non, mais le résultat n'est pas forcement exploitable
comme texte sur la machine qui le reçoit.

|> Bien que ce soit le mode par défaut de bien des clients ftp, le
|> transfert "en mode ascii" est une hérésie qui ne devrait plus
|> exister.

|> L'utilisation de ftp a évolué avec les réseaux, et il est
|> de plus en plus rare aujourd'hui de transférer des "fichiers
|> texte purs".

C'est vrai. Ça ne veut pas dire que la mode ASCII doit
disparaître, mais je conçois volentier qu'elle ne doit pas être
le défaut.

|> C'était justifié il y a bien longtemps, quand il fallait tout
|> passer en 7bits pour les communications et que la compression
|> était trop coûteuse pour les machines de l'époque. C'est
|> complètement ridicule aujourd'hui.

C'était surtout justifié parce que les différentes machines
utilisaient des codes de caractères différents -- mode ASCII
convertit toujours tout en Internet ASCII (y compris CRLF comme fin de
ligne, même si les deux machines soient Unix). Le problème existe
encore, même si tu ne le rencontres pas souvent.

Ceci dit, il faudrait peut-être rédéfinir ce qu'on entend par
« texte », parce qu'un fichier en ISO 8859-15 ne compte pas comme
texte pour le protocol.

|> Si le codage des fins de ligne d'un fichier est différent entre
|> deux machines, c'est à l'éditeur de se débrouiller pour que
|> l'affichage soit correct (c'est vraiment facile).

Et que faire avec les machines EBCDIC, où les
« enregistrements » définissent des lignes (pas de caractère
de fin de ligne). Il n'y a pas que Windows et Unix sur la terre.

|> D'ailleurs ils le font à peu près tous maintenant, sauf
|> notepad, mais on ne peut quand même pas parler décemment
|> d'éditeur pour ce machin.

Et quels éditeurs de texte des IBM 390 connais-tu ?

--
James Kanze mailto:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93

jz

01/02/2004 à 23:16

James Kanze wrote:

jz writes:
|> abitbol wrote:
...
|> Seul le mode binaire assure l'intégrité d'un transfert ftp, et
|> un transfert en mode binaire n'a jamais empéché les
|> échanges de texte.

Le transfert, non, mais le résultat n'est pas forcement exploitable
comme texte sur la machine qui le reçoit.

C'est pour cela que je persiste à dire que l'éditeur doit se débrouiller
pour rendre le texte lisible, ou bien alors l'os de la machine doit
fournir les outils de conversions, tout comme cela se fait pour les
problèmes de big ou little endian.

...

|> C'était justifié il y a bien longtemps, quand il fallait tout
|> passer en 7bits pour les communications et que la compression
|> était trop coûteuse pour les machines de l'époque. C'est
|> complètement ridicule aujourd'hui.

C'était surtout justifié parce que les différentes machines
utilisaient des codes de caractères différents -- mode ASCII
convertit toujours tout en Internet ASCII (y compris CRLF comme fin de
ligne, même si les deux machines soient Unix). Le problème existe
encore, même si tu ne le rencontres pas souvent.

J'espère bien que ce problème va complètement disparaître. Je considère
que c'est une faute grave de la part d'un programmeur de ne pas
respecter les normes élémentaires d'échange, sauf s'il fait du cryptage.

Ceci dit, il faudrait peut-être rédéfinir ce qu'on entend par
« texte », parce qu'un fichier en ISO 8859-15 ne compte pas comme
texte pour le protocol.

En effet. Pour ma part je suis convaincu que utf8 sera le remplaçant de
l'ascii dans un avenir pas très lointain (je n'ai hélas pas plus de
précisions).
Nous sommes déjà dans une phase intermédiaire où l'on voit transiter
tous les formats dans une pagaille indescriptible. Je souhaite que cette
période soit la plus brève possible.
Bien sûr le format est un peu plus lourd, mais les machines et les
réseaux ont tellement évolués depuis la première norme ascii que le coût
de traitement est insignifiant devant le gain de temps utilisateur.
C'est quand même vraiment trop ridicule de devoir encore se casser la
tête pour une histoire de codage de fin ligne. Et tant mieux si on en
profite pour enfin intégrer une fois pour toutes les alphabets
internationaux, avec tous leurs caractères marrants que les américains
n'osent même pas imaginer.

...
Et que faire avec les machines EBCDIC, où les
« enregistrements » définissent des lignes (pas de caractère
de fin de ligne). Il n'y a pas que Windows et Unix sur la terre.

EBCDIC est un codage propre à un constructeur, IBM. Ce n'est pas une
norme, au contraire d'ascii ou unicode.
N'importe qui a le droit d'inventer la langue qu'il veut, mais il ne
faut pas qu'il vienne pleurer si les autres ne le comprennent pas.

...
Et quels éditeurs de texte des IBM 390 connais-tu ?

Aucun, mais il n'y a pas que IBM dans la vie :)

J'espère qu'il y a au moins ce bon vieux vi, sinon ils sont vraiment
dans la mouize :) Enfin la situation n'est pas tout à fait désespérée,
je crois qu'il y a un portage de linux pour ibm390 :)

Plus sérieusement, je trouve dommage de s'aligner sur le moins
performant s'il persiste à ne pas vouloir s'adapter. La réputation
d'EBCDIC n'est quand même pas si reluisante que cela vaille le coup de
le conserver.

A+
Jacques

PS. on ne serait pas un petit peu hors charte là ?

James Kanze wrote:

jz <jz@jz.jz> writes:
|> abitbol wrote:
...
|> Seul le mode binaire assure l'intégrité d'un transfert ftp, et
|> un transfert en mode binaire n'a jamais empéché les
|> échanges de texte.

Le transfert, non, mais le résultat n'est pas forcement exploitable
comme texte sur la machine qui le reçoit.

C'est pour cela que je persiste à dire que l'éditeur doit se débrouiller
pour rendre le texte lisible, ou bien alors l'os de la machine doit
fournir les outils de conversions, tout comme cela se fait pour les
problèmes de big ou little endian.

...

|> C'était justifié il y a bien longtemps, quand il fallait tout
|> passer en 7bits pour les communications et que la compression
|> était trop coûteuse pour les machines de l'époque. C'est
|> complètement ridicule aujourd'hui.

C'était surtout justifié parce que les différentes machines
utilisaient des codes de caractères différents -- mode ASCII
convertit toujours tout en Internet ASCII (y compris CRLF comme fin de
ligne, même si les deux machines soient Unix). Le problème existe
encore, même si tu ne le rencontres pas souvent.

J'espère bien que ce problème va complètement disparaître. Je considère
que c'est une faute grave de la part d'un programmeur de ne pas
respecter les normes élémentaires d'échange, sauf s'il fait du cryptage.

Ceci dit, il faudrait peut-être rédéfinir ce qu'on entend par
« texte », parce qu'un fichier en ISO 8859-15 ne compte pas comme
texte pour le protocol.

En effet. Pour ma part je suis convaincu que utf8 sera le remplaçant de
l'ascii dans un avenir pas très lointain (je n'ai hélas pas plus de
précisions).
Nous sommes déjà dans une phase intermédiaire où l'on voit transiter
tous les formats dans une pagaille indescriptible. Je souhaite que cette
période soit la plus brève possible.
Bien sûr le format est un peu plus lourd, mais les machines et les
réseaux ont tellement évolués depuis la première norme ascii que le coût
de traitement est insignifiant devant le gain de temps utilisateur.
C'est quand même vraiment trop ridicule de devoir encore se casser la
tête pour une histoire de codage de fin ligne. Et tant mieux si on en
profite pour enfin intégrer une fois pour toutes les alphabets
internationaux, avec tous leurs caractères marrants que les américains
n'osent même pas imaginer.

...
Et que faire avec les machines EBCDIC, où les
« enregistrements » définissent des lignes (pas de caractère
de fin de ligne). Il n'y a pas que Windows et Unix sur la terre.

EBCDIC est un codage propre à un constructeur, IBM. Ce n'est pas une
norme, au contraire d'ascii ou unicode.
N'importe qui a le droit d'inventer la langue qu'il veut, mais il ne
faut pas qu'il vienne pleurer si les autres ne le comprennent pas.

...
Et quels éditeurs de texte des IBM 390 connais-tu ?

Aucun, mais il n'y a pas que IBM dans la vie :)

J'espère qu'il y a au moins ce bon vieux vi, sinon ils sont vraiment
dans la mouize :) Enfin la situation n'est pas tout à fait désespérée,
je crois qu'il y a un portage de linux pour ibm390 :)

Plus sérieusement, je trouve dommage de s'aligner sur le moins
performant s'il persiste à ne pas vouloir s'adapter. La réputation
d'EBCDIC n'est quand même pas si reluisante que cela vaille le coup de
le conserver.

A+
Jacques

PS. on ne serait pas un petit peu hors charte là ?

Vous avez filtré cet utilisateur ! Consultez son message

James Kanze wrote:

jz writes:
|> abitbol wrote:
...
|> Seul le mode binaire assure l'intégrité d'un transfert ftp, et
|> un transfert en mode binaire n'a jamais empéché les
|> échanges de texte.

Le transfert, non, mais le résultat n'est pas forcement exploitable
comme texte sur la machine qui le reçoit.

C'est pour cela que je persiste à dire que l'éditeur doit se débrouiller
pour rendre le texte lisible, ou bien alors l'os de la machine doit
fournir les outils de conversions, tout comme cela se fait pour les
problèmes de big ou little endian.

...

|> C'était justifié il y a bien longtemps, quand il fallait tout
|> passer en 7bits pour les communications et que la compression
|> était trop coûteuse pour les machines de l'époque. C'est
|> complètement ridicule aujourd'hui.

C'était surtout justifié parce que les différentes machines
utilisaient des codes de caractères différents -- mode ASCII
convertit toujours tout en Internet ASCII (y compris CRLF comme fin de
ligne, même si les deux machines soient Unix). Le problème existe
encore, même si tu ne le rencontres pas souvent.

J'espère bien que ce problème va complètement disparaître. Je considère
que c'est une faute grave de la part d'un programmeur de ne pas
respecter les normes élémentaires d'échange, sauf s'il fait du cryptage.

Ceci dit, il faudrait peut-être rédéfinir ce qu'on entend par
« texte », parce qu'un fichier en ISO 8859-15 ne compte pas comme
texte pour le protocol.

En effet. Pour ma part je suis convaincu que utf8 sera le remplaçant de
l'ascii dans un avenir pas très lointain (je n'ai hélas pas plus de
précisions).
Nous sommes déjà dans une phase intermédiaire où l'on voit transiter
tous les formats dans une pagaille indescriptible. Je souhaite que cette
période soit la plus brève possible.
Bien sûr le format est un peu plus lourd, mais les machines et les
réseaux ont tellement évolués depuis la première norme ascii que le coût
de traitement est insignifiant devant le gain de temps utilisateur.
C'est quand même vraiment trop ridicule de devoir encore se casser la
tête pour une histoire de codage de fin ligne. Et tant mieux si on en
profite pour enfin intégrer une fois pour toutes les alphabets
internationaux, avec tous leurs caractères marrants que les américains
n'osent même pas imaginer.

...
Et que faire avec les machines EBCDIC, où les
« enregistrements » définissent des lignes (pas de caractère
de fin de ligne). Il n'y a pas que Windows et Unix sur la terre.

EBCDIC est un codage propre à un constructeur, IBM. Ce n'est pas une
norme, au contraire d'ascii ou unicode.
N'importe qui a le droit d'inventer la langue qu'il veut, mais il ne
faut pas qu'il vienne pleurer si les autres ne le comprennent pas.

...
Et quels éditeurs de texte des IBM 390 connais-tu ?

Aucun, mais il n'y a pas que IBM dans la vie :)

J'espère qu'il y a au moins ce bon vieux vi, sinon ils sont vraiment
dans la mouize :) Enfin la situation n'est pas tout à fait désespérée,
je crois qu'il y a un portage de linux pour ibm390 :)

Plus sérieusement, je trouve dommage de s'aligner sur le moins
performant s'il persiste à ne pas vouloir s'adapter. La réputation
d'EBCDIC n'est quand même pas si reluisante que cela vaille le coup de
le conserver.

A+
Jacques

PS. on ne serait pas un petit peu hors charte là ?

kanze

02/02/2004 à 09:46

jz wrote in message
news:<401d7b01$0$2970$...

James Kanze wrote:
jz writes:
|> abitbol wrote:
...

|> Seul le mode binaire assure l'intégrité d'un transfert ftp, et
|> un transfert en mode binaire n'a jamais empéché les
|> échanges de texte.

Le transfert, non, mais le résultat n'est pas forcement exploitable
comme texte sur la machine qui le reçoit.

C'est pour cela que je persiste à dire que l'éditeur doit se
débrouiller pour rendre le texte lisible, ou bien alors l'os de la
machine doit fournir les outils de conversions, tout comme cela se
fait pour les problèmes de big ou little endian.

Les outils existent, en général. Mais pourquoi rendre la vie difficile ?

...

|> C'était justifié il y a bien longtemps, quand il fallait tout
|> passer en 7bits pour les communications et que la compression
|> était trop coûteuse pour les machines de l'époque. C'est
|> complètement ridicule aujourd'hui.

C'était surtout justifié parce que les différentes machines
utilisaient des codes de caractères différents -- mode ASCII
convertit toujours tout en Internet ASCII (y compris CRLF comme fin
de ligne, même si les deux machines soient Unix). Le problème existe
encore, même si tu ne le rencontres pas souvent.

J'espère bien que ce problème va complètement disparaître. Je
considère que c'est une faute grave de la part d'un programmeur de ne
pas respecter les normes élémentaires d'échange, sauf s'il fait du
cryptage.

C'est exactement ce que je dis. C'est le mode ASCII de ftp qui respecte
la norme internationale d'échange de texte, c-à-d l'ASCII d'Internet.
C'est une norme un peu limitée, j'en conviens, mais c'est LA norme.

Ceci dit, il faudrait peut-être rédéfinir ce qu'on entend par
« texte », parce qu'un fichier en ISO 8859-15 ne compte pas comme
texte pour le protocol.

En effet. Pour ma part je suis convaincu que utf8 sera le remplaçant
de l'ascii dans un avenir pas très lointain (je n'ai hélas pas plus de
précisions).

Il ne faut pas prendre tes souhaits pour la réalité. Moi aussi,
j'aimerais que ce soit le cas. N'empêche qu'actuellement, ce ne l'est
pas. Et que ça ne resoud pas le problème : le problème, c'est que si tu
transfères du texte, tu veux respecter une norme (ASCII d'Internet,
UTF-8, mais sans doute toujours avec CRLF comme fin de ligne, etc.) ;
quand tu transfères des données binaires (executable, etc.), tu ne veux
surtout pas que le programme touche à des données pour les rendre
conforme à une norme, quoiqu'elle soit.

Nous sommes déjà dans une phase intermédiaire où l'on voit transiter
tous les formats dans une pagaille indescriptible. Je souhaite que
cette période soit la plus brève possible.

Malheureusement, entre ce qu'on veut, et ce qu'on a... Je connais au
moins une société où la plus grande partie de leurs données internes
sont sur un IBM 390. En EBCDIC.

Bien sûr le format est un peu plus lourd, mais les machines et les
réseaux ont tellement évolués depuis la première norme ascii que le
coût de traitement est insignifiant devant le gain de temps
utilisateur.

Gain de temps pour certains utilisateurs.

Ça serait un avantage énorme si tout était unifié. Mais le prix pour y
arriver est lourd. Et ce n'est pas certain qu'il y a consensus en ce qui
concerne ce qu'il faut normaliser -- certains (Microsoft, IBM) semblent
préférer UTF-16, par exemple.

C'est quand même vraiment trop ridicule de devoir encore se casser la
tête pour une histoire de codage de fin ligne.

Tout à fait d'accord. La norme internationale dit que c'est la séquence
CRLF. Alors, il faut jeter à la poubelle tous les systèmes (c-à-d tous
les Unix, les Mac et les gros IBM) et tous les langages (comme C et C++)
qui disent autre chose.

Qu'on le veuille ou non, l'histoire existe. Il est clair aujourd'hui que
les auteurs de Unix ont fait une grosse erreur à ne pas respecter la
norme en ce qui concerne la représentation des fins de lignes. Mais à
l'époque, il y avait de bonnes raisons aussi pour faire ce qu'ils ont
fait.

Et tant mieux si on en profite pour enfin intégrer une fois pour
toutes les alphabets internationaux, avec tous leurs caractères
marrants que les américains n'osent même pas imaginer.

C'est ce qu'essaie à faire Unicode. Tout le monde s'accorde sur l'idée
de Unicode. Seulement, d'une part, il en existe plusieurs
représentations externes (« encoding scheme », dans le langage
d'Unicode), et de l'autre, il existe encore pas mal de données dans
d'autres encodages, qui ne sont pas près à disparaître.

...
Et que faire avec les machines EBCDIC, où les
« enregistrements » définissent des lignes (pas de caractère
de fin de ligne). Il n'y a pas que Windows et Unix sur la terre.

EBCDIC est un codage propre à un constructeur, IBM. Ce n'est pas une
norme, au contraire d'ascii ou unicode. N'importe qui a le droit
d'inventer la langue qu'il veut, mais il ne faut pas qu'il vienne
pleurer si les autres ne le comprennent pas.

Et qu'est-ce qu'ils auraient dû faire ? Quand IBM a inventé EBCDIC, il
n'y avait pas de ASCII.

...
Et quels éditeurs de texte des IBM 390 connais-tu ?

Aucun, mais il n'y a pas que IBM dans la vie :)

Non, mais quand on parle d'une solution reseau, il faut prendre en
compte tout ce qui existe.

J'espère qu'il y a au moins ce bon vieux vi, sinon ils sont vraiment
dans la mouize :)

Je vois mal comment vi fonctionnerait sur un système qui ne permet pas
la communication caractère par caractère avec un terminal. Les éditeurs
IBM se basent tous sur 3270.

Enfin la situation n'est pas tout à fait désespérée,
je crois qu'il y a un portage de linux pour ibm390 :)

Tu n'as pas l'air de te rendre compte. S'il y a encore des utilisateurs
des IBM 390, c'est qu'ils ont besoin d'un système ultra stable, qui
marche.

Plus sérieusement, je trouve dommage de s'aligner sur le moins
performant s'il persiste à ne pas vouloir s'adapter. La réputation
d'EBCDIC n'est quand même pas si reluisante que cela vaille le coup de
le conserver.

C'est toi qui va payer la conversion des données ? L'EBCDIC n'est pas
sans fautes -- surtout quand on considère l'internationalisation (mais
là, l'ASCII n'est guère mieux). Mais il faut reconnaître son rôle de
pionnier. Et il faut aussi reconnaître que la conversion des données,
c'est très, très chère, et que les sociétés ne l'entreprenent que dans
la mesure que ça leur apporte quelque chose.

Et que le rôle de protocols comme FTP, c'est justement de permettre le
transfers de données entre *toutes* les machines. Non seulement les
Wintels et les Linux.

--
James Kanze GABI Software mailto:
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

jz <jz@jz.jz> wrote in message
news:<401d7b01$0$2970$626a54ce@news.free.fr>...

James Kanze wrote:

jz <jz@jz.jz> writes:
|> abitbol wrote:
...

|> Seul le mode binaire assure l'intégrité d'un transfert ftp, et
|> un transfert en mode binaire n'a jamais empéché les
|> échanges de texte.

Le transfert, non, mais le résultat n'est pas forcement exploitable
comme texte sur la machine qui le reçoit.

C'est pour cela que je persiste à dire que l'éditeur doit se
débrouiller pour rendre le texte lisible, ou bien alors l'os de la
machine doit fournir les outils de conversions, tout comme cela se
fait pour les problèmes de big ou little endian.

Les outils existent, en général. Mais pourquoi rendre la vie difficile ?

...

|> C'était justifié il y a bien longtemps, quand il fallait tout
|> passer en 7bits pour les communications et que la compression
|> était trop coûteuse pour les machines de l'époque. C'est
|> complètement ridicule aujourd'hui.

C'était surtout justifié parce que les différentes machines
utilisaient des codes de caractères différents -- mode ASCII
convertit toujours tout en Internet ASCII (y compris CRLF comme fin
de ligne, même si les deux machines soient Unix). Le problème existe
encore, même si tu ne le rencontres pas souvent.

J'espère bien que ce problème va complètement disparaître. Je
considère que c'est une faute grave de la part d'un programmeur de ne
pas respecter les normes élémentaires d'échange, sauf s'il fait du
cryptage.

C'est exactement ce que je dis. C'est le mode ASCII de ftp qui respecte
la norme internationale d'échange de texte, c-à-d l'ASCII d'Internet.
C'est une norme un peu limitée, j'en conviens, mais c'est LA norme.

Ceci dit, il faudrait peut-être rédéfinir ce qu'on entend par
« texte », parce qu'un fichier en ISO 8859-15 ne compte pas comme
texte pour le protocol.

En effet. Pour ma part je suis convaincu que utf8 sera le remplaçant
de l'ascii dans un avenir pas très lointain (je n'ai hélas pas plus de
précisions).

Il ne faut pas prendre tes souhaits pour la réalité. Moi aussi,
j'aimerais que ce soit le cas. N'empêche qu'actuellement, ce ne l'est
pas. Et que ça ne resoud pas le problème : le problème, c'est que si tu
transfères du texte, tu veux respecter une norme (ASCII d'Internet,
UTF-8, mais sans doute toujours avec CRLF comme fin de ligne, etc.) ;
quand tu transfères des données binaires (executable, etc.), tu ne veux
surtout pas que le programme touche à des données pour les rendre
conforme à une norme, quoiqu'elle soit.

Nous sommes déjà dans une phase intermédiaire où l'on voit transiter
tous les formats dans une pagaille indescriptible. Je souhaite que
cette période soit la plus brève possible.

Malheureusement, entre ce qu'on veut, et ce qu'on a... Je connais au
moins une société où la plus grande partie de leurs données internes
sont sur un IBM 390. En EBCDIC.

Bien sûr le format est un peu plus lourd, mais les machines et les
réseaux ont tellement évolués depuis la première norme ascii que le
coût de traitement est insignifiant devant le gain de temps
utilisateur.

Gain de temps pour certains utilisateurs.

Ça serait un avantage énorme si tout était unifié. Mais le prix pour y
arriver est lourd. Et ce n'est pas certain qu'il y a consensus en ce qui
concerne ce qu'il faut normaliser -- certains (Microsoft, IBM) semblent
préférer UTF-16, par exemple.

C'est quand même vraiment trop ridicule de devoir encore se casser la
tête pour une histoire de codage de fin ligne.

Tout à fait d'accord. La norme internationale dit que c'est la séquence
CRLF. Alors, il faut jeter à la poubelle tous les systèmes (c-à-d tous
les Unix, les Mac et les gros IBM) et tous les langages (comme C et C++)
qui disent autre chose.

Qu'on le veuille ou non, l'histoire existe. Il est clair aujourd'hui que
les auteurs de Unix ont fait une grosse erreur à ne pas respecter la
norme en ce qui concerne la représentation des fins de lignes. Mais à
l'époque, il y avait de bonnes raisons aussi pour faire ce qu'ils ont
fait.

Et tant mieux si on en profite pour enfin intégrer une fois pour
toutes les alphabets internationaux, avec tous leurs caractères
marrants que les américains n'osent même pas imaginer.

C'est ce qu'essaie à faire Unicode. Tout le monde s'accorde sur l'idée
de Unicode. Seulement, d'une part, il en existe plusieurs
représentations externes (« encoding scheme », dans le langage
d'Unicode), et de l'autre, il existe encore pas mal de données dans
d'autres encodages, qui ne sont pas près à disparaître.

...
Et que faire avec les machines EBCDIC, où les
« enregistrements » définissent des lignes (pas de caractère
de fin de ligne). Il n'y a pas que Windows et Unix sur la terre.

EBCDIC est un codage propre à un constructeur, IBM. Ce n'est pas une
norme, au contraire d'ascii ou unicode. N'importe qui a le droit
d'inventer la langue qu'il veut, mais il ne faut pas qu'il vienne
pleurer si les autres ne le comprennent pas.

Et qu'est-ce qu'ils auraient dû faire ? Quand IBM a inventé EBCDIC, il
n'y avait pas de ASCII.

...
Et quels éditeurs de texte des IBM 390 connais-tu ?

Aucun, mais il n'y a pas que IBM dans la vie :)

Non, mais quand on parle d'une solution reseau, il faut prendre en
compte tout ce qui existe.

J'espère qu'il y a au moins ce bon vieux vi, sinon ils sont vraiment
dans la mouize :)

Je vois mal comment vi fonctionnerait sur un système qui ne permet pas
la communication caractère par caractère avec un terminal. Les éditeurs
IBM se basent tous sur 3270.

Enfin la situation n'est pas tout à fait désespérée,
je crois qu'il y a un portage de linux pour ibm390 :)

Tu n'as pas l'air de te rendre compte. S'il y a encore des utilisateurs
des IBM 390, c'est qu'ils ont besoin d'un système ultra stable, qui
marche.

Plus sérieusement, je trouve dommage de s'aligner sur le moins
performant s'il persiste à ne pas vouloir s'adapter. La réputation
d'EBCDIC n'est quand même pas si reluisante que cela vaille le coup de
le conserver.

C'est toi qui va payer la conversion des données ? L'EBCDIC n'est pas
sans fautes -- surtout quand on considère l'internationalisation (mais
là, l'ASCII n'est guère mieux). Mais il faut reconnaître son rôle de
pionnier. Et il faut aussi reconnaître que la conversion des données,
c'est très, très chère, et que les sociétés ne l'entreprenent que dans
la mesure que ça leur apporte quelque chose.

Et que le rôle de protocols comme FTP, c'est justement de permettre le
transfers de données entre *toutes* les machines. Non seulement les
Wintels et les Linux.

--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

Vous avez filtré cet utilisateur ! Consultez son message

jz wrote in message
news:<401d7b01$0$2970$...

James Kanze wrote:
jz writes:
|> abitbol wrote:
...

|> Seul le mode binaire assure l'intégrité d'un transfert ftp, et
|> un transfert en mode binaire n'a jamais empéché les
|> échanges de texte.

Le transfert, non, mais le résultat n'est pas forcement exploitable
comme texte sur la machine qui le reçoit.

C'est pour cela que je persiste à dire que l'éditeur doit se
débrouiller pour rendre le texte lisible, ou bien alors l'os de la
machine doit fournir les outils de conversions, tout comme cela se
fait pour les problèmes de big ou little endian.

Les outils existent, en général. Mais pourquoi rendre la vie difficile ?

...

|> C'était justifié il y a bien longtemps, quand il fallait tout
|> passer en 7bits pour les communications et que la compression
|> était trop coûteuse pour les machines de l'époque. C'est
|> complètement ridicule aujourd'hui.

C'était surtout justifié parce que les différentes machines
utilisaient des codes de caractères différents -- mode ASCII
convertit toujours tout en Internet ASCII (y compris CRLF comme fin
de ligne, même si les deux machines soient Unix). Le problème existe
encore, même si tu ne le rencontres pas souvent.

J'espère bien que ce problème va complètement disparaître. Je
considère que c'est une faute grave de la part d'un programmeur de ne
pas respecter les normes élémentaires d'échange, sauf s'il fait du
cryptage.

C'est exactement ce que je dis. C'est le mode ASCII de ftp qui respecte
la norme internationale d'échange de texte, c-à-d l'ASCII d'Internet.
C'est une norme un peu limitée, j'en conviens, mais c'est LA norme.

Ceci dit, il faudrait peut-être rédéfinir ce qu'on entend par
« texte », parce qu'un fichier en ISO 8859-15 ne compte pas comme
texte pour le protocol.

En effet. Pour ma part je suis convaincu que utf8 sera le remplaçant
de l'ascii dans un avenir pas très lointain (je n'ai hélas pas plus de
précisions).

Il ne faut pas prendre tes souhaits pour la réalité. Moi aussi,
j'aimerais que ce soit le cas. N'empêche qu'actuellement, ce ne l'est
pas. Et que ça ne resoud pas le problème : le problème, c'est que si tu
transfères du texte, tu veux respecter une norme (ASCII d'Internet,
UTF-8, mais sans doute toujours avec CRLF comme fin de ligne, etc.) ;
quand tu transfères des données binaires (executable, etc.), tu ne veux
surtout pas que le programme touche à des données pour les rendre
conforme à une norme, quoiqu'elle soit.

Nous sommes déjà dans une phase intermédiaire où l'on voit transiter
tous les formats dans une pagaille indescriptible. Je souhaite que
cette période soit la plus brève possible.

Malheureusement, entre ce qu'on veut, et ce qu'on a... Je connais au
moins une société où la plus grande partie de leurs données internes
sont sur un IBM 390. En EBCDIC.

Bien sûr le format est un peu plus lourd, mais les machines et les
réseaux ont tellement évolués depuis la première norme ascii que le
coût de traitement est insignifiant devant le gain de temps
utilisateur.

Gain de temps pour certains utilisateurs.

Ça serait un avantage énorme si tout était unifié. Mais le prix pour y
arriver est lourd. Et ce n'est pas certain qu'il y a consensus en ce qui
concerne ce qu'il faut normaliser -- certains (Microsoft, IBM) semblent
préférer UTF-16, par exemple.

C'est quand même vraiment trop ridicule de devoir encore se casser la
tête pour une histoire de codage de fin ligne.

Tout à fait d'accord. La norme internationale dit que c'est la séquence
CRLF. Alors, il faut jeter à la poubelle tous les systèmes (c-à-d tous
les Unix, les Mac et les gros IBM) et tous les langages (comme C et C++)
qui disent autre chose.

Qu'on le veuille ou non, l'histoire existe. Il est clair aujourd'hui que
les auteurs de Unix ont fait une grosse erreur à ne pas respecter la
norme en ce qui concerne la représentation des fins de lignes. Mais à
l'époque, il y avait de bonnes raisons aussi pour faire ce qu'ils ont
fait.

Et tant mieux si on en profite pour enfin intégrer une fois pour
toutes les alphabets internationaux, avec tous leurs caractères
marrants que les américains n'osent même pas imaginer.

C'est ce qu'essaie à faire Unicode. Tout le monde s'accorde sur l'idée
de Unicode. Seulement, d'une part, il en existe plusieurs
représentations externes (« encoding scheme », dans le langage
d'Unicode), et de l'autre, il existe encore pas mal de données dans
d'autres encodages, qui ne sont pas près à disparaître.

...
Et que faire avec les machines EBCDIC, où les
« enregistrements » définissent des lignes (pas de caractère
de fin de ligne). Il n'y a pas que Windows et Unix sur la terre.

EBCDIC est un codage propre à un constructeur, IBM. Ce n'est pas une
norme, au contraire d'ascii ou unicode. N'importe qui a le droit
d'inventer la langue qu'il veut, mais il ne faut pas qu'il vienne
pleurer si les autres ne le comprennent pas.

Et qu'est-ce qu'ils auraient dû faire ? Quand IBM a inventé EBCDIC, il
n'y avait pas de ASCII.

...
Et quels éditeurs de texte des IBM 390 connais-tu ?

Aucun, mais il n'y a pas que IBM dans la vie :)

Non, mais quand on parle d'une solution reseau, il faut prendre en
compte tout ce qui existe.

J'espère qu'il y a au moins ce bon vieux vi, sinon ils sont vraiment
dans la mouize :)

Je vois mal comment vi fonctionnerait sur un système qui ne permet pas
la communication caractère par caractère avec un terminal. Les éditeurs
IBM se basent tous sur 3270.

Enfin la situation n'est pas tout à fait désespérée,
je crois qu'il y a un portage de linux pour ibm390 :)

Tu n'as pas l'air de te rendre compte. S'il y a encore des utilisateurs
des IBM 390, c'est qu'ils ont besoin d'un système ultra stable, qui
marche.

Plus sérieusement, je trouve dommage de s'aligner sur le moins
performant s'il persiste à ne pas vouloir s'adapter. La réputation
d'EBCDIC n'est quand même pas si reluisante que cela vaille le coup de
le conserver.

C'est toi qui va payer la conversion des données ? L'EBCDIC n'est pas
sans fautes -- surtout quand on considère l'internationalisation (mais
là, l'ASCII n'est guère mieux). Mais il faut reconnaître son rôle de
pionnier. Et il faut aussi reconnaître que la conversion des données,
c'est très, très chère, et que les sociétés ne l'entreprenent que dans
la mesure que ça leur apporte quelque chose.

Et que le rôle de protocols comme FTP, c'est justement de permettre le
transfers de données entre *toutes* les machines. Non seulement les
Wintels et les Linux.

--
James Kanze GABI Software mailto:
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

Samuel Krempp

03/02/2004 à 00:54

le Sunday 01 February 2004 15:49, écrivit :

Samuel Krempp writes:

|> le Sunday 01 February 2004 13:14, écrivit :
|> > probablement de maintenir les fichiers dans le format normalisé
|> > (qui est pour une fois celui qu'utilise Microsoft), et d'utiliser
|> > un

|> ah bon ? c'est la norme C++ qui précise ça ?

C'est la norme ASCII. Celle qui définit le jeu de caractères dont
tu te sers.

ah d'accord, je viens de voir la liste des codes Ascii 0-31 (non-printable),
qui inclue CR et LF.
Effectivement si on cherche à donner un sens à un maximum de ces symboles du
point de vue plus abstrait du codage de texte, une ligne pourrait se
terminer en CR/LF par analogie aux machines à écrire (et terminaux
antiques).

Je trouve que le choix de CR/LF ou LF seul pour signifier la fin de ligne
dépasse de tte façon le cadre su standard ascii, unix a choisi un standard,
windows un autre (plus proche des significations originales de CR/LF).
Mais finalement toute la partie ASCII qui sort des caractères lisibles est
en fait un standard de terminal, pas de codage du texte. ça rime pas à
grand chose d'essayer de reprendre le plus possible de ces choses
terminalesques dans un standard de codage de texte.
Dans les codages de texte plus récents et plus complets (iso*, unicode), il
y a un symbole 'fin de ligne', ou bien c'est encore remplacé par emprunt de
CR/et/ou/LF au domaine des terminaux ? M'enfin ensuite c'est la porte
ouverte à des symboles pour fin de paragraphe, fin de chapitre..
finalement la vraie place de la 'fin de ligne' n'est peut être pas dans le
jeu de caractères mais dans l'interpretation du flux de caractères, qui ne
devrait pas inclure de fin de ligne du tout mais seulement l'indication de
sa structure, comme ça se passe en html..

enfin bon, en attendant on tape Entrée un peu partout pour donner un minimu
de structure aux codes sources et messages texte, et c'est pas idéal mais
c'est pas si mal..
enfin, pour les codes sources ce serait tout de meme mieux que tout le
formattage soit fait par l'éditeur/visualiseur, et que le source en soit
indépendant.

Ce qui m'amnèe à une question finalement en thème : y a des outils pour
réindenter complètement (y compris ajouter/supprimer des fins de ligne) des
sources C++ ?

--
Sam

le Sunday 01 February 2004 15:49, kanze@gabi-soft.fr écrivit :

Samuel Krempp <krempp@crans.truc.en.trop.ens-cachan.fr> writes:

|> le Sunday 01 February 2004 13:14, kanze@gabi-soft.fr écrivit :
|> > probablement de maintenir les fichiers dans le format normalisé
|> > (qui est pour une fois celui qu'utilise Microsoft), et d'utiliser
|> > un

|> ah bon ? c'est la norme C++ qui précise ça ?

C'est la norme ASCII. Celle qui définit le jeu de caractères dont
tu te sers.

ah d'accord, je viens de voir la liste des codes Ascii 0-31 (non-printable),
qui inclue CR et LF.
Effectivement si on cherche à donner un sens à un maximum de ces symboles du
point de vue plus abstrait du codage de texte, une ligne pourrait se
terminer en CR/LF par analogie aux machines à écrire (et terminaux
antiques).

Je trouve que le choix de CR/LF ou LF seul pour signifier la fin de ligne
dépasse de tte façon le cadre su standard ascii, unix a choisi un standard,
windows un autre (plus proche des significations originales de CR/LF).
Mais finalement toute la partie ASCII qui sort des caractères lisibles est
en fait un standard de terminal, pas de codage du texte. ça rime pas à
grand chose d'essayer de reprendre le plus possible de ces choses
terminalesques dans un standard de codage de texte.
Dans les codages de texte plus récents et plus complets (iso*, unicode), il
y a un symbole 'fin de ligne', ou bien c'est encore remplacé par emprunt de
CR/et/ou/LF au domaine des terminaux ? M'enfin ensuite c'est la porte
ouverte à des symboles pour fin de paragraphe, fin de chapitre..
finalement la vraie place de la 'fin de ligne' n'est peut être pas dans le
jeu de caractères mais dans l'interpretation du flux de caractères, qui ne
devrait pas inclure de fin de ligne du tout mais seulement l'indication de
sa structure, comme ça se passe en html..

enfin bon, en attendant on tape Entrée un peu partout pour donner un minimu
de structure aux codes sources et messages texte, et c'est pas idéal mais
c'est pas si mal..
enfin, pour les codes sources ce serait tout de meme mieux que tout le
formattage soit fait par l'éditeur/visualiseur, et que le source en soit
indépendant.

Ce qui m'amnèe à une question finalement en thème : y a des outils pour
réindenter complètement (y compris ajouter/supprimer des fins de ligne) des
sources C++ ?

--
Sam

Vous avez filtré cet utilisateur ! Consultez son message

le Sunday 01 February 2004 15:49, écrivit :

Samuel Krempp writes:

|> le Sunday 01 February 2004 13:14, écrivit :
|> > probablement de maintenir les fichiers dans le format normalisé
|> > (qui est pour une fois celui qu'utilise Microsoft), et d'utiliser
|> > un

|> ah bon ? c'est la norme C++ qui précise ça ?

C'est la norme ASCII. Celle qui définit le jeu de caractères dont
tu te sers.

ah d'accord, je viens de voir la liste des codes Ascii 0-31 (non-printable),
qui inclue CR et LF.
Effectivement si on cherche à donner un sens à un maximum de ces symboles du
point de vue plus abstrait du codage de texte, une ligne pourrait se
terminer en CR/LF par analogie aux machines à écrire (et terminaux
antiques).

Je trouve que le choix de CR/LF ou LF seul pour signifier la fin de ligne
dépasse de tte façon le cadre su standard ascii, unix a choisi un standard,
windows un autre (plus proche des significations originales de CR/LF).
Mais finalement toute la partie ASCII qui sort des caractères lisibles est
en fait un standard de terminal, pas de codage du texte. ça rime pas à
grand chose d'essayer de reprendre le plus possible de ces choses
terminalesques dans un standard de codage de texte.
Dans les codages de texte plus récents et plus complets (iso*, unicode), il
y a un symbole 'fin de ligne', ou bien c'est encore remplacé par emprunt de
CR/et/ou/LF au domaine des terminaux ? M'enfin ensuite c'est la porte
ouverte à des symboles pour fin de paragraphe, fin de chapitre..
finalement la vraie place de la 'fin de ligne' n'est peut être pas dans le
jeu de caractères mais dans l'interpretation du flux de caractères, qui ne
devrait pas inclure de fin de ligne du tout mais seulement l'indication de
sa structure, comme ça se passe en html..

enfin bon, en attendant on tape Entrée un peu partout pour donner un minimu
de structure aux codes sources et messages texte, et c'est pas idéal mais
c'est pas si mal..
enfin, pour les codes sources ce serait tout de meme mieux que tout le
formattage soit fait par l'éditeur/visualiseur, et que le source en soit
indépendant.

Ce qui m'amnèe à une question finalement en thème : y a des outils pour
réindenter complètement (y compris ajouter/supprimer des fins de ligne) des
sources C++ ?

--
Sam

Fabien LE LEZ

03/02/2004 à 03:05

On 2 Feb 2004 00:46:39 -0800, wrote:

Tout à fait d'accord. La norme internationale dit que c'est la séquence
CRLF. [...]

Qu'on le veuille ou non, l'histoire existe. Il est clair aujourd'hui que
les auteurs de Unix ont fait une grosse erreur à ne pas respecter la
norme en ce qui concerne la représentation des fins de lignes.

Sans doute, mais faut dire aussi que c'est assez tordu comme norme :
on se retrouve finalement avec tous les caractères sur un octet, sauf
le caractère de fin de ligne qui en prend deux.

--
;-)

Fabien LE LEZ

03/02/2004 à 03:13

On Tue, 03 Feb 2004 00:54:15 +0100, Samuel Krempp
wrote:

enfin, pour les codes sources ce serait tout de meme mieux que tout le
formattage soit fait par l'éditeur/visualiseur, et que le source en soit
indépendant.

C'est ce qui se fait (se faisait) en VB pour certains trucs (notamment
la mise en page des fenêtres et boîtes de dialogue). Et on tombe vite
sur un os : on est très limité dans le choix des éditeurs (pour VB, le
nombre est même réduit à 1), et les outils habituels de traitement de
texte (je pense à grep, par exemple) sont inutilisables.

C'est d'ailleurs la même chose en HTML : le code sur lequel on
travaille est affiché dans un éditeur de texte "normal" (même s'il
existe des outils de création de code en HTML -- en C++ aussi,
d'ailleurs). HTML est un "langage" interprété, et son résultat (qui
est le document formaté) est la page web telle qu'affichée dans le
navigateur, tout comme l'exécutable est le résultat du code C++.

--
;-)

Loïc Joly

03/02/2004 à 09:00

Fabien LE LEZ wrote:

On 2 Feb 2004 00:46:39 -0800, wrote:

Tout à fait d'accord. La norme internationale dit que c'est la séquence
CRLF. [...]

Qu'on le veuille ou non, l'histoire existe. Il est clair aujourd'hui que
les auteurs de Unix ont fait une grosse erreur à ne pas respecter la
norme en ce qui concerne la représentation des fins de lignes.

Sans doute, mais faut dire aussi que c'est assez tordu comme norme :
on se retrouve finalement avec tous les caractères sur un octet, sauf
le caractère de fin de ligne qui en prend deux.

Ca veut dire quoi "caractère de fin de ligne" ? Tout ce que je connais,
c'est le "caractère de retour au début de ligne", et le "caractère
d'avance d'une ligne". Ce serait illogique que dans cette norme, tous
les caractères soint sur un octet, sauf ces deux là qui soient sur un
demi octet et en plus soient indissociables...

--
Loïc, d'humeur trollesque

Samuel Krempp

03/02/2004 à 12:40

le Tuesday 03 February 2004 03:13, écrivit :

C'est ce qui se fait (se faisait) en VB pour certains trucs (notamment
la mise en page des fenêtres et boîtes de dialogue). Et on tombe vite
sur un os : on est très limité dans le choix des éditeurs (pour VB, le
nombre est même réduit à 1),

ben ça devrait pas être embêtant, il suffit d'avoir une option pour exporter
le fichier en forme lisible, ce que l'éditeur saurait faire de toute façon.
VB ne faisait pas ça ?

et les outils habituels de traitement de
texte (je pense à grep, par exemple) sont inutilisables.

ah bon ? ah oui, tout ce qui se base sur une ligne, c vrai..
j'imaginais que l'éditeur aurait interêt à sauver le fichier avec des fins
de ligne presque partout (maximise la précision des informations qui
reportent le num de ligne), et alors ce qu'on peut trouver par grep sera
limité.
mais il y a une option de grep pour travailler sur plusieurs lignes, non ?
ou même des outils plus puissants que grep qui comprennent un peu le
fichier scanné ?

C'est d'ailleurs la même chose en HTML : le code sur lequel on
travaille est affiché dans un éditeur de texte "normal" (même s'il
existe des outils de création de code en HTML -- en C++ aussi,
d'ailleurs). HTML est un "langage" interprété, et son résultat (qui
est le document formaté) est la page web telle qu'affichée dans le
navigateur, tout comme l'exécutable est le résultat du code C++.

oui justement, comme appuyer 30 fois sur entrée dans un éditeur html n'a pas
d'effet, l'éditeur de code pourrait restreindre les libertés du codeur en
ne le laissant pas gèrer la mise en page du source. le codeur taperait
seulement le code, au kilometre et l'éditeur l'afficherait comme il faut,
de manière adaptée à la structure du code.
Ensuite pour sauver le fichier il pourrait très bien le faire dans une forme
'canonique' agréable à lire, ou au contraire avec énormément de lignes (en
vue des messages avec __LINE)
C'est absurde que le codeur aie à se soucier du formattage pour rendre son
source lisible, alors que c'est le boulot de l'éditeur/afficheur que de
représenter le code de manièere adaptée, en fonction de la structure du
code. (et de toute façon ce qui est agréable pour le codeur dépend bcp de
ses gouts, de la largeur de sa fenêtre, etc..)
Je sais pas si on peut esperer comprendre la structure du code pendant qu'il
est en train d'être tapé, c'est probablement un problème..

--
Sam

le Tuesday 03 February 2004 03:13, gramster@gramster.com écrivit :

C'est ce qui se fait (se faisait) en VB pour certains trucs (notamment
la mise en page des fenêtres et boîtes de dialogue). Et on tombe vite
sur un os : on est très limité dans le choix des éditeurs (pour VB, le
nombre est même réduit à 1),

ben ça devrait pas être embêtant, il suffit d'avoir une option pour exporter
le fichier en forme lisible, ce que l'éditeur saurait faire de toute façon.
VB ne faisait pas ça ?

et les outils habituels de traitement de
texte (je pense à grep, par exemple) sont inutilisables.

ah bon ? ah oui, tout ce qui se base sur une ligne, c vrai..
j'imaginais que l'éditeur aurait interêt à sauver le fichier avec des fins
de ligne presque partout (maximise la précision des informations qui
reportent le num de ligne), et alors ce qu'on peut trouver par grep sera
limité.
mais il y a une option de grep pour travailler sur plusieurs lignes, non ?
ou même des outils plus puissants que grep qui comprennent un peu le
fichier scanné ?

C'est d'ailleurs la même chose en HTML : le code sur lequel on
travaille est affiché dans un éditeur de texte "normal" (même s'il
existe des outils de création de code en HTML -- en C++ aussi,
d'ailleurs). HTML est un "langage" interprété, et son résultat (qui
est le document formaté) est la page web telle qu'affichée dans le
navigateur, tout comme l'exécutable est le résultat du code C++.

oui justement, comme appuyer 30 fois sur entrée dans un éditeur html n'a pas
d'effet, l'éditeur de code pourrait restreindre les libertés du codeur en
ne le laissant pas gèrer la mise en page du source. le codeur taperait
seulement le code, au kilometre et l'éditeur l'afficherait comme il faut,
de manière adaptée à la structure du code.
Ensuite pour sauver le fichier il pourrait très bien le faire dans une forme
'canonique' agréable à lire, ou au contraire avec énormément de lignes (en
vue des messages avec __LINE)
C'est absurde que le codeur aie à se soucier du formattage pour rendre son
source lisible, alors que c'est le boulot de l'éditeur/afficheur que de
représenter le code de manièere adaptée, en fonction de la structure du
code. (et de toute façon ce qui est agréable pour le codeur dépend bcp de
ses gouts, de la largeur de sa fenêtre, etc..)
Je sais pas si on peut esperer comprendre la structure du code pendant qu'il
est en train d'être tapé, c'est probablement un problème..

--
Sam

Vous avez filtré cet utilisateur ! Consultez son message

le Tuesday 03 February 2004 03:13, écrivit :

C'est ce qui se fait (se faisait) en VB pour certains trucs (notamment
la mise en page des fenêtres et boîtes de dialogue). Et on tombe vite
sur un os : on est très limité dans le choix des éditeurs (pour VB, le
nombre est même réduit à 1),

ben ça devrait pas être embêtant, il suffit d'avoir une option pour exporter
le fichier en forme lisible, ce que l'éditeur saurait faire de toute façon.
VB ne faisait pas ça ?

et les outils habituels de traitement de
texte (je pense à grep, par exemple) sont inutilisables.

ah bon ? ah oui, tout ce qui se base sur une ligne, c vrai..
j'imaginais que l'éditeur aurait interêt à sauver le fichier avec des fins
de ligne presque partout (maximise la précision des informations qui
reportent le num de ligne), et alors ce qu'on peut trouver par grep sera
limité.
mais il y a une option de grep pour travailler sur plusieurs lignes, non ?
ou même des outils plus puissants que grep qui comprennent un peu le
fichier scanné ?

C'est d'ailleurs la même chose en HTML : le code sur lequel on
travaille est affiché dans un éditeur de texte "normal" (même s'il
existe des outils de création de code en HTML -- en C++ aussi,
d'ailleurs). HTML est un "langage" interprété, et son résultat (qui
est le document formaté) est la page web telle qu'affichée dans le
navigateur, tout comme l'exécutable est le résultat du code C++.

oui justement, comme appuyer 30 fois sur entrée dans un éditeur html n'a pas
d'effet, l'éditeur de code pourrait restreindre les libertés du codeur en
ne le laissant pas gèrer la mise en page du source. le codeur taperait
seulement le code, au kilometre et l'éditeur l'afficherait comme il faut,
de manière adaptée à la structure du code.
Ensuite pour sauver le fichier il pourrait très bien le faire dans une forme
'canonique' agréable à lire, ou au contraire avec énormément de lignes (en
vue des messages avec __LINE)
C'est absurde que le codeur aie à se soucier du formattage pour rendre son
source lisible, alors que c'est le boulot de l'éditeur/afficheur que de
représenter le code de manièere adaptée, en fonction de la structure du
code. (et de toute façon ce qui est agréable pour le codeur dépend bcp de
ses gouts, de la largeur de sa fenêtre, etc..)
Je sais pas si on peut esperer comprendre la structure du code pendant qu'il
est en train d'être tapé, c'est probablement un problème..

--
Sam

kanze

03/02/2004 à 14:29

Loïc Joly wrote in message
news:<bvnk6g$lv0$...

Fabien LE LEZ wrote:

On 2 Feb 2004 00:46:39 -0800, wrote:

Tout à fait d'accord. La norme internationale dit que c'est la
séquence CRLF. [...]

Qu'on le veuille ou non, l'histoire existe. Il est clair aujourd'hui
que les auteurs de Unix ont fait une grosse erreur à ne pas
respecter la norme en ce qui concerne la représentation des fins de
lignes.

Sans doute, mais faut dire aussi que c'est assez tordu comme norme :
on se retrouve finalement avec tous les caractères sur un octet,
sauf le caractère de fin de ligne qui en prend deux.

Ca veut dire quoi "caractère de fin de ligne" ? Tout ce que je
connais, c'est le "caractère de retour au début de ligne", et le
"caractère d'avance d'une ligne". Ce serait illogique que dans cette
norme, tous les caractères soint sur un octet, sauf ces deux là qui
soient sur un demi octet et en plus soient indissociables...

En fait, évidemment, cette norme a été conçue pour d'autre chose que le
traitement informatique. Et que pour l'utilisation actuelle en C et C++,
le code qui convient, c'est RS (« record separator », 0x1E):-).

Historiquement, évidemment, on se servait bien de CRLF, et que de CRLF.
C'est le driver tty des premiers Unix que faisait la conversion en
simple LF. Aller savoir pourquoi.

--
James Kanze GABI Software mailto:
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

message : "lines ending with only a carriage..."

10 réponses

Veuillez sélectionner un problème