Combien de caractères différents possibles pour un fichier ?

Combien de caractères différents possibles pour un fichier ? - Divers - Programmation

Marsh Posté le 28-08-2016 à 12:22:27    

Bonjour à tous,
 
Je voudrais savoir si qqun connait le nombre de caractères différents qu'il est possible d'avoir dans un fichier ( tous types confondu ). Je ne trouve rien d'explicite sur google.
Avec une source fiable à l'appuis se serait encore mieux :)  
Je crois savoir que les caractères ascii sont en réalité des caractères codés sous 1 octet ( donc 8 bits). Cela signifie-t-il qu'il y a des caractères allant de 00000000 à 11111111 ? ( soit juste 255 possibilités). Ce nombre me parait trop beaucoup faible.
 
Petite illustration tirée d'un fichier PDF au hasard :  
 

Code :
  1. </Filter/FlateDecode/Length 316>>stream
  2. hÞTÁNÃ0 †ïy
  3. ¤xNÒ´Éqc‚ÃZЄ‡iZG%ºií&ž™·Àm`å`ÇvþÏNÂ@—Jƒd h_T– Û û·ÑŠõ
  4. A( Æ >z´ n<½æîä¶/aÛƒO¿åÊÝÊÀ¾ÿ¯õ‡Q‹§ëÌ,‰IJ–_¦šAÖ#1!CC #–‘<¤öŠ#>X’‹vdj$¢
  5. ÒvÌléS¼ÊûC­¬A/Jc”]»Q<+=›ÓeéýëØ
  6. ™zKÃ.EÞ…BŒ¼
  7. º¸2Ï÷‹ð6#¦—3kZ& ‘£~d}CXÊC½ì¡nM?ʳ£8|ÎÀ…ˆ® ç
  8. ¬\6ˆÞEØ‹Á…ψy§BŲ«ÍGÓ*mí@™-–Sˆ±/ʬä£boÏËňZ$ñ-À uRn–
  9. endstream
  10. endobj
  11. 529 0 obj
  12. <</Filter/FlateDecode/First 56/Length 682/N 7/Type/ObjStm>>stream
  13. hÞ¬UmOÛ0þ+÷qÓÆünǪÔ
  14. LÀÐRU?„Ök#¥I• þýÎv(”
  15. ²¬‹ï®Ÿïq•@A ŒZ´ÏÐ`Y°H*ÑZ`Œ
  16. P’\Ãá!7UÓæÛbá¢Ó…ÂÏÁ€ßù“Ü>DNrqSdÒԝÓ)àèÄoqSÂUÛ,rçgäêhB¦îÎσ9GEç–ø£˜8GŒWð»¨:‡ÀH>ì—ùÐo”“éýÖ=2!Í6Åüí°[¸ÚƒQ”Œ‹í©+Wk”¹ä?à˜TŪÁ#çѨ¹›(,Á XŽ„­–󜛲ºÿ4.ªò¦-?'_Y¹pFÏ<—ÅÆ‘ÓÓ‹Éèû—>5úsß:¿X“˦ÝUt]'B’Rræ1u1¬W•C‚¹w›_hãÙBf`Ü–[ß´ñ\¡HÁý|ŸãzÑ,ËzE®ËzXwån=)ÛΏ×EûpÐGÀ؁üyѧp!H~{ãÃæÓöÖE;*ˆ½ôënÆy¸ì§C`Ù”6‹«‹k–ƒÈ°q°¢o™\gqÒR@WÆÆ ™‰m+•‘€Žù83¥@K
  17. Zã½°p4%EÌ•™Áßcl"³`“Gâ.Š#>Éâî‚¢5,®9·XÄRéÛØ”¯¸é­!-Ë@ˆ´–ÈÏÎ"ðÀYÌa¤¦ÑîWQ[
  18. /PQɲ8é®2;R?rô·8ÿ/I2$©{Iöº$ù?$yþ •¯£¦Z¾¢Kó‚.êãmÊ|¶Ý;åi÷åɘ}—<Ÿ¶=ŠR›7]žÆ\¥Có[Ðø*ï ¯ÇbÉŒ~mÒ¾Jc³”xh-þwk„öOí^]Át9>2á›1}á¯$½Vå'PzBšÞc¤Âû#À Ô췐
  19. endstream
  20. endobj


 
