2

「Test」という単語を含む単純な PDF ドキュメントを作成し、C# コンソール アプリケーションでバイト ストリームを作成しました。

buff = File.ReadAllBytes(<Path of File>);

ファイルのサイズは約 9,651 バイトです。ファイルのバイト配列とバイト配列の長さを引数として受け取る関数をエクスポートする Win32 C dll も作成し、これを使用して C# で宣言しました。

[DllImport("<path to dll>", CallingConvention = CallingConvention.Cdecl)] public static extern int file_data(byte[] byteArray, int length);

C dll のメソッドは、次のようにエクスポートされます。

#define FILEDATA_API __declspec(dllexport) FILEDATA_API int file_data(char *byteArray, int size);

次に呼び出しret = file_data(buff, buff.length)ました。Cコードでは、次のように、一時ファイルに直接受け取った文字ポインターを1文字ずつ記述しました。

    while (length> 0)
    {
        fprintf(outFile, "%c", *fileData); //fileData is the actual byte array received from C# Code
        fileData++;
        length--;
    }

しかし、ここで問題が発生します。バイト配列を 1 文字ずつファイルにダンプする C コードは、9,755 バイトのサイズのファイルを生成します。内部のコンテンツのほとんどは正しいように見えますが、いくつかの新しい行が導入されていることを除いて (私の知る限り、いくつかの追加データである可能性があります)、PDF ファイルが破損し、このダンプされたバージョンが Adob​​e で開かれません。 . 誰かが私が間違っているかもしれない場所についていくつかの指針を提供してもらえますか? %s in fprintPDF のバイト配列の一部の組み合わせにより、C で null で終了する文字列が生成され、予想よりも少ないデータがダンプされるため、使用できません。

ありがとう。

アップデート：

  1. 望ましい動作は、ファイル バイト配列が C# から受信され、C コードを使用してファイルに書き込まれたときに、ファイルが Adob​​e で正常に開かれるようにすることです。
  2. 問題に存在するコードは、誰かが単にファイルへの char ポインタを書き出す win32 dll を生成するのに十分なはずですが、さらに詳細をいくつか追加しました。
4

1 に答える 1

2

おそらくモードフラグfopenなしで呼び出しています。bモード指定子に追加bします。

FILE *outFile = fopen("file.txt", "wb")

このサイトから（強調鉱山）：

テキスト ファイルは、一連のテキスト行を含むファイルです。アプリケーションを実行する環境によっては、システム固有のテキスト ファイル形式に適合させるために、テキスト モードでの入出力操作で特殊文字の変換が発生する場合があります。一部の環境では変換が行われず、テキスト ファイルとバイナリ ファイルの両方が同じように扱われますが、適切なモードを使用すると移植性が向上します。

私の経験では、Windows でのこの「変換」\nは\r\n少なくとも .

于 2015-11-27T13:24:35.600 に答える