Discussion :

[ptonnerre]

Bonjour,

je développe sur une plateforme RHEL6.6 un programme Perl (vs 5.10.1) susceptible d'envoyer des emails vers un serveur Exchange qui seront lus avec un client Outlook 2010.
Pour gérer l'aspect encodage, j'ai consulté https://perl.developpez.com/tutoriel...ge-caracteres/.

Le script n'utilise pas le pragma use utf8
Pour que les caractères s'affichent correctement dans Outlook, j'ai créé la fonction outlook_encode appelée par la fonction send_mail.

Le résultat est correct mais je me demande si c'est la bonne façon de procéder car je ne suis pas très à l'aise lorsqu'il s'agit de manipuler les encodages ;)
J'avais essayé dans un premier temps d'utiliser sans succès :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

$msg->attr('content-type.charset' => 'CP1252');

Par la même occasion, un peu off-topic de ma précédente question, mais je n'arrive pas à obtenir dans le mail le saut de ligne entre les deux derniers éléments du tableau @t_str alors que les boucles foreach qui parcourent les tableaux de données pointées par les références fonctionnent. Voir l'image jointe, la ligne après 'Statut changé pour entrées oratab' devrait présenter un saut de ligne avant le mot 'sinon'.

Merci pour vos avis et commentaires.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
sub outlook_encode {
    my ( $string ) = @_;
    return encode ( 'CP1252', (decode ('UTF-8', $string ))  );
}

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
sub send_mail {
    my ( $r_log, $r_h_env, $r_t_new ,$r_t_del, $r_t_chg ) = @_;
 
    my $to   = 'xxx@yyy';
    my $cc   = 'xxx@yyy, xxx@yyy';
    my $from = 'xxx@yyy';
 
    my $subject = 'Action Production - Interventions ODA';
    my $message;
 
    if ( scalar(@$r_t_new) > 0 ) {
        my $str   = 'Nouvelles entrées oratab => Créer traitements VTOM de sauvegardes';
        $message .= outlook_encode ( $str ) . "\n" . $r_h_env->{'dash132'} . "\n" ;
        $message .= outlook_encode ( $_ ) . "\n" foreach @$r_t_new;
        $message .= "\n";
    }
 
    if ( scalar(@$r_t_del) > 0 ) {
        my $str   = 'Entrées oratab manquantes => Désactiver ou supprimer traitements VTOM correspondants';
        $message .= outlook_encode ( $str ) . "\n" . $r_h_env->{'dash132'} . "\n" ;
        $message .= outlook_encode ( $_ ) . "\n" foreach @$r_t_del;
        $message .= "\n";
    }
 
    if ( scalar(@$r_t_chg) > 0 ) {
 
        my @t_str = ( 'Statut changé pour entrées oratab' ,
                      'Si fin du nouveau primaire se termine par ORA0 alors dans VTOM switcher les machines physiques des machines logiques PPMLORA01 et PS1LORA01, ' ,
                      'sinon si fin du nouveau primaire se termine par ORA1 alors dans VTOM switcher les machines physiques des machines logiques BPMLORA01 et BS1LORA01' );
 
        $message .= outlook_encode ( $_ ) . "\n" foreach @t_str;
        $message .= $r_h_env->{'dash132'} . "\n" ;
 
        $message .= outlook_encode ( $_ ) . "\n" foreach @$r_t_chg;
        $message .= "\n";
    }
 
    my $msg = MIME::Lite->new(
        From     => $from,
        To       => $to,
        Cc       => $cc,
        Subject  => $subject,
        Type     => 'multipart/mixed'
    );
 
    $msg->attach(Type => 'text',
                 Data => $message,
    );
 
#    $msg->attr('content-type.charset' => 'CP1252');
 
    $msg->send;
 
}

[magicshark]

Bonjour concernant l'encodage je n'en ai pas la moindre idée, je ne supporte pas outlook (choix personnel )
Cependant, pour le off-topic
il serait intéressant de voir se que print tes boucles

