Discussion :

[free_01_binairy]

Salut
J'ai une préoccupation en C
Je veux modifier un fichier texte. je me positionne là ou je veux être dans le fichier, Par modification, j'entends supprimer des caractères et si je veux j'inscris de nouveaux caractères à cet endroit.
Je ne sais pas comment m'y prendre.
Merci.

[dalfab]

Bonjour,

Une fichier c'est une zone localisée d'octets. On ne peut pas enlever des octets ou en ajouter sauf en fin de fichier. En accès binaire, on peut en plus changer la valeurs d'octets dans le fichier.

Pour toutes les autres modifications, le seul moyen est :
a) on crée un autre fichier par une copie séquentielle du fichier initial
b) les zones à modifier sont écrites elles aussi dans la séquence
c) l'autre fichier est fermé
d) le fichier initial est renommé
e) l'autre fichier prend le nom du fichier initial
f) le fichier initial renommé peut être supprimé si tout s'est bien passé. Sinon on peut restaurer le fichier initial à son nom initial.

[free_01_binairy]

Si c'est le seul moyen de modifier un fichier texte, c'est que pour un gros fichier, le temps de traitement doit être vraiment long.
Imaginons un dictionnaire de plus 10000 mots, je veux modifier juste un caractère de ce texte; et la je suis obligé de copier 10000 mots
dans autre un fichier!
Ouf!
Je vais quand prendre cet algorithme, j'ai pas le choix, j’attends quand même un plus optimisé s'il y en a.
Merci @dalfab.

[Médinoc]

Tant que le fichier sera du texte brut, tu n'auras pas mieux.

[free_01_binairy]

Tant que le fichier sera du texte brut, tu n'auras pas mieux.

Ok

[free_01_binairy]

Existe-t-il une fonction qui crée un fichier texte ?
Je veux créer pour le cas un fichier temporaire, mais quand j'ai fouillé la doc, c'est FILE * tmpfile ( void ) mais est valable seulement pour les fichiers binaires, ce qui ne convient pas ici.
Merci

[Sve@r]

Imaginons un dictionnaire de plus 10000 mots, je veux modifier juste un caractère de ce texte; et la je suis obligé de copier 10000 mots
dans autre un fichier!

Tu peux changer les caractères d'un fichier mais en respectant la règle "1 pour 1".
- Tu ouvres ton fichier en mode "r+"
- Tu te positionnes juste avant le caractère à changer
- Tu écris le caractère de remplacement
- Tu fermes le fichier

Le seul soucis c'est le positionnement. Parce que pour savoir si tu es sur le bon caractère il te faut le lire. Mais quand tu l'as lu, tu n'es plus "juste devant" mais "juste derrière". Il faut alors jongler avec fseek() (et éventuellement ftell())...

mais est valable seulement pour les fichiers binaires, ce qui ne convient pas ici.

Unix/Linux ne fait absolument aucune distinction entre "fichier binaire" et "fichier texte". Pour la simple raison qu'en réalité il n'y en a aucune. En effet, la nature d'un fichier n'est pas liée au contenu du fichier mais à l'outil qui le lit. Prends un fichier contenant "0x0a 0x0e 0x55 ..." ben si tu le lis via "notepad" peut-être que tu verras des phrases; et si tu le lis avec "vlc" peut-être que tu verras un film. Mais pour l'ordi, cela fait-il une différence ? Et même pour toi si tu réfléchis bien, cela fait-il une différence ???

En réalité cette distinction de m.... a été imposée par le monde zindow qui a "décrété" qu'un fichier texte serait un fichier composé de lignes (jusque là ok) mais chaque ligne terminée par deux caractères ; le premier '\r' symbolisant le retour du charriot en début de ligne, et le second '\n' symbolisant la rotation du charriot qui fait passer le papier sur la ligne suivante, reproduisant ainsi le fonctionnement d'une machine à écrire.
Sauf que celui qui a imaginé reproduire ce schéma n'a pas réfléchi que si séparer les deux opérations se justifie sur une machine (on peut en effet faire revenir le charriot sans faire avancer le papier ce qui permet, en réécrivant en blanc au même endroit, d'effacer le texte tapé), elles n'apportent aucune plus value en informatique.
Et à cause de cette débilité on est maintenant obligés de préciser la nature du fichier lors des transferts ftp hétérogènes (Unix vers Windows et inversement) pour que le protocole transforme (ou ne transforme pas) les lignes lors des transferts ; et c'est aussi pour ça que le blocnote de cet os crétin ne peut pas lire les fichiers textes Unix (toutes les lignes apparaissent concaténées en une seule) lorsqu'on les passe par clef USB sans les avoir transformés au préalable via "unix2dos".

Donc quand tu es sur Unix, un ".sh", ".txt", ".mp3" ça reste de simples fichiers contenant de simples octets que tu traiteras de la même et simple façon (ouvrir, lire, fermer)...

[Christophe]

Ce qui est bizarre en plus car ça devrait plutôt être les systèmes Unix qui génère les 2 caractères en mode "machine à écrire". Car Unix étant plus ancien que Windows, celui-ci a connu l'usage des télétypes. (périphérique d'entrées-sortie utilisé avant les écrans, et via une liaison Telecom : A cette époque, on se connectait sur un mainframe).

Dans ton cas, si tu sais que tu dois modifier du texte, tu peux aussi le charger dans un buffer, effectuer les modifications, puis le réécrire. Tu pourras alors te déplacer dans ce buffer soit caractère par caractère (getc/putc), soit ligne par ligne (gets/puts). pou la famille puts/gets, attention à la gestion du retour chariot et de \0. La solution fseek et ftell reste bien entendu valable, et avec la gestion de cache de l'OS, je suis même pas sûr qu'il y ai une différence de perf.

[Médinoc]

Ce qui est bizarre en plus car ça devrait plutôt être les systèmes Unix qui génère les 2 caractères en mode "machine à écrire". Car Unix étant plus ancien que Windows, celui-ci a connu l'usage des télétypes.

C'est là qu'on voit l'historique de compatibilité de Windows: Windows est basé sur DOS, lui-même basé sur CP/M...
D'ailleurs, c'est à CP/M (qui n'avait pas de répertoires, seulement des fichiers) qu'on doit les paramètres préfixés par un slash, ce qui a forcé Microsoft à choisir autre chose comme séparateur entre répertoires et fichier...