Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
2016 connectés 

  FORUM HardWare.fr
  Programmation
  C

  Socket et envoi d'images ???

 


 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

Socket et envoi d'images ???

n°1247266
marcmm13
Posté le 17-11-2005 à 00:21:24  profilanswer
 

Bonjour, c encore moi :)
 
j'vai essayer de faire simple, je fais un projet de socket, j'ai aucun problem pour transmetre une page HTML dispo sur mon serveur a un client, mais le pb c'est quand y a une image, celle si n'est pas visible sur le client si il utilise un navigateur, et elle est sous forme de caractères très etranges si j'utilise une commande Telnet. Donc ma question est la suivante:
   Quel est la syntax correct pour lire une image, et l'ecrire de l'autre coté ?
 
voila comment je lis les fichiers pour l'instant:
     
Coté serveur (vraiment siplifié  ;)  )
 

Code :
  1. fichier_a_envoyer=fopen(nomDuFichier,"r" );          //on lis le fichier a envoyer
  2.          fichier_socket=fdopen(idSockDialogueClient,"w" );   //Socket en ecriture
  3. while(fgets(chaine,1000,fichier_a_envoyer)!=NULL)  /* on recopie 1000 caractère par 1000 cara et on  
  4. les envois */
  5.   {
  6.   fprintf(fichier_socket,"%s\n",chaine); 
  7.   fflush(fichier_a_envoyer);
  8.   }


 
j'ai pensé a remplacé le r et w  par rb et wb, mais apparament c pareil le pb vient peut etre du formatage ( je precise que l'extension est bien celle d'une image coté client).
 
une idée? merci ciao

mood
Publicité
Posté le 17-11-2005 à 00:21:24  profilanswer
 

n°1247346
blackgodde​ss
vive le troll !
Posté le 17-11-2005 à 09:33:26  profilanswer
 

fgets c'est normalement fait pour un fichier texte. Une image est un fichier binaire (ouvrir avec "rb"/"wb" si je me rappelle bien), et à lire/ecrire avec fread/fwrite.


---------------
-( BlackGoddess )-
n°1247414
Sve@r
Posté le 17-11-2005 à 10:41:08  profilanswer
 

blackgoddess a écrit :

Une image est un fichier binaire (ouvrir avec "rb"/"wb" si je me rappelle bien)...


Pas nécessaire de préciser "b" sur Unix. En revanche, l'idée de creuser "fgets" est intéressante car fgets arrête sa lecture à chaque '\n' (caractéristique d'une ligne dans un fichier texte). Or, des '\n', il peut y en avoir des tas sur une image mais ils ne signifient rien de particulier.
 

marcmm13 a écrit :

j'ai pensé a remplacé le r et w  par rb et wb, mais apparament c pareil le pb vient peut etre du formatage ( je precise que l'extension est bien celle d'une image coté client).


L'extension ne conditionne pas le type de fichier, c'et juste un repère permettant au système de choisir le programme le mieux approprié pour ouvrir ledit fichier. Mais si je renomme "toto.doc" en "toto.jpg", cela n'en fera pas une image pour autant !!!
 

marcmm13 a écrit :

une idée? merci ciao


Essaye de ramener sur ton serveur avec un média quelconque (disquette, clef USB, ftp) ton image reçue chez le client... et compare là (cmp) avec l'image d'origine. S'il y a une différence même sur un seul octet, c'est que ça vient de ton transfert (fgets ???).
Au fait, ton client est-il Unix ou Windows ???


Message édité par Sve@r le 17-11-2005 à 10:52:43

---------------
Vous ne pouvez pas apporter la prospérité au pauvre en la retirant au riche.
n°1247512
marcmm13
Posté le 17-11-2005 à 12:41:39  profilanswer
 

Merci de vos réponses
 

Citation :

Au fait, ton client est-il Unix ou Windows ???


 
-->unnix.
 
j'avais pas pensé au fgets, sije fais un fread vous pensez que c'est bon?? je test et je vous dis

Code :
  1. fichier_a_envoyer=fopen(nomDuFichier,"r" );          //on lis le fichier a envoyer  
  2.          fichier_socket=fdopen(idSockDialogueClient,"w" );   //Socket en ecriture  
  3.     while(fread(chaine,1000,fichier_a_envoyer)!=NULL)  /* on recopie 1000 caractère par 1000 cara et on   
  4. les envois */
  5.             {
  6.             fprintf(fichier_socket,"%s\n",chaine);   
  7.             fflush(fichier_a_envoyer);
  8.             }


Citation :