essaye ça et post le retour stp :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
 
sub send_mail {
    my ( $r_log, $r_h_env, $r_t_new ,$r_t_del, $r_t_chg ) = @_;
 
    my $to   = 'xxx@yyy';
    my $cc   = 'xxx@yyy, xxx@yyy';
    my $from = 'xxx@yyy';
 
    my $subject = 'Action Production - Interventions ODA';
    my $message;
 
    if ( scalar(@$r_t_new) > 0 ) {
        my $str   = 'Nouvelles entrées oratab => Créer traitements VTOM de sauvegardes';
        $message .= outlook_encode ( $str ) . "\n" . $r_h_env->{'dash132'} . "\n" ;
        $message .= outlook_encode ( $_ ) . "\n" foreach @$r_t_new;
        $message .= "\n";
    }
 
    if ( scalar(@$r_t_del) > 0 ) {
        my $str   = 'Entrées oratab manquantes => Désactiver ou supprimer traitements VTOM correspondants';
        $message .= outlook_encode ( $str ) . "\n" . $r_h_env->{'dash132'} . "\n" ;
        $message .= outlook_encode ( $_ ) . "\n" foreach @$r_t_del;
        $message .= "\n";
    }
 
    if ( scalar(@$r_t_chg) > 0 ) {
 
        my @t_str = ( 'Statut changé pour entrées oratab' ,
                      'Si fin du nouveau primaire se termine par ORA0 alors dans VTOM switcher les machines physiques des machines logiques PPMLORA01 et PS1LORA01, ' ,
                      'sinon si fin du nouveau primaire se termine par ORA1 alors dans VTOM switcher les machines physiques des machines logiques BPMLORA01 et BS1LORA01' );
 
        $message .= outlook_encode ( $_ ) . "\n" foreach @t_str;
        $message .= $r_h_env->{'dash132'} . "\n" ;
 
        $message .= outlook_encode ( $_ ) . "\n" foreach @$r_t_chg;
        $message .= "\n";
        print '---------------------TEST-----------------------';
        print outlook_encode ( $_ ) . "\n" foreach @$r_t_chg;
        print outlook_encode ( $_ ) . "\n" foreach @t_str;
        print '-------------------FIN TEST---------------------';
    }
 
    my $msg = MIME::Lite->new(
        From     => $from,
        To       => $to,
        Cc       => $cc,
        Subject  => $subject,
        Type     => 'multipart/mixed'
    );
 
    $msg->attach(Type => 'text',
                 Data => $message,
    );
 
#    $msg->attr('content-type.charset' => 'CP1252');
 
    $msg->send;
 
}

j'ai voulu respecter les unilignes mais je peux me tromper méaculpa par avance.

Si ce n'est pas fait ajoute

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
use strict;
use warnings;

au début du code pour avoir des indications supplémentaires.

[Lolo78]

Bonjour,

bien souvent, Outlook se permet de retirer les sauts de lignes qu'il juge inutiles, au moins sur les messages au format texte. Dans ce cas, il le signale (discrètement) au-dessus du message et on peut faire un clic droit pour obtenir un mini-menu contextuel permettant de les rétablir.

Peut-être que mettre des sauts de lignes "Windows" ('\r\n') suffit à résoudre le problème, je ne me souviens plus.

Sinon, il n'y a pas de problème si le message est au format HTML, dans ce cas, le format est préservé. Ce peut donc être une solution, même si c'est plus contraignant.

[ptonnerre]

Bonjour,

merci à magicshark et Lolo78 pour leurs réponses.

@magicshark
ton test marche bien pour la sortie standard, mais la concaténation dans $message qui est utilisé dans le mail, le résultat est identique

@Lolo78
les tests utilisant \r\n ne donnaient pas de meilleurs résultats.
Tu as raison pour le comportement d'Outlook qui supprime de l'affichage des sauts de lignes inutiles et le signale au-dessus du message.
Tu peux effectivement les restaurer.
Après explications, cette solution a été acceptée.