Je ne suis même pas sur que ce soit réellement du ASCCI... Ca pourrait être du ISO 8895 ou du Unicode...  
Qqun peut'il m’éclairer ? Je suis un peut perdu.
 
 
Merci
 
 

Reply

Marsh Posté le 28-08-2016 à 12:22:27   

Reply

Marsh Posté le 28-08-2016 à 13:28:24    

Bonjour !
 
Il existe des codages de caractères sur 2 (UTF-16) ou jusqurà 4 (UTF-32 ou Unicode) caractères, pour gérer les caractères des différents alphabets (cyrillique, japonais, indien ...).
 
Sinon, c'est peut-être tout simplement du binaire (le mot clé "stream" semble l'indiquer), et là, il faut regarder dans la spécification du format utilisé pour décoder ...
 
Bonne continuation.


---------------
On n'est jamais très fort pour ce calcul !
Reply

Marsh Posté le 28-08-2016 à 16:51:34    

Dans quel but tu veux avoir cette info ? Car des systèmes de codage de caractères, il en existe un paquet...


---------------
Astres, outil de help-desk GPL : http://sourceforge.net/projects/astres, ICARE, gestion de conf : http://sourceforge.net/projects/icare, Outil Planeta Calandreta : https://framalibre.org/content/planeta-calandreta
Reply

Marsh Posté le 28-08-2016 à 17:55:22    

L'objectif est de chiffrer des documents (avec les types les plus connu : png, pdf, doxc, etc...). Je veux utiliser un algorithme simple pour commencer, tel que Vigenere . Du coup j'ai besoin de connaitre le nombre de caractères qu'il est possible d'afficher afin de savoir quel modulo appliquer.
 
 
J'ai une autre petite question :
 
Je me suis rendu compte tout à l'heure que si je renomme un PDF en .txt, je peux l'ouvrir comme un fichier texte. ( jusque la , tout va bien). Si je re-renomme ce même fichier en .PDF, je peux le ré ouvrir au format PDF. (Normal)... Par contre, si j'ouvre mon PDF avec un éditeur de texte ( comme NotePad..), que je copie tout le texte qu'il contient, que je le met dans un autre fichier txt ( vide et du même nom) et que je le renomme en .PDF, j'obtiens un PDF corrompu ( alors que le contenu des 2 fichiers sont exactement les mêmes)... :??:  
 