Essaye de ramener sur ton serveur avec un média quelconque (disquette, clef USB, ftp) ton image reçue chez le client... et compare là (cmp) avec l'image d'origine. S'il y a une différence même sur un seul octet, c'est que ça vient de ton transfert (fgets ???).  


Ils ne sont pas identiques en tout points :/
 

n°1247520
blackgodde​ss
vive le troll !
Posté le 17-11-2005 à 12:57:44  profilanswer
 

fwrite, pas fprintf (ton fichier peut contenir des octets à 0)
et pense à gérer que la taille du fichier n'est pas forcement un multiple de 1000.


---------------
-( BlackGoddess )-
n°1247534
Sve@r
Posté le 17-11-2005 à 13:34:41  profilanswer
 

marcmm13 a écrit :

j'avais pas pensé au fgets, si je fais un fread vous pensez que c'est bon??


Certainement

marcmm13 a écrit :

Ils ne sont pas identiques en tout points :/


Alors ca vient bien de toi
 

marcmm13 a écrit :

Code :
  1. while(fread(chaine,1000,fichier_a_envoyer)!=NULL)  /* on recopie 1000 caractère par 1000 cara et on   
  2. les envois */
  3.             {
  4.             fprintf(fichier_socket,"%s\n",chaine);   
  5.             fflush(fichier_a_envoyer);
  6.             }



 
Bon, déjà fread attend 4 paramètres et non 3... et en plus il renvoie le nb d'éléments lus ou 0 quand c'est fini mais pas NULL
 

Code :
  1. size_t nb_lu;
  2.     while((nb_lu=fread(chaine, 1, 1000, fichier_a_envoyer)) > 0)
  3.     {
  4.             fwrite(chaine, 1, nb_lu, fichier_socket)   
  5.     }


Message édité par Sve@r le 17-11-2005 à 13:40:49
n°1247675
marcmm13
Posté le 17-11-2005 à 15:31:35  profilanswer
 

Déjà merci pour vos reponses,
 

Citation :


 
    while((nb_lu=fread(chaine, 1, 1000, fichier_a_envoyer)) > 0)
    {  
            fwrite(chaine, 1, nb_lu, fichier_socket)    
    }


 
J'ai pas bien compris le:

Code :
  1. size_t nb_lu;


Si j'ai bien compris nb_lu comporte le nombre d'éléments lu, et renvois ce même nombre lors de l'écriture?  
Moi j'ai déclaré nb_lu comme un entier "int" .
 
Si non j'ai testé, et conqueror n'affiche plus les pages HTML, il cherche en boucle, alors que mon serveur à bien reçu la requete et l'a envoyé. Et sous telnet la page a bien été reçu ( sous forme HTML bien sur). Par contre l'image je peux la télécharger et puis impossible de l'ouvrir dedans j'ais toujour des caractère très bizards :s

n°1247726
marcmm13
Posté le 17-11-2005 à 16:28:17  profilanswer
 

OP C bon ça amrche c'est super c'est de la bombe !! j'ai repris ton bout de programme, les lectures et ecritures en binaire, et en fait le pb venit de mes fermetures de fichier ^^.
   Merci a tous ;)

n°1248131
Sve@r
Posté le 18-11-2005 à 09:48:07  profilanswer
 

marcmm13 a écrit :

J'ai pas bien compris le:

Code :
  1. size_t nb_lu;


Si j'ai bien compris nb_lu comporte le nombre d'éléments lu, et renvois ce même nombre lors de l'écriture?


Exact. Tu comptes combien d'éléments tu lis... et tu en écris autant.
Si ton fichier contient 5432 éléments (ici des octets), tu auras 5 tour de boucles où "nb_lu" = 1000 et un 6° sauf au dernier tour où "nb_lu" = 432 => ce qui te permet de n'écrire que ce que tu lis et rien d'autre
 

marcmm13 a écrit :

Moi j'ai déclaré nb_lu comme un entier "int" .