Par contre, je suis toujours preneur d'avis et commentaires sur ma question concernant l'encodage.

Merci

[Artemus24]

Salut à tous.

Lorque vous dites que vous devez gérer l'aspect encodage, est-ce au niveau du perl ou au niveau du message ?
Le choix de l'encodage dépend surtout de ce que outlook sait gérer afin d'avoir aucun problème avec les accents.

Pour le choix du charset, j'ai utilisé l'en-tête suivante dans la génération de message vers outlook :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

$headers .= "Content-Type: text/plain; charset=\"iso-8859-1\"\n";

Il faut dire que j'ai fait cela depuis un script php. Il y a juste l'habillage qui sera different, mais le principe reste le même.
Pourquoi ce charset ? Je n'utilise que l'anglais et le français. Et puis tant pis pour le caractère '€' qui n'est pas présent dans ce charset.

Mettre CP1252 est une erreur car ce n'est pas le bon nom du charset qui est windows-1252.
De plus, windows-1252 n'existe que sous windows et pas ailleurs, le plus proche étant ISO-8859-1.
C'est pourquoi, j'ai utilisé ISO-8859-1 pour la codification

Je n'ai pas bien compris si vos messages sont des messages simple (uniquement du texte) ou de type html, avec image, couleur, choix de la police de caractères ...

Si ce sont de messages simple (uniquement du texte), dans l'en-tête, il faut préciser "Content-Type: text/plain".
Si ce sont des messages de type html, mettre alors "Content-Type: text/html".

Si vous choisissez ISO-8859-1, ne pas oublier de préciser ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Content-transfer-encoding: 8BIT

Peut-être que mettre des sauts de lignes "Windows" ('\r\n') suffit à résoudre le problème, je ne me souviens plus.

C'est exacte. Pour windows, il faut mettre '\r' pour "carriage return" et '\n' pour "new line".
Ne pas oublier que ces caractères de contrôle ont été inventé pour gérer des imprimantes qui fonctionnaient comme des machines à écrire.
Autrement dit "carriage return" permet de faire revenir le rouleau dans sa position d'origine, à gauche.
Et "new line", de faire faire à ce rouleau une rotation afin d'écrire sur la ligne suivante.
On comprend alors que Windows respecte la norme à l'inverse de Linux qui ne préconnise que de mettre "new line".

Pour le saut de ligne, que vous n'arrivez pas à gérer, il faut savoir que :
1) pour les messages de type text, c'est "\n".
2) pour les messages de type html, il s'agit de la balise "<br />".

--> http://articles.mongueurs.net/magazines/linuxmag60.html

@+

[Lolo78]

C'est exacte. Pour windows, il faut mettre '\r' pour "carriage return" et '\n' pour "new line".
Ne pas oublier que ces caractères de contrôle ont été inventé pour gérer des imprimantes qui fonctionnaient comme des machines à écrire.
Autrement dit "carriage return" permet de faire revenir le rouleau dans sa position d'origine, à gauche.
Et "new line", de faire faire à ce rouleau une rotation afin d'écrire sur la ligne suivante.
On comprend alors que Windows respecte la norme à l'inverse de Linux qui ne préconnise que de mettre "new line".

Euh, c'est plutôt Linux qui respecte la norme, et Windows qui ne la respecte pas...

Unix a vu le jour au début des années 1970, DOS au début des années 1980 et Windows dans les années 1990.

Microsoft a voulu fabriquer des fichiers avec un encodage qui ressemblait à celui des téléscripteurs (ou télex), un système de transmission et d'impression électromécanique (codé sur 5 bits) datant des années 1930, alors que ça n'avait plus aucune raison d'être pour des fichiers informatiques, pour lesquels il aurait fallu séparer la problématique d'encodage des fichiers de celle de leur impression. Ce choix mal pensé de Microsoft nous pourrit encore la vie 35 ans plus tard, et ce n'est sans doute pas près de s'arrêter.

