Jump to content

Publications recommandées

Ceci est en fait une page wiki GitLab interne à destination d'un groupe de travail, formatée en Markdown.
(il y a t'il un moyen de le convertir automatiquement dans l'encodage du forum?)
Je me suis dit que ces informations pourraient être intéressantes à d'autres personnes.

(Par contre soyez indulgents s'il vous plaît, ce n'est que la version 0.2.)

# TL;DR (*Too Long ; Didn't Read*) (Pré-Introduction)  

Imaginez le raisonnement suivant  que vous pourriez vous faire :  

"Le [Zen de Python (PEP20)](https://openclassrooms.com/courses/manipulez-des-donnees-avec-python-1/devenez-zen-avec-la-pep-20) dit :  
1.) Le beau est préférable au laid.  
7.) La lisibilité compte.  
Les deux premières phrases (passé l'introduction) de [PEP 8 — the Style Guide for Python Code](https://pep8.org/), insistent sur la lisibilité du code, qui est lu beaucoup plus souvent qu'écrit."  

"Je bosse (par exemple) avec des unités du système international,  
où la lettre grecque mu : "µ" désigne les micro-mètres/litres/etc.  "

"Et depuis Python 3.x(?*TODO*), non seulement les fichiers .py sont en Unicode, et il gère les chaînes de caractères en Unicode par défaut, mais en plus les noms de variables peuvent être en toute sorte de caractères Unicode (en dehors de l'ASCII) !"

"Alors je me dis : "Pourquoi ne pas directement mettre µ dans une variable, par exemple "size_µm" ?  
C'est quand même plus clair et beau que "size_um" et plus court que "size_micrometers" !  "

"En plus ce symbole "µ" est directement sur mon clavier, à côté de la touche "Entrée", et est d'ailleurs bien plus accessible par SHIFT+* que les les "{[@]}" qui demandent Ctrl+Alt+ ou AltGr+ !"

"Et je pourrais même copier-copier sur la Toile et dans LaTeX sans avoir besoin de passer par des balises!"

...

Sauf que, en pratique ça ne se révèle pas DU TOUT aussi simple !

Pour comprendre pourquoi, suivez avec moi la folle (enfin, pas trop quand même...) histoire des encodages texte !  

TODO:
"mètre" : "éèà" encore mieux comme exemple que µ?)
AZERTY? : SHIFT+*=µ (plus facile que  les "{[@]}" qui démandent Ctrl+Alt+ ou AltGr+ !)  
Python 3 : unicode par défaut  
PEPXXX? & Python 3.x? : unicode identifiers  


# Introduction

En apprenant que de Python2 à Python3, le format par défaut des fichiers .py  
(ce qui est potentiellement *différent* du **traitement** des *chaînes de caractères!*)  
est passé de ASCII à ~~Unicode~~ UTF-8,  
je me suis demandé quelles en étaient les implications...  

Notamment, ne serait-ce pas possible de directement écrire des symboles mathématiques et physiques dans les commentaires...  


    #ε₀=1⁄μ₀c² F⋅m⁻¹    (1)

Et pourquoi pas avoir directement des fonctions et des variables utilisant des symboles de maths et de physique?  

 
    εₒ=1/(μₒ*c**2)    (2)

ou bien même  

(3)  

```python
import numpy as np

def √(x):
    return np.sqrt(x)

class float:
    def __init__(self, x = 0.0):
        self.x = x
    
    def __str__(self):
        return "({0})".format(self.x)
    
    def __square__(self): # __square__ étant un éventuel opérateur post-fixé écrit x²
        xx = self.x*self.x
        return float(xx)

d = √(x² + y²)

print(d)
```

