1

これは非常に些細なことだと思うので、これを尋ねるのは嫌いです。しかし、高級言語に慣れている人にとって、これは本当の問題です。

PDFiumを使用して画像をPDFに生成するC++プログラムを入手しました。名前付きパイプを介して C++ プログラムと通信する C# プログラムがあります。PDF ファイル (バイト配列として保存される) は、パイプによって送信されます。そして、ここに私の問題があります。

ストリームの 374 番目の位置は NUL バイト (00) であり、それ以降のデータに到達するにはあまりにも愚かです。

ここに私のコードがあります:

LPTSTR lpszPipename2 = TEXT("\\\\.\\pipe\\myNamedPipe2"); 
hPipe2=CreateFile(lpszPipename2, GENERIC_READ, 0,NULL,OPEN_EXISTING,FILE_FLAG_OVERLAPPED,NULL);
if(ReadFile( hPipe2, chBuf, dwBytesToRead, &cbRead, NULL))
{
    PDFData = chBuf;
}

読み取る dwBytes はファイルのサイズで、cbRead は正しい数値を示します。しかし、PDFData には最初の 373 バイトしか含まれていません。イミディエイト ウィンドウで 373 番目の位置を超えるデータがあることを確認しましたが、処理方法がわかりません。データを文字配列に入れる必要があります。

すでに述べたように、これは非常に些細なことだと思います。しかし、問題の原因はわかっていますが、それを修正する方法がまったくわかりません。

感謝と敬意

マイケル

編集: C# コード。そのすべてが完璧です。しかし、この問題は C++ 側にあると確信しています。

public void SendRawData(byte[] data)
{
  while (clientse == null || clientse.stream == null)
  { }
  if (clientse.stream.CanWrite)
  {
    clientse.stream.Write(data, 0, data.Length);
    clientse.stream.Flush();
  }
}
private void ListenForClients()
    {
        while (true)
        {
            clientHandle = CreateNamedPipe(this.pipeName, DUPLEX | FILE_FLAG_OVERLAPPED, 0, 255, BUFFER_SIZE, BUFFER_SIZE, 0, IntPtr.Zero);

            //could not create named pipe
            if (clientHandle.IsInvalid)
                return;

            int success = ConnectNamedPipe(clientHandle, IntPtr.Zero);

            //could not connect client
            if (success == 0)
                return;

            clientse = new Client();
            clientse.handle = clientHandle;
            clientse.stream = new FileStream(clientse.handle, FileAccess.ReadWrite, BUFFER_SIZE, true);

            if (ClientType == 0)
            {
                Thread readThread = new Thread(new ThreadStart(Read));
                readThread.Start();
            }                
        }
    }

「解決策」: 実際、これは本当の問題ではありませんでした。ワイヤーを交差させただけです。chBuf は PDFData にコピーした後、またはその値を読んだときに VS のように見えましたが、これらの 373 バイトしかありません。約 20 キロバイトすべてがその位置にコピーされました。私はそれを知っていましたが、文字列が 373 文字の後に終了するかどうかを PDFium ソースがどのように認識すべきかを理解していませんでした。

ええと... PDFiumソースは、長さを渡す必要があることを知っています。によって決定されたもの

size_t len = PDFData.length();

したがって、もちろんわずか 373 バイトでした。

4

3 に答える 3

2

null 文字'\0'は、C/C++ でchar*文字列を終了するために使用されます。そのため、どのライブラリ関数 ( strlen()、strncpy()、など) も、暗黙的な文字列終了インジケータとしてヌル文字を使用します。あなたのコードは明らかにこれをどこかで行っています。代わりに、memcpy()またはstd::vector<char>明示的なデータ長を持つ a のようなものを使用してください。

于 2014-10-10T13:03:17.967 に答える
1

string:assign（http://www.cplusplus.com/reference/string/string/assign/）をご覧ください

文字列代入演算子 fromchar *は、C スタイルの文字列終了規則を使用します。assign「バッファ」呼び出しが必要です。

string& assign (const char* s, size_t n);

これには任意NULの s が含まれます。

そうは言っても、バイトのベクトルは実際にはより良い選択かもしれません。

于 2014-10-10T13:14:14.737 に答える
0

実際、これは実際の問題ではありませんでした。ワイヤーを交差させただけです。chBuf は PDFData にコピーした後、またはその値を読んだときに VS のように見えましたが、これらの 373 バイトしかありません。約 20 キロバイトすべてがその位置にコピーされました。私はそれを知っていましたが、文字列が 373 文字の後に終了するかどうかを PDFium ソースがどのように認識すべきかを理解していませんでした。

ええと... PDFiumソースは、長さを渡す必要があることを知っています。によって決定されたもの

size_t len = PDFData.length();

したがって、もちろんわずか 373 バイトでした。

そんなことでお騒がせしてすみませんでした

于 2014-10-10T13:56:23.890 に答える