Savez-vous pourquoi cela arrive ? (car c'est assez embêtant comme phénomène... )
 
Merci

Reply

Marsh Posté le 28-08-2016 à 19:08:30    

xfreekingx a écrit :

Par contre, si j'ouvre mon PDF avec un éditeur de texte ( comme NotePad..), que je copie tout le texte qu'il contient, que je le met dans un autre fichier txt ( vide et du même nom) et que je le renomme en .PDF, j'obtiens un PDF corrompu ( alors que le contenu des 2 fichiers sont exactement les mêmes)... :??:  
 
Savez-vous pourquoi cela arrive ? (car c'est assez embêtant comme phénomène... )
 
Merci


 
ben non c'est pas les mêmes

Reply

Marsh Posté le 28-08-2016 à 20:04:24    

Bonjour Totoche17,  
Vous voulez dire quoi par : "ben non c'est pas les mêmes" ? Car pourtant le contenu des 2 fichiers est identique. Je ne comprends pas...  (Je suis un peu bête  :pt1cable: )

Reply

Marsh Posté le 28-08-2016 à 20:26:35    

Cela vient du type mime.
 
Ta copie est enregistrée en tex/plain, et ton logiciel lecteur de pdf ne s'appuie pas sur l'entête du fichier .
 
Ce qui est marrant sur linux, c'est q'ue j'arrive même pas à faire bugguer april, il ouvre tout même en changeant l'encodage, il gère  :love:  
 
Par contre un truc m'intrigue :
 

Citation :

splash@splash:~$ file --mime-type /home/splash/test.txt  
/home/splash/test.txt: application/pdf
splash@splash:~$ mimetype /home/splash/test.txt  
/home/splash/test.txt: text/plain


 
man mimetype

Citation :

This script tries to determine the mime type of a file using the Shared MIME-info database. It is intended as
       a kind of file(1) work-alike, but uses mimetypes instead of descriptions.


 
Je pige pas ce qu'il désigne par "descriptions" et donc les différences entre les 2 commandes.
 
Désolé de squatter ton sujet xfreekingx  :whistle:

Message cité 1 fois
Message édité par bistouille le 28-08-2016 à 20:29:17

---------------
On croit souvent avoir vu le fond de la stupidité humaine, et il parfois nécessaire qu'on vous rappelle qu'elle n'a pas de fond.
Reply

Marsh Posté le 28-08-2016 à 21:17:44    

xfreekingx a écrit :

L'objectif est de chiffrer des documents (avec les types les plus connu : png, pdf, doxc, etc...). Je veux utiliser un algorithme simple pour commencer, tel que Vigenere . Du coup j'ai besoin de connaitre le nombre de caractères qu'il est possible d'afficher afin de savoir quel modulo appliquer.


En informatique l'unité la plus petite c'est le bit (0/1), ensuite vient l'octet avec 8 bits et qui peut donc contenir des entiers de 0 à 255 (bornes comprises). C'est avec ces octets que tu dois bricoler. Si on veut sauvegarder des nombres plus grands on prends plusieurs octets, genre le fameux "int" qui en utilise 4 ou 8 selon le système (32/64 bit). Pour les encodages c'est un peu la même chose. Le ASCII c'est un octet par caractère, pour du Unicode il existe plusieurs variantes avec jusqu'à 4 octets par caractère de mémoire. Mais tout ça tu en as pas besoin, car l'unité de base c'est l'octet et c'est avec ça que tu dois travailler. Tu dois considérer tes fichiers comme une suite d'octets sans te soucier du type de fichier. Si tu veux t'amuser et apprendre des choses vas-y, par contre si tu veux crypter des documents de manière sûre utilise un programme tout fait!


Message édité par rat de combat le 28-08-2016 à 21:19:12
Reply

Marsh Posté le 28-08-2016 à 21:25:31    

xfreekingx a écrit :


J'ai une autre petite question :
 
Je me suis rendu compte tout à l'heure que si je renomme un PDF en .txt, je peux l'ouvrir comme un fichier texte. ( jusque la , tout va bien). Si je re-renomme ce même fichier en .PDF, je peux le ré ouvrir au format PDF. (Normal)... Par contre, si j'ouvre mon PDF avec un éditeur de texte ( comme NotePad..), que je copie tout le texte qu'il contient, que je le met dans un autre fichier txt ( vide et du même nom) et que je le renomme en .PDF, j'obtiens un PDF corrompu ( alors que le contenu des 2 fichiers sont exactement les mêmes)... :??:  
 
Savez-vous pourquoi cela arrive ? (car c'est assez embêtant comme phénomène... )
Merci


Ca doit être dû au fait que ton éditeur de texte va encoder le fichier différement, en effet comme je disais il y a bien des possibilités pour encoder du texte. En plus un fichier .pdf contient des caractères non imprimables (genre 0 à 20 et quelque en ASCII), l'éditeur risque de ne pas afficher/copier ces caractères (pas du tout ou pas correctement)--> problème.  
 
Il faut distinguer: Fichier texte qui peut être encodé de différentes manières mais qui ne contient uniquement des caractères imprimables si on l'ouvre avec un éditeur qui comprends l'encodage et fichier binaire qu'il faut considérer comme une suite d'octets. Ce dernier ne peut que s'ouvrir avec un programme qui comprends le format et affiche quelque chose d'utile ou alors - si on veut regarder les octets "bruts" - un éditeur hexa. Bien sûr un fichier texte c'est un fichier binaire aussi, finalement tout fichier est un fichier binaire. Bon, pas sûr d'être clair là. :o

Reply

Marsh Posté le 28-08-2016 à 22:44:25    

C'est à moitié clair, soyons honnêtes, enfin, selon le puiblic :)
 
Mais tout à fait d'accord avec le mail précédent : oublier le texte et travailler sur un ou deux octets (4, ça commence à faire beaucoup) et voilà, on est à l'aise.
 
Et ça fonctionne quel que soit le type de fichier, pas seulement les fichiers texte.
 
Sinon, sans vouloir être désagréable (ce n'est vraiment pas le but), mais xfreekingx, tu devrais revoir les bases de ce qu'est un fichier, un format binaire et un encodage, sinon tu risques de partir sur de mauvaises voies, la fameuse "mauvaise réponse à un faux problème" (faux problème, car ce n'est pas le "vrai besoin" ).
 
Bon courage, en tous cas !


---------------
On n'est jamais très fort pour ce calcul !
Reply

Marsh Posté le 28-08-2016 à 22:44:25   

Reply

Marsh Posté le 28-08-2016 à 22:49:20    

xfreekingx a écrit :

L'objectif est de chiffrer des documents (avec les types les plus connu : png, pdf, doxc, etc...). Je veux utiliser un algorithme simple pour commencer, tel que Vigenere . Du coup j'ai besoin de connaitre le nombre de caractères qu'il est possible d'afficher afin de savoir quel modulo appliquer.
 
 
J'ai une autre petite question :
 
Je me suis rendu compte tout à l'heure que si je renomme un PDF en .txt, je peux l'ouvrir comme un fichier texte. ( jusque la , tout va bien). Si je re-renomme ce même fichier en .PDF, je peux le ré ouvrir au format PDF. (Normal)... Par contre, si j'ouvre mon PDF avec un éditeur de texte ( comme NotePad..), que je copie tout le texte qu'il contient, que je le met dans un autre fichier txt ( vide et du même nom) et que je le renomme en .PDF, j'obtiens un PDF corrompu ( alors que le contenu des 2 fichiers sont exactement les mêmes)... :??:  
 
Savez-vous pourquoi cela arrive ? (car c'est assez embêtant comme phénomène... )
 
Merci


Aucun intérêt. Vigenere est complètement dépassé. Pour le chiffrement aujourd'hui, on travaille sur des blocs d'octets + une clé de plusieurs centaines de bits.
Regarde AES comme algo ;)


---------------
Astres, outil de help-desk GPL : http://sourceforge.net/projects/astres, ICARE, gestion de conf : http://sourceforge.net/projects/icare, Outil Planeta Calandreta : https://framalibre.org/content/planeta-calandreta
Reply

Marsh Posté le 28-08-2016 à 23:16:29    

rufo a écrit :

Regarde AES comme algo ;)

Il va s'amuser. :o Tu as parfaitement raison que Vigenere est complètement inadapté pour vraiment protéger un document, mais peut-être xfreekingx n'a pas ce but mais veut apprendre et s'entraîner. Et puis même avec un truc costaud comme AES, si l'implémentation est mauvaise ça ne vaut pas grand chose, vaut mieux se tourner vers un programme qui a déjà fait ses preuves (hélas Truecrypt est mort :sweat: ).

Reply

Marsh Posté le 29-08-2016 à 07:44:58    

rat de combat a écrit :

Il va s'amuser. :o Tu as parfaitement raison que Vigenere est complètement inadapté pour vraiment protéger un document, mais peut-être xfreekingx n'a pas ce but mais veut apprendre et s'entraîner. Et puis même avec un truc costaud comme AES, si l'implémentation est mauvaise ça ne vaut pas grand chose, vaut mieux se tourner vers un programme qui a déjà fait ses preuves (hélas Truecrypt est mort :sweat: ).


 
Bon Vigenère c'est pas le plus solide, mais je l'ai parfois utilisé quand je ne voulais pas que mon chien puisse lire mes documents :D Sérieusement, pour autant que je sache, Vigenère ne fonctionne que pour les fichiers textes non ? Crypter un fichier binaire nécessite quelques précautions qui n'ont pas directement à voir avec le processus d'encryption et donc si on ne considère que l'aspect didactique de la chose, je ne suis pas certain que ce soit la meilleure solution.
 
Si c'est juste pour utiliser un cryptage, il y a le programme "aescrypt" qui fonctionne pas mal. Si l'OP veut recréer lui-même un petit utilitaire de cryptage alors il peut baser son application sur une bibliothèque comme "bouncy castle" ou "botan" (juste deux exemples choisis au hasard, il y a en a des tonnes). Implanter soi-même un algorithme comme AES n'est pas simple (et justement il semble que l'OP ne soit pas un pro de la programmation). De plus certains aspects d'implantation (genre "choisir deux nombres sans diviseur commun" ) peuvent sembler simples à priori, mais en réalité ils ont vite tendance à introduire des failles monumentales dans un programme.
 
Juste mes deux centimes CFA :)

Reply

Marsh Posté le 14-09-2016 à 21:30:28    

Bonjour à tous,
 
Je tenais à vous remercier pour vos conseils car je viens de finir mon programme de chiffrement/déchiffrement. En effet, en chiffrant les fichiers binaires comme vous me l'avez conseillé tout se passe bien et je n'ai absolument aucun problème à déchiffrer mes données quels que soient leurs types ( fichiers, applications, etc.). Il ne me reste plus qu'à augmenter la complexité de l'algorithme de chiffrement ( je pense au triple-DES, qui même s'il n'est pas considéré comme sur est plus simple à implémenter que de l'AES ou du RSA pour un noob comme moi ^^' ).
 
Bref, merci a vous :jap:

Reply

Marsh Posté le 15-09-2016 à 20:59:50    

bistouille a écrit :

Cela vient du type mime.
 
Ta copie est enregistrée en tex/plain, et ton logiciel lecteur de pdf ne s'appuie pas sur l'entête du fichier .


Non.
Tu sembles penser que le type MIME est une info standard stockée dans chaque fichier (ou en metadata du FS) pour donner son type. Ce n'est pas le cas.
Ce n'est qu'une syntaxe standard pour définir le contenu d'un fichier. Ça sert surtout à "annoncer" ce que tu vas envoyer/recevoir lors d'un transfert de fichier sur le réseau par exemple.
 
La façon dont le MIME est renseigné ou découvert n'est pas standard ni stockée dans le fichier.
Les outils comme "file" essaient de deviner en cherchant des motifs usuels aux endroits connus de chaque type de fichier.
 
La plupart du temps tu as quand même des octets magiques en entête de fichier qui permettent d'identifier rapidement et facilement son type, mais c'est pas standard, ils peuvent être n'importe où.

Reply

Marsh Posté le 15-09-2016 à 21:35:12    

ok, merci du complément d'info :o


---------------
On croit souvent avoir vu le fond de la stupidité humaine, et il parfois nécessaire qu'on vous rappelle qu'elle n'a pas de fond.
Reply

Marsh Posté le 19-10-2016 à 21:49:22    

leonhard a écrit :

Sérieusement, pour autant que je sache, Vigenère ne fonctionne que pour les fichiers textes non ? Crypter un fichier binaire nécessite quelques précautions qui n'ont pas directement à voir avec le processus d'encryption et donc si on ne considère que l'aspect didactique de la chose, je ne suis pas certain que ce soit la meilleure solution.

On peut très bien crypter du binaire avec Vigenère. De quelles précautions parles-tu?

Message cité 1 fois
Message édité par rat de combat le 19-10-2016 à 21:50:05
Reply

Marsh Posté le 21-10-2016 à 08:45:26    

rat de combat a écrit :

On peut très bien crypter du binaire avec Vigenère. De quelles précautions parles-tu?


 
Le système de Vigenères est normalement un système de substitution polyalphabétique (un remplace une lettre par une autre, mais pas toujours la même). Le système original ne prévoit rien pour les caractères de contrôle (code ascii < 32) ni pour les choses étranges comme les parenthèses, les accolades et autres. Pour coder du binaire, je suppose que tu dois utiliser une version modifiée (en passant par du base64 par exemple). Ce que je voulais dire par "quelques précautions", c'est que dans le cas d'un message binaire, il faus s'assurer que le décryptage retourne au bit près le message original, sinon tu auras des problèmes à le lire le fichiers produit ensuite. J'ai lu plusieurs des messages que tu as postés et il semble évident que pour toi cette conversion sera "simple" parce que tu ne semble pas être un débutant en programmation mais, d'expérience, je sais que pour un débutant (un vrai débutant) le fait de ne pas pouvoir vérifier à la main que le message codé est correct, n'est pas quelque chose d'évident. C'est pourquoi, pour une vrai débutant j'aurais plutôt proposé un truc genre "one time pad" qui est plus facile à réaliser avec des binaire. Maintenant ce n'est que mon avis (et je le partage bien entendu).

Reply

Marsh Posté le 21-10-2016 à 19:59:56    

Sois tu as tord, soit mon bricolage n'est pas du Vigenère. :o  
J'arrive pas à mettre le code dans un spoiler :o , désolé, c'est un peu long...

Code :
  1. //vigenere_bin_crypt.c
  2. #include <stdlib.h>
  3. #include <stdio.h>
  4. #include <string.h>
  5.  
  6. #define SZ_MAX 25000 //octets
  7.  
  8. void err(char const * const msg)
  9. {
  10.    printf("ERR: %s\n", msg);
  11.    exit(1);
  12. }
  13.  
  14. int main(void)
  15. {
  16.  
  17.    FILE *inp=fopen("forum_logo.gif", "rb" );
  18.    if(!inp) err("inp" );
  19.    
  20.    unsigned char *data=malloc(SZ_MAX);
  21.    if(!data) err("malloc" );
  22.  
  23.    unsigned char *data_crypt=malloc(SZ_MAX);
  24.    if(!data_crypt) err("malloc2" );    
  25.  
  26.    char cle[]="clesupersecrete\x01\x02\xfe\xff";
  27.    
  28.    int nb_oct=fread(data, sizeof(unsigned char), SZ_MAX, inp);
  29.    if(!nb_oct) err("fread" );
  30.    
  31.    fclose(inp);
  32.    
  33.    int i, j;
  34.    
  35.    for(i=0, j=0; i<nb_oct; i++)
  36.    {
  37.        data_crypt[i]=(data[i]+cle[j])&0xFF;
  38.        j++;
  39.        j=j%strlen(cle);
  40.    }
  41.    
  42.    FILE *outp=fopen("resultat.gif", "wb" );
  43.    if(!outp) err("outp" );
  44.    
  45.    if(fwrite(data_crypt, sizeof(unsigned char), nb_oct, outp)!=nb_oct) err("fwrite" );
  46.    
  47.    fclose(outp);
  48.    
  49.    return 0;
  50. }
Code :
  1. //vigenere_bin_decrypt.c
  2. #include <stdlib.h>
  3. #include <stdio.h>
  4. #include <string.h>
  5.  
  6. #define SZ_MAX 25000 //octets
  7.  
  8. void err(char const * const msg)
  9. {
  10.    printf("ERR: %s\n", msg);
  11.    exit(1);
  12. }
  13.  
  14. int main(void)
  15. {
  16.  
  17.    FILE *inp=fopen("resultat.gif", "rb" );
  18.    if(!inp) err("inp" );
  19.    
  20.    unsigned char *data_crypt=malloc(SZ_MAX);
  21.    if(!data_crypt) err("malloc2" );    
  22.    
  23.    unsigned char *data=malloc(SZ_MAX);
  24.    if(!data) err("malloc" );
  25.  
  26.    char cle[]="clesupersecrete\x01\x02\xfe\xff";
  27.    
  28.    int nb_oct=fread(data_crypt, sizeof(unsigned char), SZ_MAX, inp);
  29.    if(!nb_oct) err("fread" );
  30.    
  31.    fclose(inp);
  32.    
  33.    int i, j;
  34.    
  35.    for(i=0, j=0; i<nb_oct; i++)
  36.    {
  37.        data[i]=(data_crypt[i]-cle[j])&0xFF; //signe '-'!
  38.        j++;
  39.        j=j%strlen(cle);
  40.    }
  41.    
  42.    FILE *outp=fopen("decode.gif", "wb" );
  43.    if(!outp) err("outp" );
  44.    
  45.    if(fwrite(data, sizeof(unsigned char), nb_oct, outp)!=nb_oct) err("fwrite" );
  46.    
  47.    fclose(outp);
  48.    
  49.    return 0;
  50. }

Testé avec le logo du forum, aucun problème, image originale+décryptée identiques (MD5). On peut mettre des caractères non-imprimables dans la clé ou pas, selon goût personnel.

Reply

Marsh Posté le 21-10-2016 à 21:15:08    

Disons qu'à partir du moment ou du texte, enfin de l'ASCII (ou autre encodage) n'est qu'une suite de sous-ensemble des valeurs possibles d'un byte, et que ton algo opère sur des bytes... bein tu peux faire ce que tu veux et incrémenter/soustraire ce que tu veux à cette suite de bytes donc oui c'est correct. Après est-ce qu'on peut mettre le tampon "agréé Vigenère©" à ton algo j'en sais rien peut-être quà la base il est pas censé être utilisé hors caractères imprimables :o
 
[:moundir]  
Par contre en théorie en C un overflow/underflow est un comportement indéfini et là avec tes opérations sur des uchar t'es en plein dedans :o (en plus ça dépend des compilos, char peut être signed ou unsigned par défaut)
Donc par exemple pour des unsigned char : a -= b puis a+=b, avec b > a ne garantit pas en théorie que a retombe sur sa valeur initiale en fin d'opération. Mais bon tout le monde ignore cette règle en pratique :o

Reply

Marsh Posté le 22-10-2016 à 01:44:01    

make install a écrit :

Après est-ce qu'on peut mettre le tampon "agréé Vigenère©" à ton algo j'en sais rien peut-être quà la base il est pas censé être utilisé hors caractères imprimables :o

C'est qu'en 1500 et quelque il ne devait pas connaître le ASCII et les caractères non-imprimables. :lol:

Citation :

Par contre en théorie en C un overflow/underflow est un comportement indéfini et là avec tes opérations sur des uchar t'es en plein dedans :o

Oups, le C est bizarre parfois... Merci pour l'info. :o

Citation :

(en plus ça dépend des compilos, char peut être signed ou unsigned par défaut)

J'aurais dû rajouter unsigned, même si ça ne change rien à priori...

Reply

Marsh Posté le 22-10-2016 à 12:10:57    

Ben 2, 0 et 1. Soit, Nul et un autre. Ou false et True.

Reply

Marsh Posté le 22-10-2016 à 12:27:20    

Ou factorielle N avecN nombre de pixel d'un caractère.
 
Ca dépand en fait, ça dépasse ?

Reply

Marsh Posté le 22-10-2016 à 21:17:44    

Heu, de quoi parles-tu? :??:

Reply

Marsh Posté le 23-10-2016 à 09:23:18    

rat de combat a écrit :

Heu, de quoi parles-tu? :??:


 
Du nombre max de caractères dans un fichier (cf le titre du sujet [:haha])

Reply

Marsh Posté le    

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed