2009-08-25 8 views
0

J'ai un fichier binaire. Il se compose de 4 messages, chacun d'une taille de 100 octets. Je veux lire ces 2 derniers messages à nouveau. J'utilise l'objet BinaryReader. Je cherche à psosition 200 et puis je lis: BinaryReaderObject.read (charBuffer, 0, 10000), où charBuffer est grand enougth. Je reçois tout le temps le nombre de lectures est toujours manquant 1. Au lieu d'obtenir 200 je reçois 199. Au lieu d'obtenir 400, je reçois 399. J'ai vérifié et j'ai vu que la taille du fichier est correcte et les données que je reçois commence au bon endroit.lecture de fichier C# .NET

Thnaks,

Répondre

0

Le problème était que j'ai utilisé un wrapper à l'objet BinaryReader. Lors de l'appel de la méthode Read, certaines fonctions sont surchargées. Au lieu de cela, en utilisant la signeture de char [], j'ai utilisé byte []. Jusqu'à maintenant, cela fonctionnait bien car il n'y avait que l'utilisation de utf-8, mais maintenant, quand j'ai entré de vraies données binaires au début de chaque message, cela a causé le problème.

1

Astuce: index de tableau à base zéro, et les positions de base zéro ... premier octet commencera à la position zéro.

+0

Droite. Je pensais la même chose, mais je pense que les chiffres sont corrects (c'est-à-dire que le premier enregistrement commence à 0 et passe à 99, le deuxième enregistrement commence à 100, passe à 199, etc ...). Chercher à la position 200 semble être le bon endroit pour le début du 3ème album. –

+0

Où voulez-vous dire zéro basé, dans le fichier dans ce que je lis? Comme je l'ai dit je reçois des données démarrant correctement, et la quantité de données que je récupère est manquante 0r –

+1

Les ordinateurs comptent à partir de zéro. Le premier élément d'un tableau est 0, le second est 1, etc. Ceci est appelé un tableau basé sur zéro; parce que ça commence à zéro. Les fichiers sont traités comme des tableaux d'octets basés sur zéro, donc la position 200 est le 201e octet par un comptage «normal», expliquant l'erreur «un par un» que vous rencontrez. –

1
  1. Recherchez la position de fin et d'impression. Est-ce comme prévu?
  2. Imprimez la position après avoir lu le 199 - est-ce comme prévu?
  3. Essayez de lire 1 octet de plus de la position après avoir obtenu 199 - obtenez-vous EOF?
  4. Comment vérifiez-vous la taille du fichier?
  5. Diffère les 199 octets avec les attendus - qu'est-ce qui est différent?

Deux choses que je vérifierais

  1. transformations de CR/LF
  2. que la taille est ce que vous pensez qu'il est.
+1

S'il s'agit d'un fichier "binaire", "CR/LF" ne devrait pas faire la différence. Mais je pense que vous pourriez être sur quelque chose s'il utilise des chaînes et l'encodage pourrait affecter la taille. –

+0

Un fichier n'est ni binaire ni textuel - c'est comme ça que vous l'ouvrez et le lisez. –

+0

Il parle d'enregistrements de 100 octets ajoutés à un fichier. Il l'a appelé un fichier binaire. Je le citais. Tous les fichiers sont binaires (par opposition à analogiques), mais oui, que ce soit "binaire" ou "texte" dépend du lecteur sur la façon dont il décode les données. –

5

Essayez ce code et voyez ce qui se passe avec votre fichier.

String message = @"Read {0} bytes into the buffer."; 

String fileName = @"TEST.DAT"; 

Int32 recordSize = 100; 

Byte[] buffer = new Byte[recordSize]; 

using (BinaryReader br = new BinaryReader(File.OpenRead(fileName))) 
{ 
    br.BaseStream.Seek(2 * recordSize, SeekOrigin.Begin); 

    Console.WriteLine(message, br.Read(buffer, 0, recordSize)); 
    Console.WriteLine(message, br.Read(buffer, 0, recordSize)); 
} 

Console.ReadLine(); 

Je reçois la sortie suivante avec un fichier de test de 400 octets.

Read 100 bytes into the buffer. 
Read 100 bytes into the buffer. 

Si je cherche à 2 * recordSize + 1 ou utiliser un fichier de 399 octets, je reçois la sortie suivante.

Read 100 bytes into the buffer. 
Read 99 bytes into the buffer. 

Cela fonctionne comme prévu.