0

ここで関連する質問があります。ここでは、保存されたファイルの場所へのリンクを作成しようとしていました (場所とファイル名はユーザーのために処理されます)。残念ながら、パス アクセス拒否 (上記のリンクの更新 4 で説明されているように) のため、リンクはファイルを開きません。

可能であれば、私が本当にやりたいことは、ユーザーに保存場所を要求することです (「C:\Bla\Blee」のような入力テキスト要素に入力する必要はありません)。ただし、実証済みの (この場合) FileSaveDialog が SharePoint ページから利用できるとは思いません。

ユーザーに場所の入力を求めることができるようにするための代替手段または回避策はありますか?

アップデート

生成されたファイルは（iTextSharpを介して）サーバー側で生成されるため、生成されたファイルをクライアント側で保存しようとしてもうまくいかないと思います。

更新 2

ファイルへのリンクを作成することにより (私が行ったように、ここでの方法のように)、そのリンクを右クリックして [ターゲットを名前を付けて保存...] を選択し、そうすることができます ([名前を付けて保存] ダイアログが表示され、好きな場所にファイルを保存します）。この場合、ユーザーが右クリックしてメニュー項目 (「対象をファイルに保存...」) を選択する代わりに、同じダイアログをプログラムで呼び出す方法が必要です。リンクをクリックすると、イタチのように [名前を付けて保存] ダイアログがポップアップします。

では、リンクのクリックに応答して、明らかに呼び出し可能なダイアログを呼び出すにはどうすればよいでしょうか?

「合計と支払い合計が一致しません。両方の値に同じ金額を入力して、もう一度やり直してください。」と表示された場合。フォームを再表示する必要がありますか (「show_sections()」関数を作成し、保存ボタンの実行後に呼び出します)?

4

1 に答える 1

1

他の質問を確認しましたが、いくつかの点について明確にしたいと思います。(ここに盲目的に明らかなことがあれば、ご容赦ください。侮辱するつもりはありません。同じページにいることを確認したいだけです。)

まず、client と server。サーバー側のものはすべて、ユーザー アカウントのコンテキストで実行され、それが実行されるマシンに対して相対的です。サーバー側のコードを使用して「これをデスクトップに保存する」と言った場合、これはサーバーのローカル プロセスのデスクトップであり、ほとんど意味がありません。ただし、ログインしているユーザーを偽装している場合は、サーバー上のログインしているユーザーのデスクトップに保存する場合を除いて、これは機能する可能性があります。クライアントとサーバーが同じマシンで実行されていて、クライアントを偽装している場合、これは実際には完全に機能する可能性があります。多分。

次に、右クリックして [名前を付けて保存] を選択します。リンクを右クリックすると、ブラウザに組み込まれた独自のメニュー システムが呼び出されます。そのシステムはブラウザおよび/またはOS固有であり、仕様では定義されていません。90 年代には、VBScript を使用して "キーを送信" し、Internet Explorer にそのリンクを "クリック" させることができたかもしれませんが、その時代は過ぎ去りました。これに最も近い現代の同等物は、あなたがしたくないと私が想像するプラグインを書くことです（そして、ブラウザおよび/またはOS固有のものになるでしょう）。

3 つ目は、MIME タイプです。一般的に言えば、すべての HTTP 応答には、送信されるバイトに対するサーバーの意図を指定する MIME タイプが含まれています。これらには、 や などがtext/htmlありapplication/pdfます。サーバー側コード (ASP.Net) が呼び出されない場合、たとえば、画像や CSS などの静的ファイル、または PDF などの事前生成されたファイルでさえ、サーバー (IIS) はリスト内のファイル拡張子を調べて、何が何であるかを判断します。送信する MIME タイプ。クライアント側では、ブラウザーは MIME タイプを使用して、実行するアクションを決定します。そうであればtext/html、(おそらく) HTML をレンダリングします。そうであるapplication/pdf場合、ブラウザはそのMIME タイプのリストを表示して、その MIME タイプが登録されているアプリケーションがあるかどうかを確認します。最近のほとんどのブラウザーには PDF レンダラーが組み込まれているため、ブラウザーはバイトをそれに渡してレンダリングします。ブラウザーがその MIME を認識していない場合、OS に認識しているかどうか、登録済みのハンドラーが利用可能かどうかを確認し、存在する場合はそれを通過させます。それがすべて失敗した場合 (おそらく私のようなユーザーがその特定の MIME タイプを無効にしたため)、ブラウザーはそれらのバイトを「ダウンロード」フォルダーに入れるか、それらのバイトをテキストとして解釈しようとするか、保存するように求めます。

HTTP 仕様(19.5.1 パラグラフ 3) に従ってapplication/octet-stream、この最後のものをもう少し詳しく説明しContent-Disposition: attachment; filename="fname.ext"ます。

暗黙の提案は、ユーザー エージェントが応答を表示するのではなく、「応答を名前を付けて保存...」ダイアログに直接入る必要があるということです。

これがあなたが最終的に達成しようとしていることですよね？

あなたの場合、PDF リンクをクリックすると ASP.Net がバイパスされ、IIS はファイルを検索してapplication/pdfMIME タイプを送信します。解決策の 1 つは、 PDF ファイル拡張子をシステムから登録解除することです。ただし、これはおそらく最も移植性の高いソリューションではありません。同様に、ファイル拡張子を に変更するとapplication/octet-stream、[名前を付けて保存] ダイアログが表示される場合があります。

名前を付けて保存ダイアログを強制するための最良のオプションは、MIME タイプと Content Disposition ヘッダーを強制的にストリームに入れ、ファイルの未加工バイトを渡す何らかの種類のサーバー側のハンドラーを作成することです。これはいくつかの方法で行うことができます。おそらく、 (おそらくここでIHttpHandlerはさらに良いでしょう) を使用するか、クエリ文字列を検査する 1 つの ASPX ページだけを使用します。追加のセキュリティを実行し、ファイル名にパスのような文字やコマンドを許可しないようにする必要があります。

于 2015-07-21T14:48:54.817 に答える