> Accueil>

Voir entete

Oui, la longueur d'un INT de 'java' pour crc. Pas qu'un seul octet, car ce n'est pas assez sûre. On aurait une chance sur 256 de se trompé(,mais si vous voulez mettre crc sur un octet, comme au temps de la saisie AMSTRAD des fichiers Basic, je comprendrai).
   Qu'est ce crc?- crc est l'octet de vérification d'une ligne hexa entrée par saisie manuelle. Elle permet malgré son taux d'incertitude de repérer les fautes,(tout comme le bit de parité en beaucoup plus puissant!).
   Ici, adapté aux fichiers, permettrait aux programmes qui les gèrent de savoir si deux fichiers sont identiques en contenu au lieu de le vérifié octet par octet,qui avec les gros fichiers actuels demandent un temps non négligeable au processeur.
   Et deuxièment, crc permettrait de vérifié l'intégrité du fichier, surtout si les pirates ne savent pas comment est créé le crc du fichier. Car évidemment on peut faire soi-même le crc, et si le pirate peut changer cette valeur (surtout pour les exe,java) ou s'il a changé quelque octets dans le fichier d'être démasqué par le programme Officiel qui les génèrent!

Quand à info, il permettrait d'afficher une remarque du concepteur du fichier,quand on survole le fichier.(C'est pas bête n'est-ce-pas!)

Enfin, j'entend déja qu'on hurle (on a pas assez de place, ou c'est de l'espace perdu:plus maintenant les amis, je pousserai encore plus loin le bouchon, Maurice!).
   Et si on ajoutait une propriété supplémentaire du même style que info(reste à trouver le nom que je n'ai pas!)(on met ce qu'on veut quand c'est pas normalisé. Ce pourrait-être un fichier XML pour les fichiers normalisés). On y mettrait toutes sorte d'info, comme les balises meta des fichiers HTML.Et nouveau, on les mets à la fin du fichier après un caractère qui n'existe pas (autre que EOF! Et oui, on peut même mettre plusieurs fichiers texte comme un tar (texte).
   Je dis cela, cela ferait plus propre pour le fichiers mp3,email. Car pour moi! on doit pas tout mélangé dans un fichier (le son,vidéo... et ses info:auteur...niveau(nom) de cryptage,compression). On le fait actuellement pour les mp3,jpeg(je crois à la fin du fichier), mais il faut après séparer les données qui pour un micro-controlleur n'est pas chose aisé(D'où le caractère spécial ou voir dans le paragraphe suivant taille effective du fichier). Remplacé un octet obsolète qui se trouve dans les 31 octets les plus bas)

Une idée de dernière minute ! Si on opte pour les meta données, après le contenu qui n'est peut-être pas du texte, je propose ceci:il existe la taille du fichier, mais il pourrait y a avoir en plus la taille effective, pour le contenu. Si la taille et la taille effective du fichier sont égales alors il n'y a pas de meta données! Par ailleurs, si taille effective =0 alors il contient que des meta données!Pour moi, les propriétés de sont pas dans les meta données!

Voila c'est pensé et soumit!

Le texte est modifiable, si vous ne voulez imprimer qu'une partie ou ajouter des commentaires avant l'impression

Imprimer