Cela me rappelle l'anecdote (réelle ou inventée, je ne sais, mais ô combien savoureuse) de la distance entre deux rails de chemins de fer qui serait dérivée de la taille du cul des bœufs utilisés pour tracter des chariots sur les voies romaines du premier siècle avant JC.

[ptonnerre]

Bonjour,

le but est bien d'envoyer des messages au format 'texte' qui seront lus avec un client Outlook.

Après lecture de la doc du module Mime::Lite j'ai simplifié mon code en enlevant l'attribut multipart et en choisissant le charset latin1 dans la fonction outlook_encode :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    if ( scalar(@$r_t_chg) > 0 ) {
 
        my @t_str = ( 'Statut changé pour entrées oratab' ,
                      'Si fin du nouveau primaire se termine par ORA0 alors dans VTOM switcher les machines physiques des machines logiques PPMLORA01 et PS1LORA01, ' ,
                      'sinon si fin du nouveau primaire se termine par ORA1 alors dans VTOM switcher les machines physiques des machines logiques BPMLORA01 et BS1LORA01' );
 
        $message .= outlook_encode ( $_ ) . "\n" foreach @t_str;
        $message .= $r_h_env->{'dash132'} . "\n" ;
 
        $message .= outlook_encode ( $_ ) . "\n" foreach @$r_t_chg;
        $message .= "\n";
    }
 
    my $msg = MIME::Lite->new(
        From     => $from,
        To       => $to,
        Cc       => $cc,
        Subject  => $subject,
        Data     => $message
    );
 
    $msg->send;
 
}
 
 
sub outlook_encode {
    my ( $string ) = @_;
    return encode ( 'ISO-8859-1', (decode ('UTF-8', $string ))  );
}

Tout fonctionne parfaitement.

Mon interrogation est plus centrée sur la méthode que j'utilise : j'ai une chaîne de caractères dans mon code, qui est en UTF-8, je la décode dans ma fonction outlook_decode et elle est donc au format interne de Perl, et ensuite je l'encode en latin1 pour la constitution du mail.

Est-ce la bonne façon de procéder ? Quel est le format interne de Perl ?

Merci pour vos lumières.

[Lolo78]

Mon interrogation est plus centrée sur la méthode que j'utilise : j'ai une chaîne de caractères dans mon code, qui est en UTF-8, je la décode dans ma fonction outlook_decode et elle est donc au format interne de Perl, et ensuite je l'encode en latin1 pour la constitution du mail.

Oui, c'est l'idée

Est-ce la bonne façon de procéder ?

A priori, oui, et si ça marche comme tu le souhaites, eh bien ça confirme.

Le format interne de Perl est, je crois, une représentation proche de l'UTF-8.

[Artemus24]

Salut à tous.

@ ptonnerre : Latin1, c'est l'ancien nom de l'ISO-8859-1.
--> https://fr.wikipedia.org/wiki/ISO/CEI_8859-1

Le nom du charset dépend de votre environnement.
Sous MySql, c'est latin1, tandis que dans un document HTML, c'est "ISO-8859-1".
C'est ce qui est le plus proche de windows-1252.

j'ai une chaîne de caractères dans mon code, qui est en UTF-8

Ce qui me dérange le plus, ce sont les conversions inutiles. Je préfère de loin que vous fassiez tout dans le même charset.
Si vous n'avez pas le choix du charset de votre chaîne de caractères, dès le départ, autant rester en UTF-8 de bout en bout.

Est-ce la bonne façon de procéder ?

Il n'y a pas de bonnes ou de mauvaises méthodes. Il y a juste des contraintes qui vous sont imposées et que vous devez faire avec.
Outlook sait gérer l'UTF-8, donc pourquoi ne pas tout faire en UTF-8 ?

Quel est le format interne de Perl ?

