15

ファイルをダウンロードする必要があるデバイスがあります。場合によっては、ファイルに間違っcontent-encodingた . 特に、gzip されていないか、何らかの方法で圧縮されていない場合は、「gzip」のコンテンツ エンコーディングが含まれる場合があります。

したがって、ファイルが gzip されている場合、基本的な ajax GET を使用してコンテンツを取得するのは簡単です。

$.ajax({
    url: 'http://' + IP + '/test.txt',
    type: 'GET'
})
.done(function(data) {
    alert(data);
});

しかし、ご想像のとおり、コンテンツのエンコードが間違っていると、これは失敗します。

ERR_CONTENT_DECODING_FAILED明確にするために、ブラウザーで指定された URL に移動するだけで、をバイパスするソリューションを探しているわけではありません。さらに解析するために、たとえばcsvをjavascriptの文字列にロードできるようにしたいと考えています。

ファイルを取得して、強制的にデコードの試行をスキップしたり、応答のコンテンツ エンコーディングをオーバーライドしたりできますか?

4

2 に答える 2

7

これは、WHATWG Fetch Standardからのフェッチ操作を利用するWHATWG のXHR 仕様に従って、クライアント側の JavaScript を介して行うことはできません。

クライアント側のスクリプトは、ブラウザー環境によって提供される応答オブジェクトのみを読み取ることができます。Fetch Standard は、ブラウザー環境がフェッチ操作のステップ 2 で応答オブジェクトのbody属性を構築する方法を定義します (特にサブステップ 2 から 4 に注意してください)。

  1. 1 つまたは複数のバイトが送信されるたびに、bytes を送信されたバイトとし、次のサブサブステップを実行します。

    1. 送信される応答の本文をバイトの長さで増やします。

    2. コーディングは、応答のヘッダー リストでの解析の結果とします。Content-Encoding

    3. コーディングとバイトを指定してコンテンツ コーディングを処理した結果をバイトに設定します。

    4. 応答の本文にバイトをプッシュします。

コンテンツ コーディングを処理するアクションは次のとおりです。

コーディングとバイトを指定してコンテンツ コーディングを処理するには、次のサブステップを実行します。

  1. コーディングがサポートされていない場合は、 bytesを返します。

  2. HTTPで説明されているように、指定されたコーディングでバイトをデコードした結果を返します。

この定義から、レスポンス オブジェクトはボディプロパティでエンコードされたバイトを公開しないことがわかります。バイトを本文に追加する前に、まずデコードする必要があります。クライアント スクリプトは、仕様で「送信されたバイト」と呼ばれるもの (つまり、ネットワーク上で送信された実際のエンコードされたバイト) にアクセスすることはできません。

デコードは、Content-Encodingヘッダーによってのみ決定されます。クライアント側の JavaScript が応答オブジェクトの応答ヘッダーを操作できるメカニズムはないためContent-Encoding、サーバーが最初に送信したものは何でもある必要があります。

サーバーが行っていることは間違っています。あなたの唯一のオプションは次のとおりです。

  1. サーバーの動作を修正します。

  2. Content-Encodingクライアントに到達する前に応答ヘッダーを修正するプロキシを介して HTTP 応答を実行します。

于 2015-04-21T20:34:29.387 に答える
2

最新のブラウザーベースの環境では、HttpRequest の Same-Origin ポリシーのおかげで、Accept-Encoding を変更することはできません。

Googleの説明へのリンク

脳死状態のデバイスの場合、最善の回避策は、サーバー側のプロキシを使用してコンテンツを取得し、正しくないエンコーディングを無視して、正常なヘッダー セットで結果を返すことです。

于 2015-04-21T19:45:33.500 に答える