Oui, il y a eu à ce propos une grosse discussion  sur le forum (voir topic http://forum.hardware.fr/hardwaref [...] 8189-1.htm)
 
Si tu déclares "nb_lu" comme un "int", ça marche aujourd'hui parce que la valeur renvoyée par "read" rentre sur un "int" et même un int signé (elle ne peut pas dépasser 32767) mais si demain la fonction "read" est modifiée pour qu'elle puisse traiter plus d'éléments et que sa valeur ne peut rentrer que sur un "long", tu seras obligé de modifier tous tes sources où tu utilises "read" sur un "int".
 
Si tu utilises le type "size_t" (défini dans "<sys/types.h>" ) t'auras aucun problème. Aujourd'hui "size_t" est défini comme un "int", demain il sera redéfini comme il faut et toi, t'auras juste qu'à recompiler sans toucher à ton code
C'est le début de la "portabilité" !!!


---------------
Vous ne pouvez pas apporter la prospérité au pauvre en la retirant au riche.
n°1248150
Emmanuel D​elahaye
C is a sharp tool
Posté le 18-11-2005 à 10:17:24  profilanswer
 

Sve@r a écrit :

Si tu utilises le type "size_t" (défini dans "<sys/types.h>" )


Eeek! Non! Ce header n'est pas standard. size_t est défini lorsqu'on inclue le header standard <stddef.h>, ce qui est fait automatiquement quand on inclus <stdio.h> ou <stdlib.h>.
 
Ca, c'est la suite de la portabilité !


---------------
Des infos sur la programmation et le langage C: http://www.bien-programmer.fr Pas de Wi-Fi à la maison : http://www.cpl-france.org/
mood
Publicité
Posté le 18-11-2005 à 10:17:24  profilanswer
 

n°1248252
blackgodde​ss
vive le troll !
Posté le 18-11-2005 à 11:56:26  profilanswer
 

Sve@r a écrit :

un int signé (elle ne peut pas dépasser 32767)


 
sur la plupart des plateformes les int sont sur 32 bits non ?


---------------
-( BlackGoddess )-
n°1248299
Emmanuel D​elahaye
C is a sharp tool
Posté le 18-11-2005 à 12:52:34  profilanswer
 

blackgoddess a écrit :

sur la plupart des plateformes les int sont sur 32 bits non ?


Et ? La norme définit une taille minimale garantie.  
 
(pour simplifier)

  • char : 8-bit
  • short : 16-bit
  • int : 16-bit
  • long : 32-bit
  • long long : 64-bit [C99]


Ce qui est en plus n'est pas portable. Il existe des plateformes où les char font 16-bit. Il ne me viendrait pas à l'idée de mettre 256 dans un char pour cette raison...
 
Pour les int, c'est pareil.
 
Evidemment, il est techniquement possible d'écrire du code non portable. Il ne fonctionnera pas mieux, et constitue une bombe à retardement... Je dirait même que c'est contraire à l'éthique supposée d'un programmeur C normalement constitué...


---------------
Des infos sur la programmation et le langage C: http://www.bien-programmer.fr Pas de Wi-Fi à la maison : http://www.cpl-france.org/
n°1248344
blackgodde​ss
vive le troll !
Posté le 18-11-2005 à 13:54:54  profilanswer
 

d'accord ,je n'etais pas au courant de ce minimal garanti.
est-ce ce que ces valeurs sont disponible dans un en-tête standard ?


---------------
-( BlackGoddess )-
n°1248491
Sve@r
Posté le 18-11-2005 à 15:32:47  profilanswer
 

blackgoddess a écrit :

d'accord ,je n'etais pas au courant de ce minimal garanti.
est-ce ce que ces valeurs sont disponible dans un en-tête standard ?


Je crois que c'est dans "<limits.h>"


---------------
Vous ne pouvez pas apporter la prospérité au pauvre en la retirant au riche.
n°1248586
marcmm13
Posté le 18-11-2005 à 16:39:56  profilanswer
 

Citation :

Evidemment, il est techniquement possible d'écrire du code non portable. Il ne fonctionnera pas mieux, et constitue une bombe à retardement... Je dirait même que c'est contraire à l'éthique supposée d'un programmeur C normalement constitué...


 
Je suis tout a fait d'accord, et encore merci pour toutes vos réponses ^^
Grace a vous j'aurai peut etre un 24/20   lol
 non serieu merci, ciao.

n°1248636
Emmanuel D​elahaye
C is a sharp tool
Posté le 18-11-2005 à 17:34:40  profilanswer
 

blackgoddess a écrit :

d'accord ,je n'etais pas au courant de ce minimal garanti.
est-ce ce que ces valeurs sont disponible dans un en-tête standard ?


Non, ils le sont dans la norme.  


ISO/IEC 9899:1999 (E) ©ISO/IEC"
 
5.2.4.1 Translation limits
<...>
— number of bits for smallest object that is not a bit-field (byte)
CHAR_BIT 8
— minimum value for an object of type signed char
SCHAR_MIN -127 // -(27 - 1)
— maximum value for an object of type signed char
SCHAR_MAX +127 // 27 - 1
— maximum value for an object of type unsigned char
UCHAR_MAX 255 // 28 - 1
— minimum value for an object of type char
CHAR_MIN see below
— maximum value for an object of type char
CHAR_MAX see below
— maximum number of bytes in a multibyte character, for any supported locale
MB_LEN_MAX 1
— minimum value for an object of type short int
SHRT_MIN -32767 // -(215 - 1)
— maximum value for an object of type short int
SHRT_MAX +32767 // 215 - 1
— maximum value for an object of type unsigned short int
USHRT_MAX 65535 // 216 - 1
— minimum value for an object of type int
INT_MIN -32767 // -(215 - 1)
— maximum value for an object of type int
INT_MAX +32767 // 215 - 1
— maximum value for an object of type unsigned int
UINT_MAX 65535 // 216 - 1
— minimum value for an object of type long int
LONG_MIN -2147483647 // -(231 - 1)
— maximum value for an object of type long int
LONG_MAX +2147483647 // 231 - 1
— maximum value for an object of type unsigned long int
ULONG_MAX 4294967295 // 232 - 1
— minimum value for an object of type long long int
LLONG_MIN -9223372036854775807 // -(263 - 1)
— maximum value for an object of type long long int
LLONG_MAX +9223372036854775807 // 263 - 1
— maximum value for an object of type unsigned long long int
ULLONG_MAX 18446744073709551615 // 264 - 1


 
Ce qui est dans <limits.h>, ce sont les valeurs limites pour l'implémentation.

Message cité 1 fois
Message édité par Emmanuel Delahaye le 18-11-2005 à 17:51:42

---------------
Des infos sur la programmation et le langage C: http://www.bien-programmer.fr Pas de Wi-Fi à la maison : http://www.cpl-france.org/
n°1248667
Sve@r
Posté le 18-11-2005 à 18:31:07  profilanswer
 

Emmanuel Delahaye a écrit :

Non, ils le sont dans la norme.  


ISO/IEC 9899:1999 (E) ©ISO/IEC"
 
5.2.4.1 Translation limits
<...>
— number of bits for smallest object that is not a bit-field (byte)
CHAR_BIT 8
— minimum value for an object of type signed char
SCHAR_MIN -127 // -(27 - 1)
— maximum value for an object of type signed char
SCHAR_MAX +127 // 27 - 1
— maximum value for an object of type unsigned char
UCHAR_MAX 255 // 28 - 1
— minimum value for an object of type char
CHAR_MIN see below
— maximum value for an object of type char
CHAR_MAX see below
— maximum number of bytes in a multibyte character, for any supported locale
MB_LEN_MAX 1
— minimum value for an object of type short int
SHRT_MIN -32767 // -(215 - 1)
— maximum value for an object of type short int
SHRT_MAX +32767 // 215 - 1
— maximum value for an object of type unsigned short int
USHRT_MAX 65535 // 216 - 1
— minimum value for an object of type int
INT_MIN -32767 // -(215 - 1)
— maximum value for an object of type int
INT_MAX +32767 // 215 - 1
— maximum value for an object of type unsigned int
UINT_MAX 65535 // 216 - 1
— minimum value for an object of type long int
LONG_MIN -2147483647 // -(231 - 1)
— maximum value for an object of type long int
LONG_MAX +2147483647 // 231 - 1
— maximum value for an object of type unsigned long int
ULONG_MAX 4294967295 // 232 - 1
— minimum value for an object of type long long int
LLONG_MIN -9223372036854775807 // -(263 - 1)
— maximum value for an object of type long long int
LLONG_MAX +9223372036854775807 // 263 - 1
— maximum value for an object of type unsigned long long int
ULLONG_MAX 18446744073709551615 // 264 - 1




Je présume que les "232", "263", "264" etc... signifient "2 exposant 32", "2 exposant 63" et "2 exposant 64"...  :sol:  
 

Emmanuel Delahaye a écrit :

Ce qui est dans <limits.h>, ce sont les valeurs limites pour l'implémentation.


 
Oui, je suis allé voir - Merci...  :jap:


---------------
Vous ne pouvez pas apporter la prospérité au pauvre en la retirant au riche.

Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Programmation
  C

  Socket et envoi d'images ???

 

Sujets relatifs
Résolution imagesenvoyer une structure avec une socket udp
BufferedReader en attente pendant lecture socket[Resolu]Récupérer l'état d'une socket en sortie d'un select()
Formulaire d'inscription qui envoi tout par mail?Envoi d'un mail à l'internaute si "Oui" est coché
Macro excel: reduction taille des imagesEnvoi d'un formulaire par mail
Envoi d'un email à la personne si "Oui" est cochépb avec les images en php dans une page !
Plus de sujets relatifs à : Socket et envoi d'images ???


Copyright © 1997-2022 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR