C# http通信で受信したファイルが壊れてしまっている

Question

前提・実現したいこと

C#でhttp通信をするサーバーとクライアントを作成しています。
http通信でクライアントから動画をサーバーに送りたいです。

発生している問題・エラーメッセージ

サーバーで、クライアントから受信したbyte配列をmp4ファイルに変換してもmp4ファイルが壊れてしまっている

該当のソースコード

var context = listener.GetContext();
context.Response.ContentType = "video/mp4";
var video = new StreamReader(context.Request.InputStream).ReadToEnd();  //postされたデータをstringに
byte[] videobytes = Encoding.GetEncoding("shift_jis").GetBytes(video);  
FileStream vidFile = new FileStream(@"C:\Users\ig_ei\OneDrive\Desktop\test.mp4", FileMode.Create);      
BinaryWriter writer = new BinaryWriter(vidFile);
writer.Write(video);  //バイト配列をファイルに書き出し

↑サーバーサイドのコードです。

試したこと

元の動画と壊れてしまっている動画の拡張子をtxtに変えて中身を見たところ構成がとても似ていたので文字化けしてしまっているだけだと思います。サーバーサイドで文字コードを指定する必要があるのでしょうか？

Comments

[退会済みユーザー]

意味不明です。単にクライアントの PC からファイルをサーバーにアップロードできれば良いのですか？　サーバー側、クライアント側のアプリは何なのですか？　「該当のソースコード」というのは一体何をするものなのですか？

[The8]

すみません、情報不足でした
クライアントのpcからサーバーにファイルをアップロードしたいです
その際http通信で転送しようと思うのですが、どうも送られてきたファイルが壊れてしまっているようです。
ソースコードはサーバーサイドのもので、クライアントからpostで送られたデータをbyte配列に変換して最終的にファイルに書き出してます。

[takasima20]

C# は知らんけど "shift_jis" とか関係あるのかな?

[退会済みユーザー]

サーバー側、クライアント側のアプリは何なのですか？

[退会済みユーザー]

上の意味が分かりますか？　例えば、「サーバー側が ASP.NET Web Forms アプリ、クライアント側が Windows Forms アプリ」といった答えを書いてほしいと言っているのですよ。

[The8]

クライアント、サーバーどちらも.Net frameworkのコンソールアプリケーションです

[退会済みユーザー]

> クライアント、サーバーどちらも.Net frameworkのコンソールアプリケーションです

クライアントはコンソールアプリでよくても、サーバー側はコンソールアプリでは全くダメ＆問題外です。このまま話を続けても、質問者さんの知識不足で話が通じないと思います。もっと勉強してきてください。

[KOZ6.0]

いやいや、コンソールアプリでサーバーを作っても大丈夫ですよ。

「非同期サーバー ソケットの使用」
https://docs.microsoft.com/ja-jp/dotnet/framework/network-programming/using-an-asynchronous-server-socket

サンプルはコンソールアプリです。

ASP.NET で作るより、考えなければいけないことは多いですが、全くダメ＆問題外ってことはありません。

[YAmaGNZ]

HttpListenerクラスを使えば、簡易なHTTPサーバをコンソールアプリで作成できるかと
出来ることは限られるかもしれませんが、問題外ではないでしょう。

[退会済みユーザー]

自力で http サーバーを実装しているということですか？ そうだとしたら「全くダメ&問題外」ということはなかったですね。

失礼しました > 質問者さん

Answer 1

postされたデータをそのままファイルに書けばいいのではないでしょうか？

using (FileStream fs = new FileStream(@"C:\Users\ig_ei\OneDrive\Desktop\test.mp4", FileMode.Create))
{
    context.Request.InputStream.CopyTo(fs);
}

また、レスポンスの返しがおかしいかと思います。
レスポンスでmp4を返すわけではないと思いますので、
context.Response.ContentType = "video/mp4";
とするのではなく

context.Response.StatusCode = 200;
context.Response.ContentType = "text/html";
using (StreamWriter writer = new StreamWriter(context.Response.OutputStream, Encoding.UTF8))
    writer.WriteLine("Ok");

context.Response.Close();

と正常に受信した旨を返すべきかと思います。

Answer 2

「テキストファイル」「バイナリファイル」と分けることもありますが、ファイルは全て「バイナリ」です。
決まった範囲の値しかない場合、あるいは、ある決まりの下に解釈すると印字可能な文字に置き換えられるコードだけで構成されているバイナリファイルを、特に「テキストファイル」と呼びます。
この、「ある決まり」が、Shift JIS であったり、EUC であったり、UTF-8 などです。
さて、mp4 ファイルということですが、これはバイナリファイルです。どう解釈しても、印字可能な文字だけで構成されているわけではありません。ですから、「文字化けする」なんてあり得ないし、逆に、Encoding.GetEncoding("shift_jis").GetBytes(video)などとして「データ化け」させています。

