如何用C#读取Btrieve维护工具恢复生成的ASCII顺序文件？

Absolutely, you can read those .seq files generated by BUTIL -recover in C#—the trick is addressing two key quirks that make them hard to parse with standard tools like Notepad++: their encoding and fixed-length record structure. Let’s walk through how to handle this properly.

Why Notepad++ Can’t Read Them #

First, even though the docs call these "ASCII files," they’re actually using an OEM character encoding (most commonly IBM850 or Windows-1252) instead of UTF-8, which is what Notepad++ defaults to. That’s why you see garbled text when opening them directly. You can test this by switching Notepad++’s encoding to "Western European (IBM850)" or "Windows-1252"—the text should become readable if you pick the right one.

Step 1: Confirm Key Details Before Coding #

Before writing any C# code, you need two critical pieces of info:

• Record Length: The fixed length of each record in the .seq file, which matches the record length of your original Btrieve table. You can get this from the Btrieve Maintenance Utility (look at the table’s properties) or via Btrieve’s API.
• Correct Encoding: As mentioned, start with IBM850 (code page 850) or Windows-1252 (code page 1252)—these are the most common for Btrieve on Windows.

Step 2: C# Implementation Example #

Here’s a straightforward way to read the file, using BinaryReader to handle the fixed-length records reliably (text readers can mess up with embedded nulls or line breaks):

using System;
using System.IO;
using System.Text;

class BtrieveSeqFileReader
{
    static void Main(string[] args)
    {
        // Replace with your actual file path
        string seqFilePath = @"C:\Data\yourfile.xq1.seq";
        // Replace with your Btrieve table's record length
        int recordLength = 300;
        // Use the encoding confirmed earlier (IBM850 in this example)
        Encoding btrieveEncoding = Encoding.GetEncoding(850);

        using (FileStream fileStream = new FileStream(seqFilePath, FileMode.Open, FileAccess.Read))
        using (BinaryReader reader = new BinaryReader(fileStream, btrieveEncoding))
        {
            byte[] recordBuffer = new byte[recordLength];
            int bytesRead;

            // Loop through each fixed-length record
            while ((bytesRead = reader.Read(recordBuffer, 0, recordLength)) > 0)
            {
                // Handle the final record if it's shorter (uncommon, but possible)
                if (bytesRead < recordLength)
                {
                    Array.Resize(ref recordBuffer, bytesRead);
                }

                // Convert the byte array to a string using the correct encoding
                string recordContent = btrieveEncoding.GetString(recordBuffer);
                
                // Clean up trailing nulls (common in fixed-length records) and process
                string cleanedRecord = recordContent.TrimEnd('\0');
                Console.WriteLine(cleanedRecord);
                // Add your own logic here to parse fields, save to a database, etc.
            }
        }
    }
}

Key Notes for Success #

• Double-Check Record Length: If you use the wrong record length, all subsequent records will be misaligned, leading to garbled text. Verify this value carefully.
• Tweak Encoding if Needed: If IBM850 doesn’t work, try Windows-1252 (code page 1252) or IBM437—some older Btrieve setups use these.
• Parsing Specific Fields: If you need to extract individual fields from each record, you’ll need the original table’s field layout (field positions, lengths, and data types). You can then slice the recordBuffer byte array or recordContent string to pull out each field’s value.
• Avoid Text Readers: Tools like StreamReader aren’t ideal here because fixed-length records often contain embedded nulls or line breaks that break text-based reading. Stick to binary reading for consistency.

内容的提问来源于stack exchange，提问作者Jordy van Eijk