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 :  
 

 
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
 
 

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.

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

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

 
ben non c'est pas les mêmes

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   )

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    
 
Par contre un truc m'intrigue :
 

 
man mimetype

 
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  

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!

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à.

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 !

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

Il va s'amuser. 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 ).

 
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 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

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

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ù.

ok, merci du complément d'info

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).

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

//vigenere_bin_crypt.c
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
 
#define SZ_MAX 25000 //octets
 
void err(char const * const msg)
{
    printf("ERR: %s\n", msg);
    exit(1);
}
 
int main(void)
{
 
    FILE *inp=fopen("forum_logo.gif", "rb" );
    if(!inp) err("inp" );
    
    unsigned char *data=malloc(SZ_MAX);
    if(!data) err("malloc" );
 
    unsigned char *data_crypt=malloc(SZ_MAX);
    if(!data_crypt) err("malloc2" );    
 
    char cle[]="clesupersecrete\x01\x02\xfe\xff";
    
    int nb_oct=fread(data, sizeof(unsigned char), SZ_MAX, inp);
    if(!nb_oct) err("fread" );
    
    fclose(inp);
    
    int i, j;
    
    for(i=0, j=0; i<nb_oct; i++)
    {
        data_crypt[i]=(data[i]+cle[j])&0xFF;
        j++;
        j=j%strlen(cle);
    }
    
    FILE *outp=fopen("resultat.gif", "wb" );
    if(!outp) err("outp" );
    
    if(fwrite(data_crypt, sizeof(unsigned char), nb_oct, outp)!=nb_oct) err("fwrite" );
    
    fclose(outp);
    
    return 0;
}

//vigenere_bin_decrypt.c
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
 
#define SZ_MAX 25000 //octets
 
void err(char const * const msg)
{
    printf("ERR: %s\n", msg);
    exit(1);
}
 
int main(void)
{
 
    FILE *inp=fopen("resultat.gif", "rb" );
    if(!inp) err("inp" );
    
    unsigned char *data_crypt=malloc(SZ_MAX);
    if(!data_crypt) err("malloc2" );    
    
    unsigned char *data=malloc(SZ_MAX);
    if(!data) err("malloc" );
 
    char cle[]="clesupersecrete\x01\x02\xfe\xff";
    
    int nb_oct=fread(data_crypt, sizeof(unsigned char), SZ_MAX, inp);
    if(!nb_oct) err("fread" );
    
    fclose(inp);
    
    int i, j;
    
    for(i=0, j=0; i<nb_oct; i++)
    {
        data[i]=(data_crypt[i]-cle[j])&0xFF; //signe '-'!
        j++;
        j=j%strlen(cle);
    }
    
    FILE *outp=fopen("decode.gif", "wb" );
    if(!outp) err("outp" );
    
    if(fwrite(data, sizeof(unsigned char), nb_oct, outp)!=nb_oct) err("fwrite" );
    
    fclose(outp);
    
    return 0;
}

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.

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
 
 
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 (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

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

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

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

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

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

Heu, de quoi parles-tu?

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