Différences

Ci-dessous, les différences entre deux révisions de la page.

--- nsi:premiere:fichier_texte [2021/09/29 13:56] – goupillwiki
+++ nsi:premiere:fichier_texte [2024/01/15 12:28] (Version actuelle) – goupillwiki
@@ Ligne 1: / Ligne 1: @@
 ====== Fichier texte ======
-===== Fichiers et encodages =====
-On a déjà parlé de **ASCII** et **Unicode** -- cours sur [[caracteres|chaînes de caractères]]. Allons un peu plus loin en examinant les fichiers de texte.
-==== Reconnaître un fichier texte ====
-Un fichier en mémoire est une suite de bits, ou si on veut une suite d'octets.
-Ces octets peuvent signifier n'importe quoi. On ne sait pas forcément ce qu'ils représentent à priori. Il nous faut des indices :
-  * Le fichier peut avoir une extension. Le format ''.txt'' sous Windows indique qu'il s'agit d'un fichier texte.\\ Chaque octet représente un caractère selon le codage [[https://fr.wikipedia.org/wiki/Windows-1252|ANSI]] de Windows, **compatible avec ASCII**.\\ Mais cet indice ne constitue pas une preuve !\\ //cf. Exercice 1//
-  * Si on renomme en ''monimage.doc'', l'ouverture avec //Word// ne fonctionnera pas.\\ En effet, ''.doc'' est un format plus compliqué contenant un certain nombre d'informations placées d'une certaine façon. Si les données ne correspondent pas à ce qui est attendu, //Word// retourne une erreur.
-On peut donc analyser le fichier selon plusieurs format connus et ne conserver que les formats compatibles.
-==== Les encodages ====
-Supposons que l'on ait un fichier texte, un fichier simple, contenant seulement la suite des caractères.
-<wrap tip>Donc ni un fichier '.doc' ni un fichier '.pdf' par exemple.</wrap>
-Il s'agit maintenant de savoir **comment lire ces octets**. Doit-on les considérer un par un ? par groupe de deux ? etc. **Il n'y a pas un seul choix possible !**
-  * Il y a une histoire qui a vu les systèmes se complexifier à mesure que les performances le permettaient.
-  * Il y a une inertie importante : un choix ancien -- comme ASCII -- demeure simplement pour assurer la compatibilité avec ce qui existe déjà et que l'inertie est parfois importante.
-  * Différentes entreprises concurrentes tentent d'imposer leurs choix.
-  * Des situations différentes peuvent entraîner des besoins différents et donc des choix différents.
-  * Quand l'informatique ne concernait que les USA, ASCII suffisait. Mais aujourd'hui, il faut tenir compte de la grande diversité des systèmes d'écriture.
-<WRAP important>Avec internet, les échanges de fichier devient mondial. De plus certains fichiers restent accessibles pendant très longtemps. Le problème de l'encodage est donc très important.</WRAP>
-=== ASCII ===
-Déjà mentionné, 128 caractères sans accent, donc 7 bits par caractère.
-<WRAP tip>
-Dans les fait on utilise plutôt un des codages suivants qui sont compatibles avec ASCII si bien qu'on n'utilise jamais moins d'un octet par caractère.
-</WRAP>
-=== ISO 8859-1 ===
-//Latin-1 = Europe occidentale [1986]//
-Ajoute des caractères accentués à ASCII. Suffit pour le français.
-<img src='inc/11.iso.png'>
-Tend à disparaître au profit d'**UTF-8**. Pas plus de 10 % d'utilisation.
-<img src="inc/11.utilisation.png">
-=== ANSI ===
-//Windows-1252 ou CP1252//
-C'est un codage //Windows//, très proche de //ISO 8859-1//.
-ANSI se contente de remplacer certains codes de contrôles -- octets ne correspondant pas à un caractère affichable -- par des caractères.
-=== UTF8 ===
-//Universal character set Transformation Set - 8 bits//
-C'est un codage fait pour utiliser **Unicode** mais en allégeant un peu.
-Avec UTF-8, selon les cas, un caractère peut-être codé sur 1, 2 ou 4 octets.
-  * Quand c'est un caractère ASCII, il ne prend qu'un octet. Ainsi, un fichier en ASCII est parfaitement compatible avec UTF-8. <wrap tip>Être compatible ASCII est quasiment obligatoire.</wrap>
-  * Un caractère comme ''é'' va être encodé par deux octets : ''0xC3 A9''.
-  * L'encodage est fait pour que l'on sache à chaque fois combien on devra lire d'octets pour le prochain caractère.
-<WRAP box>Je donne ici un peu plus de détails. C'est optionnel, vous pouvez ignorer ces détails si vous n'êtes pas intéressés.
-  * Quand l'octet commence par ''0'', UTF8 considère que la fin de l'octet, les 7 bits restants, codent un caractère ASCII.
-  * Quand l'octet commence par ''110'', UTF8 comprend que le prochain caractère utilisera deux octets, celui-ci et le suivant. L'octet suivant devra commencer par ''10'', sinon ce sera une erreur.\\ Par exemple, le caractère ''é'' :
-     * ''é'' est codé en UTF8 ''0x C3 A9 = 0b 1100 0011 1010 1001''
-     * Le premier des deux octets commence bien par ''110'' et le second par ''10''.
-     * Quand on enlève ces codes ''110'' et ''10'' (je mets des ''%%_%%'' à la place) il reste ''%%___00 0011 __10 1001%%'' ce qui correspond au ''é'' en unicode : ''0xE9 = 1110 1001''.
-  * Il y a encore d'autres codes spéciaux pour des caractères plus rares.
-</WRAP>
-//Exercice 11.2//
-==== Reconnaître l'encodage ====
-Pour éviter les problèmes, le mieux est d'indiquer d'une façon ou d'une autre le codage utilisé. Par exemple avec un fichier ''.html'' :
-  * Le fichier ''.html'' est un fichier texte écrit avec un certain encodage //xxx//.
-  * Dans le fichier ''.html'' on ajoute une balise ''%%<meta charset='xxx'>%%'' dans la partie ''%%<head>%%''.
-Ainsi le navigateur ouvrant la page reconnaît la balise ''%%<meta charset>%%'' -- écrite uniquement en ASCII donc compatibles avec tous les encodages -- et en déduit l'encodage à utiliser.
-<WRAP tip>Rien n'empêche de s'amuser à enregistrer le fichier en ISO-8859-1 puis d'écrire ''%%<meta charset='utf-8'>%%''. Le navigateur essaiera alors d'ouvrir le fichier avec l'encodage UTF8. Des caractères spéciaux indiqueront qu'il y a des caractères non reconnus.</WRAP>
-//Exercice 11.3 et 11.4//
 ===== Manipulation de fichiers =====