(µ et ² sont d'ailleurs présents sur certains clavier "français")

Et d'ailleurs, la (1) et la (2) marchent très bien dans Python 3.6 (au moins, 3.0 au plus) !

Je m'imaginais déjà pouvoir copier-coller ce genre de formules n'importe ou sur la Toile et dans TeX!

Mais non seulement la (3) ne marche pas -  
parce que ² (et √?) iraient mieux comme opérateurs à part entière, et l'ajout d'opérateurs personnalisés dans Python, surtout post-fixés [n'est pas prévu au moins avant la version 4 ou 5](TODO:source), -  
mais en plus même les moteurs de TeX où Unicode est endémique, tels LuaTeX et XeTeX ont du mal à les afficher ! (est-ce une simple histoire de police par défaut n'ayant pas les glyphes requis, ou alors c'est dû à autre chose? (Windows?))  

Un des problèmes essentiels est que l'histoire des encodages a été longue et tortueuse, et du coup, même quand Unicode essaye de s'imposer, on n'est en fait toujours pas tiré d'affaire !

# ~~Au commencement il fut l'ASCII !!~~  

Après des décennies, l'informatique s'est standardisée sur l'ASCII :  
un encodage à 7 bits, rentrant dans un seul octet et pouvant donc prendre les valeurs :  
décimales : 0d : 0 à 127  
binaires : 0b : _000 0000 à _111 1111  
hexadécimales : 0x : 00 à 7F  

[Liste](http://www.madore.org/~david/computers/unicode/cstab.html) :  

```
       0    1    2    3    4    5    6    7    8    9    a    b    c    d    e    f  
0x0    nul    stx    sot    etx    eot    enq    ack    bel    bs    ht    lf    vt    ff    cr    so    si  
0x1    dle    dc1    dc2    dc3    dc4    nak    syn    etb    can    em    sub    esc    fs    gs    rs    us  
0x2    sp    !    "    #    $    %    &    '    (    )    *    +    ,    -    .    /  
0x3    0    1    2    3    4    5    6    7    8    9    :    ;    <    =    >    ?  
0x4    @    A    B    C    D    E    F    G    H    I    J    K    L    M    N    O  
0x5    P    Q    R    S    T    U    V    W    X    Y    Z    [    \    ]    ^    _  
0x6    `    a    b    c    d    e    f    g    h    i    j    k    l    m    n    o  
0x7    p    q    r    s    t    u    v    w    x    y    z    {    |    }    ~    del  
       0    1    2    3    4    5    6    7    8    9    a    b    c    d    e    f  
```
*(TODO : explication des codes de contrôle 0x00 à 0x1F)*

Le protocole de transfert de méls SMTP *(Simple Mail Transfer Protocol)* l'utilise toujours exclusivement *(ou presque? TODO : "SMTPUTF8")*.
*(TODO : multiplets 7-bits (septiplets?), de SMTP, byte=multiplet, "word", base64, quoted-printable...)*

C'était plutôt suffisant pour l'anglo-américain et d'autres caractères, [dont de contrôle](TODO), mais pas pour les autres langues comme le français, qui était quant même bien désemparé sans les caractères tel le "é" ou le "à" !  

Les ordinateurs ayant tendance à travailler avec des octets [*TODO:pourquoi?*], et au fil des années le poids des données devenant de moins en moins cher, un bit a été rajouté, doublant le nombre de caractères pouvant être utilisés :  
décimales : 0d : 0 à 2555  
binaires : 0b : 0000 0000 à 1111 1111  
hexadécimales : 0h : 00 à FF  

Malheureusement (il s'est passé la même chose qu'avant la standardisation de l'ASCII?)  
[chacun a voulu y aller à sa sauce](http://www.iana.org/assignments/character-sets/character-sets.xhtml), et ce fut le bazar, "standardisé" sous les normes ISO-8859-dd voir la liste des encodages non-Unicode de caractères dans un navigateur ou dans les paramètres régionales de Windows.

Nous intéressent particulièrement :  

ISO-8859-1 nommée de préférence latin1 :  
*(TODO?: différence entre ISO 8859-1 et ISO-8859-1 ?)*

```
       01    2    3    4    5    6    7    8    9    a    b    c    d    e    f  
0x8    pad    hop    bph    nbh    ind    nel    ssa    esa    hts    htj    vts    pld    plu    ri    ss2    ss3  
0x9    dcs    pu1    pu2    sts    cch    mw    spa    epa    sos    sgci    sci    csi    st    osc    pm    apc  
0xa    nbsp    ¡    ¢    £     ¤    ¥    ¦    §    ¨    ©    ª    «    ¬    shy    ®    ¯  
0xb    °    ±    ²    ³    ´    µ    ¶    ·    ¸    ¹    º    »    ¼    ½    ¾    ¿  
0xc    À    Á    Â    Ã    Ä    Å    Æ    Ç    È    É    Ê    Ë    Ì    Í    Î    Ï  
0xd    Ð    Ñ    Ò    Ó    Ô    Õ    Ö    ×    Ø    Ù    Ú    Û    Ü    Ý    Þ    ß  
0xe    à    á    â    ã    ä    å    æ    ç    è    é    ê    ë    ì    í    î    ï  
0xf    ð    ñ    ò    ó    ô    õ    ö    ÷    ø    ù    ú    û    ü    ý    þ    ÿ  
       0    1    2    3    4    5    6    7    8    9    a    b    c    d    e    f  
```

il y a eu aussi :  
ISO-8859-15 nommée de préférence latin9 :  
(une sorte de "mise à jour" de latin1 )
**(à ne pas confondre avec ISO-8859-9=latin5=turkish≠windows-1254 !)**

```
Position    0xA4    0xA6    0xA8    0xB4    0xB8    0xBC    0xBD    0xBE  
8859-1    ¤    ¦    ¨    ´    ¸    ¼    ½    ¾  
8859-15    €    Š    š    Ž    ž    Œ    œ    Ÿ  
```

Mais c'est windows-1252 (finalisé pour Windows 98) qui a fini par s'imposer ,  
aussi surnommé "ANSI" *("ansinew" dans LaTeX ?)* :  
(remplaçant les codes de contrôle 0h80-0h9f finalement peu utilisés par d'autres caractères qui semblaient plus "utiles", et ayant donc tous ceux de latin1 ET  de latin9)

```
       0    1    2    3    4    5    6    7    8    9    a    b    c    d    e    f  
0x8    €    XX    ‚    ƒ    „    …    †    ‡    ˆ    ‰    Š    ‹    Œ    XX    Ž    XX  
0x9    XX    ‘    ’    “    ”    •    –    —    ˜    ™    š    ›    œ    XX    ž    Ÿ  
       0    1    2    3    4    5    6    7    8    9    a    b    c    d    e    f  
```
*(TODO:conversion windows-1252/latin9?)

81, 8D, 8F, 90, et 9D sont soit **non affectés**,  
soit  sont considères comme codes de contrôle de latin1 :  
respectivement hop, ri, ss3, dcs et st  
*(TODO : qu'est ce qu'ils font?)*  
*(TODO : attention aux erreurs possibles dans un cas ou dans l'autre?)*  


windows-1252 est souvent appelé par abus,  
[voire "standardisé" comme par exemple dans HTML5,  
en tant que "ISO-8859-1"(=latin1), (voire même en tant que "ascii"!)](https://encoding.spec.whatwg.org/#names-and-labels),  
probablement parce que les logiciels modernes (surtout les navigateurs? qu'en est-il des terminaux *nix?) auront tendance à automatiquement interpréter les codes de contrôle 0h80-0h9f de ISO-8859-1=latin1 comme les caractères de windows-1252.  
*(TODO : exceptions à cette règle?)*  
*(TODO?: windows code pages, DOS=OEM=IBM code page)*
*(TODO : W3C et WHATWG)*

Évidemment, le problème se pose quand un texte encodé comme latin9 est lu comme du windows-1252 ou du latin1, par exemple :
"1œuf = 1€" en latin9 est encodé en la séquence d'octets :  
0x : 31 BD 75 66 20 3D 20 31 A4  
cette même séquence d'octets donne :  
en latin1 : "1½uf = 1¤" *  
(¤ symbole monétaire, TODO? : remplacements ¤<=>$<=>£<=>€ ?)*  
en windows-1252 : "1¼uf = 1¢"  
Dans les deux cas, 0xBD et 0xA4 posent problème.  
*(TODO : J'obtiens "1�uf = 1�" en windows-1252 sur https://dencode.com/en/string/hex ??)*

*NB : Il y aurait eu un problème similaire à latin1/latin9 avant la standardisation de l'ascii?*

# **TODO : Chapitres Unicode, YAML, (Lua/Xe)(La)Tex**

 

Partager cette publication


Link to post
Share on other sites
Publié (modifié)

Pour précisions :

  • Cela s'appelle MBCS (Multi Byte Character Set) qui sont des "code pages" qui permettent de remplir les 127 valeurs vacantes de l'ASCII. Mais pas seulement, c'est un encodage soit sur 1 octet soit sur 2 octets comme le Shift-JIS
  • ANSI c'est un terme Microsoft pour définir le "code page" par défaut de son Windows. En France, ANSI c'est le latin-9. Au Japon, ANSI c'est sûrement le Shift-JIS.
  • Et pour l'anecdote, cette connerie de ligne de commandes Microsoft, utilise / utilisait par défaut un code page OEM. C'est pour cette raison que si son programme sort de l'Unicode il faut changer par 65001 (UTF-8) ou 1200/ 1201 (UTF-16)  (Et il existe aussi l'UTF-32 avec 12000/ 12001)

Et il faut parler du BOM "Byte Order Marker" (<- lien Wiki anglais) ;) ;) ... ce mal-aimé que Linux chie dessus

Modifié par foetus
Orthographe et mise en forme

Partager cette publication


Link to post
Share on other sites

Veuillez vous connecter pour commenter

Vous serez en mesure de laisser un commentaire après vous être connecté



Se connecter dès maintenant

×