2016-01-08 4 views
0

Я использую двоичный файл для хранения измеренных данных некоторого продукта. Ранее продукт был единственным, теперь я должен иметь возможность сохранять/загружать больше типов продуктов.C# BinaryReader - данные, которые могут быть или не быть в двоичном файле

Я собираюсь сохранить дескриптор типа в начале файла, 1 байт должен быть абсолютно достаточным, будет только несколько типов (2, возможно, 3 или 4 в будущем).

Проблема в том, что мне все еще нужно иметь возможность загружать старые двоичные файлы без этого дескриптора. Вот мой старый код с комментариями, где я хочу, чтобы проверить наличие дескриптора, а затем принять решение о типе продукта, как это:

  1. Нет дескрипторе -> старый продукт
  2. Descriptor = ххх -> новый продукт xxx

Можно ли сохранить дескриптор в таком формате? Я думаю, что вызов reader.PeekChar() - это только одна возможность из-за того, что вы не переходите к следующим байтам, но я не уверен, как его использовать в этом случае.

 BinaryReader reader; 
    using (reader = new BinaryReader(File.Open(header.path, FileMode.Open, FileAccess.Read))) 
    { 
     // ... 
     // check presence of product type descriptor 
     // make a decision of type 
     // ... 

     DateTime measTime = DateTime.FromOADate(reader.ReadDouble()); 
     double diameter = reader.ReadDouble(); 
     double plusToler = reader.ReadDouble(); 
     double minusToler = reader.ReadDouble(); 
    } 
+2

Ваш исходный поток является обычным файлом и, следовательно, доступен для поиска, не так ли? Если да, то в чем проблема (временно) «переход к следующим байтам»? –

+0

О, вы правы. Временного поиска мне не приходило. – Majak

+0

Я использую фиктивный дескриптор для старых продуктов и отбрасываю его, когда обнаружено фиктивное значение. Это будет намного эффективнее, чем перемещение назад и вперед в файле. Оба метода будут работать – nicomp

ответ

1

Проблема, если я понимаю correclty, что вы не знаете ли вы читаете дескриптор типа (новый файл) или первое значение данных (старый файл).

Один простой способ решить это - выбрать другое расширение файла для новых файлов, но в зависимости от вашей ситуации это может быть не вариант.

Если нет, вы можете придать дескриптору продукта магическое значение, которое никогда (или маловероятно) не появляется в старом формате файла. Нечто похожее на символы ASCII "TYP", за которым следует байт дескриптора продукта, вряд ли появится в старом формате файла (который начинается с значения double).

Вы можете даже выбрать для сериализации double.MinValue в качестве магического значения, так как DateTime.FromOADate может читать только

значение между отрицательным 657435.0 с помощью позитивного 2958465.99999999

Это было бы полностью исключить ложно идентифицировать старый файл как новый.

+0

Да, я получил второе решение, которое вы предлагаете. Я сохраняю последовательность 'char [4]' в таком же формате, как вы упомянули, поскольку эта последовательность не может отображаться в старых данных. Затем с использованием 'reader.ReadChars (4)', анализа синтаксического анализа и, наконец, 'reader.Seek (-4, SeekOrigin.Current)' в случае дескриптора не было найдено, – Majak