@@ Ligne 140: / Ligne 50: @@
 </code>
-Et quand on récupère une ligne de fichier ''.csv%%'', par exemple :
+Et quand on récupère une ligne de fichier ''%%.csv%%'', on veut pouvoir le convertir facilement en tableau. Voici un exemple :
-''%%chaine = "Michel,Dupont,12/11/1984,3 rue de la fontaine"%%''
+<code python>
+>>> chaine = "Michel,Dupont,12/11/1984,3 rue de la fontaine"
+# ci-dessus, chaine reçoit une ligne de données type csv
+>>> chaine.split(',')
+# on fait un découpe suivant le caractère ','
+['Michel', 'Dupont', '12/11/1984', '3 rue de la fontaine']
+# ce qui donne un tableau
+</code>
-On va vouloir la fractionner sous forme d'un tableau :
+<WRAP tip>Le genre de travail que l'on va faire a déjà été fait 1000 fois et sert d'apprentissage. Pour aller plus vite, il y aura des bibliothèques de fonctions toutes faites comme [[https://docs.python.org/fr/3/library/csv.html|csv]].
+</WRAP>
-''%%['Michel', 'Dupont', '12/11/1984', '3 rue de la fontaine']%%''
+===== Libérer la ressource =====
-Cette commande est là pour cela :
+Quand Python ouvre un fichier, il demande au **système d'exploitation** (//OS//) de lui donner l'accès à ce fichier. Quand c'est une demande d'écriture, l'OS **verrouille** le fichier pour qu'il n'y ait pas deux programmes écrivant en même temps dans un même fichier. Il est donc important de **libérer** le fichier quand on a fini de l'utiliser.
 <code python>
-chaine.split(',')
+f.close() # libère le fichier
 </code>
-<WRAP tip>Le genre de travail que l'on va faire a déjà été fait 1000 fois et sert d'apprentissage. Pour aller plus vite, il y aura des bibliothèques de fonctions toutes faites comme [[https://docs.python.org/fr/3/library/csv.html|csv]].
+Pour être certain de ne pas oublier la fermeture, on peut empaqueter l'utilisation de fichier dans une structure de programmation :
+<code python>
+with open('nom_du_fichier', mode, encodage='utf8') as f:
+    # on peut utiliser f tant qu'on est à l'intérieur de ce with
+# dès qu'on sort du with, f est fermé.
+</code>