Discussion :

[kertimanoff]

Bonjour,

je réalise de le cadre de mes études un Client - Serveur de fichiers.
Le probleme: les fichiers BINAIRES envoyés de l'un vers l'autre sont corrompus tandis que les fichiers .txt ne le sont pas.
Prenon la situation du transfére Client ->vers-> Serveur:
metton que le nom du fichier soit connu a l'avance (je vais pas mettre tout le code pour pas fair trop lourd)

algo java du client:(volontairement sans controle d'exception)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
BufferedReader br    = null;   //Reader sur la socket
PrintWriter pw       = null;    //Writer sur la socket
FileInputStream fis  = null;   //Entrèe sur un fichier
FileOutputStream fos = null; //Sortie sur un fichier

File theFile = new File(filename);
fileSize = theFile.length();
fis = new FileInputStream(theFile);

// Envoi de la taille du fichier sur la socket
pw.println(new Long((fileSize)).toString());   
pw.flush();

for (long i=0;i<fileSize;i++){
   pw.write(fis.read());
}
pw.flush();   
fis.close();

//a savoir que d'aprés la doc fis.read() renvoi un int compris en 0 et 65535 pour une valeur lu entre 0 et 0xffff (en gros que les octets sont interprétés comme des int)

Algo java du serveur:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
BufferedReader br    = null; //Reader sur la socket
PrintWriter pw       = null; //Writer sur la socket
FileInputStream fis  = null; //Entrèe sur un fichier
FileOutputStream fos = null; //Sortie sur un fichier
 
fos = new FileOutputStream(filename);
// Reception de la taille du fichier sur la socket
long fileSize = Long.parseLong(br.readLine());
// Reception des octets.
for (long i=0;i<fileSize;i++) 
                 fos.write(br.read());
 
fos.close();

////////////////////////////////////FIN d'algo
Le souci c'est que les fichiers autre que txt sont corrompu alors j'ai fai un petit programme cpp pour comparait un a un les octets des deux fichier (celui avant et celui aprés transfére) et j'observe que les octets 0x9y et 0x8y avec y un caractére hexa quelconque, sont remplacer systématiquement par 0x3f
a noté également que tous les transfére d'un méme fichier correcte donnent des fichiers corompu identiques (donc les octet reçu ne sont pas du hasard)

comment fair pour transférer correctement les octets d'un fichier binaire, et ainsi restituer une copi parfaite du fichier de l'autre coté?

[ngpub]

a savoir que d'aprés la doc fis.read() renvoi un int compris en 0 et 65535 pour une valeur lu entre 0 et 0xffff (en gros que les octets sont interprétés comme des int)

Dans ma doc à moi j'ai :

Reads the next byte of data from the input stream. The value byte is returned as an int in the range 0 to 255. If no byte is available because the end of the stream has been reached, the value -1 is returned...

comment fair pour transférer correctement les octets d'un fichier binaire, et ainsi restituer une copi parfaite du fichier de l'autre coté?

Utiliser un flux binaire à la place d'un flux caractères ?

[kertimanoff]

je suis entiérement dacor, alors justement comment modifier mon code actuel pour Utiliser un flux binaire à la place d'un flux caractères ?

[ngpub]

En remplaçant

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
BufferedReader br    = null; //Reader sur la socket
PrintWriter pw       = null; //Writer sur la socket

par

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
BufferedInputStream br    = null;
BufferedOutputStream pw       = null;

et en arrangeant le protocole concernant la transmission de la taille du fichier.

[kertimanoff]

je teste sa dessuite, j'en profite pour préciser que j'ai oublier de mettre les new mais c'est pas grave. on admet qu'ils existent entre la déclaration et l'utilisation des méthodes

[kertimanoff]

Merveilleux, ça marche comme je le désire !
Merci beaucoup

[kertimanoff]

Je vien de m'apercevoir d'un détaille inatendu:
les fichiers binaire se transfére parfaitement (méme crc) sauf que maintenant les fichiers .txt son éroné...
faut-il tester le type de fichier a transféré, et choisir ensuite le flux aproprié?

[dingoth]

Idéalement, il faut demander à l'utilisateur quel est le type de fichier (binaire/texte) et ouvrir un flux en utilisant cette information : *Reader pour les fichiers textes et *InputStream pour les fichiers binaires.

Enfin, c'est surtout le cas lors de transferts de fichiers entre systèmes peu compatibles (Mac <--> Windows par exemple).

[kertimanoff]

En fait ce n'est pas les fichiers texte mais les fichiers de taille inférieur au kilo octet qui se transmettent mal. donc résolu.

[kertimanoff]

Idéalement, il faut demander à l'utilisateur quel est le type de fichier (binaire/texte)

dans cette idée, je pense que le mieux serais plutôt de trouver un moyen d'identifier le type du fichier et aviser en conséquent de façon automatique sans avoir a embéter l'utilisateur pour ça.
je serais donc intéressait si quelqu'un aurait cette astuce.

[dingoth]

Par exemple les fichiers transférés par FTP n'ont pas cette notion : c'est bel et bien à l'utilisateur de déterminer la méthode de transmission de ces fichiers : binaire ou texte.

[kertimanoff]

Comme c'est cruel ! Comme si on pourrais vouloir envoyer un fichier binaire en mode texte...