Answer 3

送信側がどうなっているか書いてないので分かりませんが、ファイルアップロードでバイナリデータをサーバーに送信する場合、普通 "multipart/form-data" 形式にするはずです。

質問者さんの送信用コンソールアプリも多分そうしていると想像しています。

さらに、受信側は HttpListener を利用したアプリで、質問のコードにある変数 listener が HttpListner オブジェクトを指していると理解しています。

その想像が当たっているとすると、そう簡単にはいかないはずです。

なぜなら、"multipart/form-data" 形式でファイルを送信するとその内容は以下のようになりますが（Fiddler でのキャプチャ画像）、この中で目的のファイルのバイト配列は赤枠で囲った部分になります（実際はこの下にずっと続きます）。

この赤枠部分をバイト配列として切り出してきてファイルとして保存するという操作が必要です。

そうするためには、要求ヘッダから boundary を探してきてそれを基準に各部分に分けて、分けた中からファイルの部分を探して上の赤枠部分のバイト配列を取得することになるはずです。

ググって調べてみるとそういうことを考えた人はいるようです。

Httplistener and file upload
https://stackoverflow.com/questions/8466703/httplistener-and-file-upload

回答も付いていますので見てください。検証はしてませんが、かなり大変なのは分かるかと思います。

という訳で、コンソールアプリでは「全くダメ&問題外」ということはないにしても、かなりの無理筋のような気がします。

サーバー側を ASP.NET にすれば、そのあたりはフレームワークが面倒を見てくれて、ごく簡単にアップロードされたファイルを保存できますので、コンソールアプリで実装するというのが必須でなければ、そちらの方向に進むのがお勧めです。

Comments

[YAmaGNZ]

"multipart/form-data"ではなく"application/octet-stream"でPOSTすればHttplistenerのRequest.InputStreamをそのまま保存で送信元のバイナリと差異がないことを確認してますので、無理筋でもないと思います。

[退会済みユーザー]

HttpListener で無理筋でないように送信側を実装すれば無理筋ではなくなるのは当たり前ですよね。

何が普通かについてはいろいろ議論があるかもしれませんが、自分的には "multipart/form-data" 形式が普通と思っているので、その前提で無理筋です。

[tamoto]

Web サイトからのアップロードでしたら form の multipart が一般的ですが、Http を直接使ってコンソールアプリのクライアントから投げているのなら body にバイナリを突っ込む形は極めて自然だと思います。そして、質問者さんの環境は後者だと読み取れます。

[YAmaGNZ]

一般的なブラウザからのアップロードであれば仰るとおりだと思います。
ただ、質問にはクライアントも作成されているとのことでしたので、こうすれば出来るということを書かせてもらいました。

[退会済みユーザー]

web サーバー側も考えた場合は「body にバイナリを突っ込む形は極めて自然」はどうかは疑問です。

でも、そもそもがどういう形式で送受信するかという前提・条件が明確になってないところで議論が始まっているということがアレでしたね。その点、自分も反省。後は質問者さんのレスを待ちたいと思います。

[YAmaGNZ]

HttpMultipartParser（https://www.nuget.org/packages/HttpMultipartParser/）を使えば、"multipart/form-data"でもファイルの取得はできました。

[KOZ6.0]

multipart/form-data は HTML の規格なので http とは切り離して考えるべきです。

元質問者が作っているのは http サーバーであって、web サーバーではないことに注意しましょう。

[退会済みユーザー]

個人的意見ですが、切っても切れないと思っています。HttpListener で無理筋でないように送信側を実装するというように閉じた世界で考えるのであればともかく、自分はそのようには考えてませんでした。質問者さんがそう考えているというのかどうかは質問からは不明ですし。

[KOZ6.0]

html から見ると、たしかに http は切り離せない存在でしょう。

でも、http から html を見ると、そうでもないです。
普通に json を送ったり送られたりしてますし、WebDAV みたいなしくみもある。

まあ、これも私見といえば私見なんでしょうね。

質問の冒頭で

「C#でhttp通信をするサーバーとクライアントを作成しています。」

と書かれているのに Web サーバーという発想が出てくるのか私にはわからないです。

コードと「試したこと」から、おしいところまでいってるっていう様子がうかがえます。

うまくいかなかったらすぐ再質問がくるでしょうから、他の方の回答で解決しちゃってると思ってよいと思うんですけどね。

バイナリ読み出しのところで詰まってなきゃいいかな、という心配はあります。