从 Process.StandardOutput 捕获二进制输出答案

【问题标题】：Capturing binary output from Process.StandardOutput从 Process.StandardOutput 捕获二进制输出
【发布时间】：2011-05-07 19:05:41
【问题描述】：

在 C#（在 SuSE 上的 Mono 2.8 下运行的 .NET 4.0）中，我想运行一个外部批处理命令并以二进制形式捕获其输出。我使用的外部工具称为“samtools”（samtools.sourceforge.net），除其他外，它可以从称为 BAM 的索引二进制文件格式返回记录。

我使用 Process.Start 来运行外部命令，并且我知道我可以通过重定向 Process.StandardOutput 来捕获它的输出。问题是，这是一个带有编码的文本流，所以它不能让我访问输出的原始字节。我发现几乎可行的解决方案是访问底层流。

这是我的代码：

        Process cmdProcess = new Process();
        ProcessStartInfo cmdStartInfo = new ProcessStartInfo();
        cmdStartInfo.FileName = "samtools";

        cmdStartInfo.RedirectStandardError = true;
        cmdStartInfo.RedirectStandardOutput = true;
        cmdStartInfo.RedirectStandardInput = false;
        cmdStartInfo.UseShellExecute = false;
        cmdStartInfo.CreateNoWindow = true;

        cmdStartInfo.Arguments = "view -u " + BamFileName + " " + chromosome + ":" + start + "-" + end;

        cmdProcess.EnableRaisingEvents = true;
        cmdProcess.StartInfo = cmdStartInfo;
        cmdProcess.Start();

        // Prepare to read each alignment (binary)
        var br = new BinaryReader(cmdProcess.StandardOutput.BaseStream);

        while (!cmdProcess.StandardOutput.EndOfStream)
        {
            // Consume the initial, undocumented BAM data 
            br.ReadBytes(23);

// ...更多解析如下

但是当我运行它时，我读取的前 23 个字节不是输出中的前 23 个字节，而是下游的几百或几千个字节。我假设 StreamReader 做了一些缓冲，所以底层流已经提前了，比如说 4K 进入输出。底层流不支持寻回起点。

我被困在这里了。有没有人有运行外部命令并以二进制形式捕获其标准输出的有效解决方案？输出可能非常大，所以我想流式传输它。

任何帮助表示赞赏。

顺便说一句，我目前的解决方法是让 samtools 以文本格式返回记录，然后解析这些记录，但这很慢，我希望直接使用二进制格式来加快速度。

【问题讨论】：

我唯一能想到的就是将所需的编码设置为 Unicode，然后将 StreamReader 中的每个字符分成两个字节。这将是一个可怕的黑客攻击，如果输出的字节数为奇数，可能会惨遭失败。一种解决方法是实现您自己的编码，将字节直接映射到它们各自的 char 值，如 ASCII，但不将上限转换为“？”。但我会让别人想出一个正确的答案。 :)
事实发生 10 年后，但是当 Process 实例为 OutputDataReceived 事件做好准备时，您的数据是否正在被使用和处理？我自己正在寻找它，但我认为 Process 类不能用于捕获二进制数据，因此。

标签： c# process binary

【解决方案1】：

使用StandardOutput.BaseStream 是正确的方法，但您不能使用cmdProcess.StandardOutput 的任何其他属性或方法。例如，访问cmdProcess.StandardOutput.EndOfStream 将导致StreamReader 的StandardOutput 读取部分流，从而删除您要访问的数据。

相反，只需从br 读取和解析数据（假设您知道如何解析数据，并且不会读取流的末尾，或者愿意捕获EndOfStreamException）。或者，如果您不知道数据有多大，请使用Stream.CopyTo 将整个标准输出流复制到新文件或内存流中。

【讨论】：

应该在哪里调用 Stream.CopyTo 来处理可能非常巨大的整个输出？

【解决方案2】：

由于您明确指定在 Suse linux 和 mono 上运行，您可以通过使用本机 unix 调用来创建重定向并从流中读取来解决该问题。如：