Je pense que cela dépend de votre environnement.
Je suis sous Windows 10 Pro, et mes scripts Perl, je les encode en "Windows-1252".
Je peux aussi les encoder en UTF-8, mais je n'ai aucun usage de ce charset, qui je le rappelle, occupe plus de place puisqu'il se code sur 1, 2 ou 3 octets, à l'inverse de Windows-1252 qui est sur 1 seul octet.

Sinon, pourquoi mettre le caractère de contrôle à l'extérieur du message ?
Il est certain que sa codification ne va pas changer car il appartient à la table ASCII (<=127) et ne subira aucun changement.

@ Lolo78 : oui, mais l'informatique existait bien avant Unix.
Et à ma connaissance, vu que j'ai fait toute ma carrière sur des machines IBM et BULL sous gros système, ces deux caractères ont leur raison d'être, comme je l'ai indiqué précédemment.
Maintenant, je reconnais que continuer à se trimballer des contraintes qui n'ont plus aucune raison d'être, sous le prétexte de la compatibilité ascendante, n'est plus justifié aujourd'hui.
Donc, je ne saurai répondre qui à tort ou qui à raison, mais faut faire avec, comme on dit !

Ce dont vous parlez, c'est le code Baudot qui se code sur cinq bits et ne date pas des années 1930, mais plutôt de 1874, dans sa première forme.
Ce code a été remanipulé à plusieurs reprises, et l'on retrouve des traces de ce code dans l'EBCDIC.
--> https://fr.wikipedia.org/wiki/Code_Baudot

alors que ça n'avait plus aucune raison d'être pour des fichiers informatiques

Pour des fichiers, oui, mais que faites vous des périphériques qui parfois sont associés à ces fichiers ?
Les périphériques propriétaires sont de moins en moins présentes dans les entreprises, et votre remarque peut se justifier car, je suppose, que vous travaillez exclusivement sous Linux.

il aurait fallu séparer la problématique d'encodage des fichiers de celle de leur impression.

Et comment faire cette séparation, puisque c'est le fichier qui sera interprété par le périphérique ?
Vous soulevez alors la question de deux codifications, l'une disons pour le stockage et l'autre pour son exécution. C'est pas très performant comme approche.
D'ailleurs, ma remarque concernant le charset en est un exemple. Pourquoi travailler en UTF-8 pour ensuite codifier en ISO-8859-1 ?
Vous allez passer votre temps à convertir, et sur ce point, je ne suis pas du même avis que vous.

Sinon sur le fond, oui, je suis d'accord car si l'on peut simplifier les traitements, je suis preneur.
Mais là, ce n'est pas nous qui décidons, mais bien les constructeurs de matériels qui préfèrent utiliser des normes propriétaires.
Vous avez oublier la dimension commerciale qui n'est pas faire pour nous simplifier la vie !

@+

[Lolo78]

Ce qui me dérange le plus, ce sont les conversions inutiles. Je préfère de loin que vous fassiez tout dans le même charset.
Si vous n'avez pas le choix du charset de votre chaîne de caractères, dès le départ, autant rester en UTF-8 de bout en bout.

En interne, Perl stocke les chaînes de caractères sous une forme correspondant à l'UTF-8, et ce depuis au moins une dizaine d'années.

Et, non, ça ne prend pas vraiment beaucoup plus de place si les caractères sont dans leur très grande majorité des caractères du jeu ASCII 128 bits (ce qui est généralement le cas au moins dans nos langues européennes).

Je suis comme tout le monde (ou presque), je déteste les problématiques de conversion associées à l'Unicode, mais il faut bien s'y faire, Unicode se généralise et est là pour durer un bon moment.

Ce dont vous parlez, c'est le code Baudot qui se code sur cinq bits et ne date pas des années 1930, mais plutôt de 1874, dans sa première forme.
Ce code a été remanipulé à plusieurs reprises, et l'on retrouve des traces de ce code dans l'EBCDIC.
--> https://fr.wikipedia.org/wiki/Code_Baudot

Euh, non, pas vraiment, je ne parlais pas trop du code Baudot, mais plutôt des téléscripteurs qui datent des années 1930 (même si, bien sûr, ils utilisaient une version modifiée du code Baudot). A ma connaissance, ce sont les téléscripteurs, et non le code Baudot en tant que tel, qui ont amené l'utilisation de deux caractères de contrôle pour les sauts de ligne.

Pour des fichiers, oui, mais que faites vous des périphériques qui parfois sont associés à ces fichiers ?
Les périphériques propriétaires sont de moins en moins présentes dans les entreprises, et votre remarque peut se justifier car, je suppose, que vous travaillez exclusivement sous Linux.

L'époque où les fichiers texte contenaient les caractères de contrôle pour les imprimantes (ou les modems ou autres périphériques) est révolue depuis longtemps (et Dieu merci, car il fallait alors créer des fichiers différents pour chaque périphérique). Les drivers sont là pour cela de nos jours et l'on peut travailler à un niveau d’abstraction supérieur, indépendant du périphérique employé.

Je travaille sur Unix (HP-UX, AIX), soius Linux (RHEL), sous VMS, sous Windows, un peu sous AS-400 et, parfois, je dois même récupérer des données gros systèmes (MVS ou autres) codées en EBCDIC. Donc pas du tout exclusivement du Linux (malheureusement).

Et comment faire cette séparation, puisque c'est le fichier qui sera interprété par le périphérique ?
Vous soulevez alors la question de deux codifications, l'une disons pour le stockage et l'autre pour son exécution. C'est pas très performant comme approche.

Bof, de toutes façons, il y a toujours conversions de format de nos jours au moment de l'impression. Un processeur actuel travaille probablement des millions de fois plus vite qu'une imprimante, ça n'a pas vraiment d'importance. Et c'est fondamentalement bien plus satisfaisant de séparer le contenu du fichier des caractères de contrôle qui fonctionneront avec un périphérique et pas avec un autre. Encore une fois, il y a les drivers pour piloter les périphériques (et je ne parle pas du fait que les imprimantes ont aussi depuis bien longtemps leur propre processeur qui font aussi toutes sortes de manipulations des données reçues).

Sur l'encodage des caractères en Perl, l'Unicode, l'UTF-8, etc. voir ce très bon article écrit par l'un des meilleurs connaisseurs français des entrailles de Perl:
https://perl.developpez.com/tutoriel...e-guide-perl5/

[Artemus24]

Salut Lolo78.

En interne, Perl stocke les chaînes de caractères sous une forme correspondant à l'UTF-8, et ce depuis au moins une dizaine d'années.

Je ne parlais pas de comment travaille Perl en interne.

Je parlais d'une part du charset utilisé pour les script Perl (chez moi, j'utilise Notepad++ avec l'encodage ANSI (c'est windows-1252)).
Et d'autre part, l'affichage, c'est-à-dire la façon dont les caractères seront interprétés par la console Windows.
Bien que la console soit appelée par l'utilitaire "perl.exe", elle reste la console batch windows, qui est la même que celle que l'on lance en tapant "cmd" dans le bouton 'exécuter...".

Chez moi, j'ai préféré utilisé Windows-1252 comme charset, aussi bien pour la console que pour le stockage des scripts perl et cela me simplifie grandement la vie.
Donc aucune conversion à faire !

Et, non, ça ne prend pas vraiment beaucoup plus de place si les caractères sont dans leur très grande majorité des caractères du jeu ASCII 128 bits (ce qui est généralement le cas au moins dans nos langues européennes).

