14

すべきではないのに、Base64 の無効な文字エラーが発生し続けます。

プログラムは XML ファイルを取得し、それをドキュメントにエクスポートします。ユーザーが望む場合は、ファイルも圧縮します。圧縮は正常に機能し、UTF-8 にエンコードされてファイルに書き込まれる Base64 文字列を返します。

ドキュメントをプログラムにリロードするときは、圧縮されているかどうかを確認する必要があります。コードは次のとおりです。

byte[] gzBuffer = System.Convert.FromBase64String(text);
return "1F-8B-08" == BitConverter.ToString(new List<Byte>(gzBuffer).GetRange(4, 3).ToArray());

文字列の先頭をチェックして、GZip コードが含まれているかどうかを確認します。

問題は、すべてのテストが機能することです。文字列を取得し、圧縮、解凍して、元の文字列と比較します。問題は、ADO レコードセットから返された文字列を取得するときです。文字列はまさにファイルに書き込まれたものです（最後に「\ 0」が追加されていますが、何もしないとは思いませんが、トリミングしてもまだスローされます）。文字列全体をコピーしてテストメソッドに貼り付け、それを圧縮/解凍しました。正常に動作します。

テストはパスしますが、コードはまったく同じ文字列を使用して失敗しますか? 唯一の違いは、通常の文字列を宣言して渡すのではなく、レコードセットから返される文字列を取得していることです。

私が間違っていることについてのアイデアはありますか？

4

5 に答える 5

3

null char が許可されるかどうかは、問題の base64 コーデックによって異なります。Base64 標準のあいまいさ (正式な正確な仕様はありません) を考えると、多くの実装では空白として無視されます。そして、他の人が問題としてフラグを立てることができます。そして、最もバグのある人は気付かず、喜んでデコードしようとします... :-/

しかし、C＃の実装はそれを好まないように思えます（これは有効なアプローチの1つです）。削除が役立つ場合は、それを行う必要があります。

ちょっとした追加コメント: UTF-8 は必須ではありません。ISO-8859-x 別名 Latin-x、および 7 ビット Ascii も同様に機能します。これは、Base64 が、すべての 7 ビット ASCII 互換エンコーディングで動作する 7 ビット サブセットのみを使用するように特別に設計されているためです。

于 2009-04-02T18:08:58.563 に答える
0

文字列からBase64を変換する際の落とし穴のひとつは、一部の変換関数は前述の「data：image / jpg; base64」を使用し、その他の関数は実際のデータのみを受け入れることです。

于 2012-05-16T06:33:21.187 に答える
0

文字列の末尾から \0 を削除できない場合は、エンコードする文字列ごとに独自の文字を追加し、デコード時に削除できます。

于 2009-04-02T19:28:41.617 に答える