using System;
using System.Diagnostics;
using System.IO;
using Mono.Unix;

class Test
{
    public static void Main()
    {
        int reading, writing;
        Mono.Unix.Native.Syscall.pipe(out reading, out writing);
        int stdout = Mono.Unix.Native.Syscall.dup(1);
        Mono.Unix.Native.Syscall.dup2(writing, 1);
        Mono.Unix.Native.Syscall.close(writing);

        Process cmdProcess = new Process();
        ProcessStartInfo cmdStartInfo = new ProcessStartInfo();
        cmdStartInfo.FileName = "cat";
        cmdStartInfo.CreateNoWindow = true;
        cmdStartInfo.Arguments = "test.exe";
        cmdProcess.StartInfo = cmdStartInfo;
        cmdProcess.Start();

        Mono.Unix.Native.Syscall.dup2(stdout, 1);
        Mono.Unix.Native.Syscall.close(stdout);

        Stream s = new UnixStream(reading);
        byte[] buf = new byte[1024];
        int bytes = 0;
        int current;
        while((current = s.Read(buf, 0, buf.Length)) > 0)
        {
            bytes += current;
        }
        Mono.Unix.Native.Syscall.close(reading);
        Console.WriteLine("{0} bytes read", bytes);
    }
}

在 unix 下，文件描述符由子进程继承，除非另有标记（close on exec）。因此，要重定向子进程的stdout，您需要做的就是在调用exec 之前更改父进程中的文件描述符#1。 Unix 还提供了一个方便的东西，称为 pipe，它是一个单向通信通道，有两个文件描述符代表两个端点。对于复制文件描述符，您可以使用dup 或dup2 两者都创建描述符的等效副本，但dup 返回系统分配的新描述符，dup2 将副本放置在特定目标中（必要时关闭它）。那么上面的代码做了什么：

创建一个带有端点reading 和writing 的管道
保存当前stdout 描述符的副本
将管道的写入端点分配给stdout并关闭原始端点
启动子进程，使其继承连接到管道写入端点的stdout
恢复保存的stdout
通过将管道包装在UnixStream 中，从管道的reading 端点读取

注意，在本机代码中，进程通常由fork+exec 对启动，因此可以在子进程本身中修改文件描述符，但在加载新程序之前。这个托管版本不是线程安全的，因为它必须临时修改父进程的stdout。

由于代码在没有托管重定向的情况下启动子进程，因此 .NET 运行时不会更改任何描述符或创建任何流。因此，孩子输出的唯一读者将是用户代码，它使用UnixStream 来解决StreamReader 的编码问题，

【讨论】：

您能否评论 (1) 管道如何连接到新进程的标准输出，以及 (2) 这如何解决 StreamReader 在创建时缓冲一些字节的问题？

【解决方案3】：

我查看了反射器的情况。在我看来，StreamReader 在您调用 read 之前不会读取。但它是用 0x1000 的缓冲区大小创建的，所以也许它确实如此。但幸运的是，在你真正从中读取之前，你可以安全地从中取出缓冲数据：它有一个私有字段 byte[] byteBuffer，以及两个整数字段 byteLen 和 bytePos，第一个表示缓冲区中有多少字节，第二个意思是你吃了多少，应该是零。所以首先用反射读取这个缓冲区，然后创建 BinaryReader。

【讨论】：

哦，现在我明白了，您调用 EndOfStream，这确实会导致缓冲读取。所以就像 Bradley 建议的那样，不要那样做，你会没事的，而不会弄乱私有字段。

【解决方案4】：

您可以使用CliWrap 抽象出System.Diagnostics.Process 背后的表达API 以运行shell 命令。例如，您可以这样做：

var output = new MemoryStream(); // a stream, but CliWrap supports other targets too

var cmd = Cli.Wrap("app.exe").WithArguments("foo bar") | output;

await cmd.ExecuteAsync();

【讨论】：