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**
On parle de quels Pi aussi ? Parce que c'est clair qu'entre le Pi "1", les Pi Zero, le Pi4 1Go et le Pi4 4 Go, tu ne va pas avoir les mêmes performances ! Et le problème d'alim (et de cartes SD foutues !) ce n'était pas dû aux transformateurs USB2 normalement limités à 2.5 W ? Avec les Pi qui te montent facilement au double de ça, surtout en branchant d'autres périphériques, tu m'étonnes qu'ils aient du mal à tenir ! Par contre, avec l'USB3 du Pi4*, en théorie capable de 15W en 5V (et jusqu'à 100W en 20V ??), ça devrait mieux passer ? (Enfin, il faut quand même faire gaffe à ne pas le surcharger si en pratique il n'est pas capable de faire mieux que 5V : 15W ce n'est pas *si* loin...) *P.S.: Pi4 seulement à partir de la version 1.2, la version 1.0 aurait eu le port USB-C mal soudé ?