Séquence d'échappement ANSI
En télématique, les séquences d'échappement ANSI permettent de contrôler le formatage du texte dans un périphérique graphique (terminal informatique, téléscripteur ou imprimante). Pour encoder cette information de formatage, certains caractères sont insérés dans le texte et interprétés par le terminal non comme des caractères, mais comme des commandes[1].
Successeurs des codes propriétaires des années 1960 (EBCDIC d'IBM notamment), les codes ANSI sont apparus dans les années 1970, et leur usage s'est répandu dans le marché informatique au début des années 1980.
Bien que les terminaux physiques en mode texte soient devenus rares au début du XXIe siècle, les codes ANSI restent utilisés dans les émulateurs de terminaux.
Historique
Vers le milieu des années 1960, pratiquement tous les fabricants de terminaux vidéo les ont pourvus en ROM de séquences d'échappement pour réaliser les opérations graphiques les plus élémentaires, à savoir effacer l'écran et déplacer le curseur à une position quelconque de l'écran. Dans le cas du terminal VT52, on plaçait le curseur à l'intersection de la colonne x et de la ligne y en tapant ou en imprimant en mémoire vidéo le code ASCII ESC, puis Y et les deux chiffres donnant le numéro de colonne x, et le numéro de ligne y (plus 32, conformément au codage ASCII qui démarre la liste des chiffres à partir du code 32). La console Hazeltine 1500 ne fonctionnait pas différemment : au lieu du code ESC, il fallait taper ~, DC1 puis les coordonnées d'écran X et Y séparées par une virgule. Ainsi, pour une même fonctionnalité, ces deux terminaux utilisaient des séquences de contrôle différentes.
Les terminaux en mode texte étaient presque tous monochromes, de sorte que le codage informatique des couleurs a été progressif : un groupe de codes ANSI, le Select Graphic Rendition Subset, s'est limité dans un premier temps à un codage sur 4 bits, soit 16 couleurs (noir, rouge, vert, jaune, bleu, magenta, cyan, gris clair, gris foncé, rouge clair, vert clair, jaune citron, cobalt, magenta clair, cyan clair, blanc), qui était celui pris en charge par la première carte graphique couleur[2], la carte CGA d'IBM (1981).
La disparité des séquences de contrôle d'un fabricant à l'autre a suscité le développement de bases de données de conversion comme termcap ("terminal capabilities"), et de scripts comme tput de façon à permettre aux programmes d'utiliser une API compatible avec tous les terminaux. En outre, sur plusieurs de ces terminaux, les nombres de la séquence de contrôle (le numéro de ligne et de colonne) devaient être convertis en code octal ; pour certains langages de programmation, et pour les ordinateurs qui n'intégraient pas les codes ASCII, la conversion d'un nombre en code octal devait être traitée explicitement par l'utilisateur.
La norme ANSI s'efforçait de traiter ces problèmes en prescrivant une liste de commandes primitives accessibles sur tous les terminaux, dont les arguments numériques devaient être codés avec les codes ASCII des chiffres. La première des normes ANSI de ce genre est ECMA-48, adoptée[3] en 1976. Elle complétait une série de normes bureautiques, la plus ancienne étant l'ECMA-6 de 1965, norme utilisant une table de 128 codes à 7 bits, et qui est le point de départ de la norme ISO 646. L’appellation "ANSI escape sequence" remonte à l'année 1979, qui est celle où l'ANSI a promulgué la norme ANSI X3.64. La commission ANSI X3L2 avait collaboré avec le groupe technique 1 de la commission ECMA pour parvenir à un codage pratiquement uniforme. Ces deux normes ont fusionné ensuite pour aboutir à la norme internationale ISO 6429[3], finalement adoptée en 1994 par l'ANSI.
Le premier terminal vidéo à reconnaître les séquences de contrôle d'écran était le DEC VT100, commercialisé en 1978[4]. Ce modèle bénéficia d'une grande faveur auprès des entreprises, et connut une multitude de versions bon marché concurrentes, à commencer par la Zenith Z-19[5] en 1979. Parmi les autres consoles, il faut principalement citer la QVT-108 de Qume, la TVI-970 de Televideo, la WY-99GT de Wyse, et toutes les consoles dotées de modes optionnels VT100, VT103 ou ANSI plus ou moins compatibles. Le succès rencontré par ces matériels auprès du public (surtout grâce à l'application bulletin board system et à d'autres services en ligne rendus possibles par la mise en place d'un réseau local), directement lié à la prise en charge des caractères d'échappement, a imposé à tous les terminaux et émulateurs d'interfaces d'incorporer la reconnaissance de ces mêmes caractères.
En 1981, le Bulletin d'information des normes bureautiques n°86 du gouvernement fédéral américain annonçait l'adoption de sa propre norme ANSI X3.64 pour les caractères d'échappement mais, confronté à un risque d’incompatibilité avec les standard informatiques déjà prévalents, il dut l'abandonner peu après[6].
Le standard ECMA-48 a été mis à jour à de nombreuses reprises et en était en 1991 à sa 5e édition. Il a été intégré aux normes ISO et IEC comme norme ISO/IEC 6429[7] et par le Japanese Industrial Standard avec la norme JIS X 0211. D'autres normes l'ont intègré à peu de changements près : le standard pour téléscripteurs ITU T.61, la norme européenne Télétex et l’ISO/IEC 8613, enfin l’Open Document Architecture (surtout ISO/IEC 8613-6 ou ITU T.416). Les différences ponctuelles n'affectaient d'ailleurs pas le comportement graphique des terminaux eux-mêmes. Quoique ces standards soient depuis tombés en désuétude, l'ECMA-48 a conservé les codes réservés à leurs extensions particulières.
Disponibilité selon la plate-forme
Sur plate-forme Unix
Bien que les bibliothèques logicielles du type termcap/terminfo aient été conçues initialement pour et sur plates-formes Unix[8] - [9], au milieu des années 1980, les programmes fonctionnant sur les systèmes d'exploitation de type Unix présupposaient presque tous que le terminal ou l'émulateur auquel ils étaient destinés reconnaissait les séquences de contrôle ANSI : c'était le cas de nombreux jeux et applicatifs fonctionnant en mode semi-graphique. On ne pouvait donc les utiliser sur des terminaux n'interprétant pas les codes d'échappement. Aujourd'hui, un grand nombre de programmes, y compris les éditeur de texte comme vi et GNU Emacs, emploient termcap ou terminfo, ou recourent à des bibliothèques logicielles comme curses, qui s'appuie sur la base de données termcap ou terminfo : de ce fait, il ne peuvent plus tourner sur les vieilles consoles qui n'intégraient pas les codes ANSI ; mais il est très rare d'utiliser aujourd'hui ces anciens matériels.
Les émulateur de terminaux, qui permettent de lancer et d'éditer des programmes en même local, utilisent presque tous les codes d'échappement ANSI, de même que les consoles. Citons par exemple les émulateurs de terminal xterm, rxvt, GNOME Terminal et Konsole pour les environnements de bureau basés sur X11 ou Wayland ; Terminal.app et quelques autres émulateurs indépendants comme iTerm2 sur les plates-formes macOS.
Une longue résistance : DOS, OS/2 et Windows
MS-DOS 1.x ne reconnaissait ni les codes ANSI, ni même aucune séquence d'échappement : ce n'est que parce que la couche BIOS sous-jacente les décodait, qu'un petit nombre de caractères de contrôle (l'alerte sonore, le retour chariot, le saut de ligne, le retour arrière) étaient reconnus, de sorte qu'il était pratiquement impossible[note 1] de produire la moindre application semi-graphique sur de tels appareils. Les quelques effets graphiques disponibles requéraient soit un appel au BIOS, qui était à l’époque réputé pour sa relative lenteur, soit un programme en assembleur ou langage machine IBM.
DOS 2.0 a ménagé la possibilité d'intégrer un pilote de décodage des codes ANSI – le standard étant de facto ANSI.SYS, mais avec possibilité d'utiliser ad libitum ANSI.COM[10], NANSI.SYS[11] ou ANSIPLUS.EXE (ces deux-là étant nettement plus rapides, car ils court-circuitaient le BIOS). Malgré cela, une certaine lenteur et le fait que l'utilisateur devait installer lui-même le pilote, ont dissuadé les éditeurs de logiciels plein-écran de s'en servir ; les développeurs de jeux vidéo et d'applications continuaient d'adresser directement la mémoire vidéo en langage machine. ANSI.SYS et les pilotes du même genre ont continué d'être supportés sur Windows 95, Windows 98, Windows ME et les versions dérivées de Windows NT pour les programmes en mode 16-bits tournant sous NTVDM.
Plusieurs émulations de DOS reconnaissaient les caractères de contrôle et évitaient de devoir charger un pilote ANSI : PTS-DOS[12] - [13] de même que Concurrent DOS, Multiuser DOS[14] et REAL/32 comportent une aide en ligne (et diverses extensions). OS/2 comporte une commande ANSI qui interprète les séquences de contrôle.
La console Windows ne reconnaissait aucune séquence d'échappement, et Microsoft ne fournissait aucune méthode pour y parvenir. Certains substituts de la console Windows, tels TCC (anciennement 4NT) de JP Software, ANSI.COM de Michael J. Mefford, ANSICON[15] de Jason Hood et ConEmu de Maximus5 interprétaient les séquence de contrôle ANSI imprimées par programme. Une bibliothèque logicielle Python[16] réalisait une opération similaire, de façon à faciliter le portage de programmes Python semi-graphiques sous Windows. Pour porter les codes POSIX C sous Windows, Cygwin intègre un interpréteur de séquences d'échappement pour convertir les frappes clavier sous la console Windows : cet interpréteur utilise des descripteurs de fichier Cygwin, et le rendu est assuré grâce aux primitives graphiques de cygwin1.dll.
En 2016, Microsoft a déployé la version 1511 de Windows 10, qui, pour la première fois depuis le lancement de Windows NT, reconnaît les séquences de contrôle ANSI[17]. Ce développement a été réalisé en parallèle de celui de Windows Subsystem for Linux, permettant aux applications pour console type Unix d'exploiter les séquences de contrôle des jeux et applications pour Windows. Il est malheureusement désactivé par défaut, mais fonctionne sous Windows PowerShell 5.1. PowerShell 6 permet enfin d'utiliser le caractère ESC dans une chaîne grâce au code `e[18].
Windows Terminal, mis sur le marché en 2019, accepte par défaut les séquences d'échappement ANSI, et Microsoft a annoncé son intention de remplacer la console Windows par Windows Terminal[19].
Atari ST
L'Atari ST, au lieu des séquences ANSI proprement dites, utilisait un jeu de commandes inspiré de celui du terminal VT52 à quelques extensions propriétaires près pour la prise en charge des couleurs[20].
AmigaOS
Le système d'exploitation AmigaOS utilise les séquences de contrôle ANSI non seulement pour l'affichage à l'écran, mais aussi pour le formatage des pages via le pilote d'impression de l'imprimante (à quelques extensions propriétaires près)[21].
| Effet | |
|---|---|
| (tt) n u | fixe à n le nombre de lignes d'une fenêtre. |
| (tt) n t | fixe à n le nombre maximum de lignes d'une fenêtre. |
| (tt) n x | Place le pointeur de texte à n pixels depuis le bord gauche d'une fenêtre. |
| (tt) n y | Place le pointeur de texte à n pixels depuis le bord supérieur d'une fenêtre. |
Notes et références
- « Affichage en couleur sur le terminal — documentation Sokoban 0.9.2.0 », sur chamilo.univ-grenoble-alpes.fr (consulté le )
- Jim Hall, « About ncurses Colors », Linux Journal, (lire en ligne)
- « Standard ECMA-48: Control Functions for Character-Imaging I/O Devices », sur Ecma International, , Brief History
- Paul Williams, « Digital's Video Terminals », sur VT100.net, (consulté le )
- Heathkit Company, « Heathkit Catalog 1979 », sur Heathkit Company, (version du 13 janvier 2012 sur Internet Archive)
- « Withdrawn FIPS Listed by Number », sur National Institute of Standards and Technology,
- « Standard ECMA-48: Control Functions for Coded Character Sets »,
- D'après Peter H. Salus, « The history of Unix is as much about collaboration as it is about technology », Byte, (lire en ligne).
- Cf. Arnold Amir et Elan Amir, Screen Updating and Cursor Movement Optimization: A Library Package, C.R.C. Press (lire en ligne)
- Michael Mefford, « ANSI.com: Download It Here », PC Magazine, (lire en ligne)
- Dan Kegel et Eric Auer, « Nansi and NNansi – ANSI Drivers for MS-DOS », sur Dan Kegel's Web Hostel, (consulté le )
- « PTS-DOS 2000 Pro User Manual », sur Paragon Technology GmbH, (sur Internet Archive)
- (de) Jens Günther, Tobias Ernst et Wolfgang Ellsässer, « Inoffizielle deutschsprachige PTS-DOS-FAQ (PTS/FAQD) », (consulté le )
- CCI Multiuser DOS 7.22 GOLD Online Documentation, Concurrent Controls, Inc. (CCI),
- Jason Hoodb, « Process ANSI escape sequences for Windows console programs », sur Jason Hood's Home page, (consulté le )
- « colorama 0.2.5 », sur Python Package Index (consulté le )
- (en-US) bitcrazed, « Console Virtual Terminal Sequences - Windows Console », sur docs.microsoft.com (consulté le )
- (en) « PowerShell Help: About Special Characters », sur Microsoft,
- « Windows Console and Terminal Ecosystem Roadmap », sur Microsoft, (consulté le ) : « this includes retiring the classic console host user interface from its default position in favor of Windows Terminal, ConPTY, and virtual terminal sequences. »
- (en) « Printer and terminal escape codes », sur Concise Atari ST 68000 Programming Guide (version du 20 septembre 2016 sur Internet Archive)
- « Amiga Printer Command Definitions », sur Commodore (consulté le )
- « Escape Sequence - OpenVMS Wiki », sur VMS Software
- Le rafraîchissement d'écran se faisait en redessinant le contenu ligne à ligne sur la dernière ligne en bas de l'écran, et en comptant sur le défilement automatique, qui repoussait les premières lignes hors de l'écran, vers le haut jusqu'à remplacer les 32 lignes de l'écran. L'utilisateur voyait l'écran défiler, et le curseur était en butée dans le coin inférieur droit de l'écran. Certains programmes d'arrière-plan réalisaient un affichage plein écran rudimentaire de cette façon.