Socket et envoi d'images ??? - C - Programmation
Marsh Posté le 17-11-2005 à 09:33:26
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.
Marsh Posté le 17-11-2005 à 10:41:08
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 ???
Marsh Posté le 17-11-2005 à 12:41:39
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 :
|
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
Marsh Posté le 17-11-2005 à 12:57:44
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.
Marsh Posté le 17-11-2005 à 13:34:41
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 :
|
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 :
|
Marsh Posté le 17-11-2005 à 15:31:35
Déjà merci pour vos reponses,
Citation : |
J'ai pas bien compris le:
Code :
|
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
Marsh Posté le 17-11-2005 à 16:28:17
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
Marsh Posté le 18-11-2005 à 09:48:07
marcmm13 a écrit : J'ai pas bien compris le:
|
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é" !!!
Marsh Posté le 18-11-2005 à 10:17:24
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é !
Marsh Posté le 18-11-2005 à 11:56:26
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 ?
Marsh Posté le 18-11-2005 à 12:52:34
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)
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é...
Marsh Posté le 18-11-2005 à 13:54:54
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 ?
Marsh Posté le 18-11-2005 à 15:32:47
blackgoddess a écrit : d'accord ,je n'etais pas au courant de ce minimal garanti. |
Je crois que c'est dans "<limits.h>"
Marsh Posté le 18-11-2005 à 16:39:56
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.
Marsh Posté le 18-11-2005 à 17:34:40
blackgoddess a écrit : d'accord ,je n'etais pas au courant de ce minimal garanti. |
Non, ils le sont dans la norme.
|
Ce qui est dans <limits.h>, ce sont les valeurs limites pour l'implémentation.
Marsh Posté le 18-11-2005 à 18:31:07
Emmanuel Delahaye a écrit : Non, ils le sont dans la norme.
|
Je présume que les "232", "263", "264" etc... signifient "2 exposant 32", "2 exposant 63" et "2 exposant 64"...
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...
Marsh Posté le 17-11-2005 à 00:21:24
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é )
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