Sauf qu'aujourd'hui, plus personne ne travaille exclusivement qu'avec de l'ASCII.
Il arrive fréquemment dans les bases de données que l'utilisateur croyant bien faire, utilise le charset utf-8 et se retrouve avec quelques problèmes.
Entre autre, la méconnaissance de la taille réelle d'une chaîne de caractères en UTF-8 dans le stockage d'une colonne.
Les problèmes de collation, c'est-à-dire la façon de classer les caractères pour les tests de comparaisons.
Et je ne parle même pas des problèmes récurrents de l'affichage des caractères diacritiques !
Alors que si, de bout en bout, l'utilisateur utilisait le même charset, il n'aurait pas des problèmes de conversions à résoudre.

Je suis comme tout le monde (ou presque), je déteste les problématiques de conversion associées à l'Unicode, mais il faut bien s'y faire, Unicode se généralise et est là pour durer un bon moment.

Ce n'est pas un problème d'unicode, mais juste un problème de paramétrage dont l'utilisateur ne sait pas résoudre.

A ma connaissance, ce sont les téléscripteurs, et non le code Baudot en tant que tel, qui ont amené l'utilisation de deux caractères de contrôle pour les sauts de ligne.

Le telex, c'est un ruban en continue. Le télétype, c'est comme une machine à écrire, dont par exemple, les imprimantes à boule IBM 82.
La séparation entre remettre le rouleau le plus à gauche (carriage return) et le faire tourner d'un cran (line feed) provient du fonctionnement des machines à écrire mécaniques.

L'époque où les fichiers texte contenaient les caractères de contrôle pour les imprimantes (ou les modems ou autres périphériques) est révolue depuis longtemps (et Dieu merci).

Oui, je suis d'accord, mais voilà, les ordinateurs ont été conçus avec cette technique. C'est ce que l'on nomme la compatibilité ascendante !
Le cas le plus flagrant, ce sont les processeurs 64 bits qui doivent encore pouvoir traiter du 32 bits, voire du 16 bits !
Si sur le fond, je suis d'accord, il faut faire avec, sinon beaucoup de périphériques seraient inutilisables aujourd'hui.

Les drivers sont là pour cela de nos jours et l'on peut travailler à un niveau d’abstraction supérieur, indépendant du périphérique employé.

Pour l'interprétation, oui, les drivers servent à faire le lien entre l'ordinateur et les périphériques.
Mais sinon, comment faites-vous pour indiquer un saut de ligne, un saut de page, afficher en gras ...
Il faut bien un pseudo langage qui va gérer sous forme de caractères de contrôles ce que l'on désire faire au final sur une imprimante.
La plus part du temps, et surtout avec le traitement de texte, tout cela est transparent pour l'utilisateur.
Mais ce pseudo langage existe bel et bien.

Un processeur actuel travaille probablement des millions de fois plus vite qu'une imprimante, ça n'a pas vraiment d'importance.

Oui, mais cela ne change rien car cette séparation existe bien, même si c'est le driver, qui en parti, gère cela.

Et c'est fondamentalement bien plus satisfaisant de séparer le contenu du fichier des caractères de contrôle qui fonctionneront avec un périphérique et pas avec un autre.

Cela simplifie grandement le travail du développeur car il n'a pas à gérer physiquement le périphérique qu'il désire piloter.
Jadis, on ne pouvait pas faire autrement que de connaitre le fonctionnement de chaque périphérique.

Et d'ailleurs, qui travaille encore en assembleur de nos jours ?

@+

[ptonnerre]

Cette discussion est très intéressante, et moi aussi j'aimerai utiliser le même charset de bout en bout.
Hélas, je travaille dans un organisme où nous avons des vieux GCOS, du Windows, de l'Aix et du Linux (RHEL).
Ce dernier est en train de prendre le pas progressivement sur les autres OS, mais les migrations prennent du temps, beaucoup de temps.
Donc pour l'instant, nous avons des chaines de traitements hétérogènes qui récupère les sorties de telle plateforme, qui deviennent les entrées d'une autre, qui doivent envoyer des rapports par mail, faire des stats pour une autre plateforme...
Bref, on échange dans tous les sens et nous sommes obligés de gérer les encodages