タグ付けされた質問 「mime」


3
libmagic / fileに.docxファイルを検出させる
他の場所で見られるように、docx、xlsx、およびpttxはZIPです。Webアプリケーションにそれらをアップロードするとき、file(libmagicおよびを介してpython-magic)ZIPとして検出します。 ファイルの内容をデータベースにblobとして保存しますが、当然、どのような種類のファイルであるかをユーザーに信頼したくありません。したがってfile、ダウンロード中にファイル名を信頼し、自動的に生成したいと思います。 修正できることは知っ/etc/magicていますが、フォーマット(magic(5))は私には複雑すぎます。Debianのバグでこの問題に関するバグレポートを見つけましたが、2008年以降のものであるため、すぐには修正されないようです。 私の他の唯一の選択肢は、ユーザーを実際に信頼することですが(ただし、コンテンツをblobとして保存する)、ファイル名に基づいてファイル拡張子のみをチェックすることです。このようにして、一部の拡張機能を禁止し、他の拡張機能を許可できます。また、ユーザーがファイルを再ダウンロードするときに、アップロードした方法に関係なく使用できます。ただし、ファイルを他のユーザーと共有する場合、このソリューションは安全ではありません。ファイルの名前を変更してアップロードできるようにするだけです。 何か案は? 最後に、docxなどのマジックナンバーのリストを見つけましたが、これらをmagic(5)フォーマットに変換することはできません。
17 linux  debian  unix  mime 

2
メールのMIMEにContent-IDヘッダーが存在するということは、添付ファイルを埋め込む必要があるということですか?
私たちが持っている2つの異なるサードパーティのメール製品は、メールのMIMEソースのcontent-idヘッダーの存在に異なる反応を示しています。これにより、解決しようとしているユーザーエクスペリエンスに一貫性がなくなります。 次に例を示します。 --boundary-example Content-Location: CID:somethingatelse Content-ID: <foo4atfoo1atbar.net> Content-Type: IMAGE/GIF Content-Transfer-Encoding: BASE64 R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNv cHlyaWdodCAoQykgMTk5LiBVbmF1dGhvcml6ZWQgZHV wbGljYXRpb24gcHJvaGliaXRlZC4A etc.. 1つのメール製品がこれを埋め込み画像として解釈します。もう1つは、これを通常の添付ファイル(埋め込みではない)として解釈します。Content-ID行を完全に削除すると、どちらの製品も添付ファイルが埋め込まれていないと見なします。 どの動作が正しいかを明確に結論付ける特定のRFCはありますか?同僚と私は、冒頭の要約で次のように述べているRFC2392をレビューしました。 電子メール内で[MIME]を使用してWebページとその 関連画像を伝達するには、HTML がメッセージに含まれる画像やその他のデータを参照できるようにするためのURLスキームが必要です。Content-IDの Uniform Resource Locator、「cid:」がその目的を果たします。[…]「cid」スキームは、メッセージの特定の本文部分を指します。通常、その使用は、参照している本文部分と同じメッセージ内の他の本文部分への参照に限定されます。「中間」スキームは、コンテンツIDのアドレスを含めることにより、指定されたメッセージ内の特定のボディパーツを指す場合もあります。 したがって、絶対的ではありませんが、すべての埋め込みアイテムはそれらを参照するためにcidを必要とするため、「通常は同じメッセージ内の他のボディパーツに限定されます」、添付ファイルには cid は必要ないと考えます、電子メール製品がcidの存在を「埋め込み意図」の指標として扱うことは合理的な動作です。 これについて確認をもらえますか?
11 email  mime  rfc 


3
IIS 7から不明なファイルタイプを提供する方法
IIS 7で不明なファイルタイプを提供する方法はありますか? 実行がオフになっており、すべてが静的ファイルとして提供される単一のディレクトリに対してのみこれを実行したいと思います。 現状では、MIMEタイプとして機能させたいファイル拡張子をそれぞれ追加する必要があります。私はすべてを提供したいと思います。これはどのように行うことができますか?

3
nginx、x-accel-redirectおよびmimeタイプ
私のnginx 0.8.34セットアップでは、X-Accel-Redirect機能を使用して、アプリケーション自体でダウンロードを処理せずに、アプリケーションコードでファイルのダウンロードを制御しています。 多くの苦痛の後、これは今や基本的に動作しますが、nginxは常にtext/htmlコンテンツタイプのファイルを返します。 デフォルトのコンテンツタイプは、httpブロックで指定されたapplication / octet-stream です。 サーバーブロックには、特に、ファイルが格納されているディレクトリの定義が含まれています。 location /files { default_type application/octet-stream; alias /srv/www/uploads; internal; } したがって、ここでもコンテンツタイプを指定しましたが、何も変更されていません。 アプリケーションでContent-Typeを設定したくないので、速度が低下します(最初に確認する必要があります)。したがって、理想的には、nginxはファイル拡張子に基づいて正しいmimetypeを返します(httpブロックにはmime.typesを含めます)。
9 nginx  mime  mime-type 
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.