14

たとえば、それは有効なajaxリクエストですか？

$.ajax({
    type: "POST",
    url: "SomePage.aspx/GetSomeObjects",
    contentType: "application/json; charset=utf-8",
    ...
});

例として使用されることもありますが、明示的な文字セットがないとソフトウェアが破損する可能性があります。

application /jsonメディアタイプのrfc4627は、セクション6のパラメーターを受け入れないと言っています。

The MIME media type for JSON text is application/json.

Type name: application

Subtype name: json

Required parameters: n/a

Optional parameters: n/a

charsetはapplication/jsonと一緒に使用すべきではないと解釈できます。

また、セクション3は、文字セットを指定する必要がないことを示しています。

JSON text SHALL be encoded in Unicode.  The default encoding is
UTF-8.

Since the first two characters of a JSON text will always be ASCII
characters [RFC0020], it is possible to determine whether an octet
stream is UTF-8, UTF-16 (BE or LE), or UTF-32 (BE or LE) by looking
at the pattern of nulls in the first four octets.

        00 00 00 xx  UTF-32BE
        00 xx 00 xx  UTF-16BE
        xx 00 00 00  UTF-32LE
        xx 00 xx 00  UTF-16LE
        xx xx xx xx  UTF-8

コンテンツからUTF-8,16,32エンコーディングを推測できるためです。なぜUTF-8がデフォルトであると言われるのですか？他の文字エンコーディングを選択する方法はrfcで指定されておらず、エンコーディングはとにかく決定論的に見つけることができます。または、Unicodeをサポートする他の（UTF-8,16,32ではない）文字エンコードはありますか？

文字セットを使用できると主張する人もいます：

私はそれを落とさなければならないというあなたの評価に同意しません。RFC 2046は、「「テキスト」のサブタイプ以外のメディアタイプは、ここで定義されている文字セットパラメータを使用することを選択する可能性がある」と述べています。これは、アプリケーションタイプでの文字セットパラメータの存在に制限がないことを示します。さらに、RFC 2045は、「MIME実装は、名前が認識されないパラメータを無視する必要がある」と述べています。したがって、その存在によって害が生じていると想定することは合理的ではありません。

rfc準拠のソフトウェアは、charsetパラメーターを使用してコンテンツタイプapplication / jsonを生成できますか？rfc準拠のソフトウェアはそのような要求を受け入れる必要がありますか？

4

3 に答える 3

8

application / jsonはcharsetパラメーターを定義していないため、これを含めるのは正しくありません。RFC 2046が言っていることは、アプリケーションタイプは一般にapplication/xmlなどの文字セットパラメータを持つことができるということです。しかし、JSONはそうではありません。

于 2012-10-27T09:00:22.670 に答える
7

最近のjsonrfc7159は次のように述べています：

注：この登録には「charset」パラメーターは定義されていません。
1つ追加しても、準拠している受信者には実際には影響しません。

つまり、charset準拠している受信者は無視する必要があります。

これは、rfc2045と一致しています。 「MIME実装は、名前が認識されないパラメータを無視する必要があります。」rfc 7159は、アプリケーション/ json mimeメディアタイプ（パラメーターなし）に対して「必須パラメーター：n / a;オプションパラメーター：n/a」を指定しているためです。

jsonテキストはオブジェクトまたは配列に制限されなくなり、最初の2文字に基づいて文字エンコードを計算する古いセクション3は新しいrfcになくなりました。UTF-8、UTF-16、またはUTF-32は許可されていますが、エンコーディングを指定する方法はありません（BOMなし、UTF-8がデフォルトです）。

charsetパラメータはhttp/1.1のapplication/jsonコンテンツタイプで使用できますか？

使用しても害はありませんcharset="utf-8"。utf-8はjsonテキストのデフォルトのエンコーディングですが、準拠している受信者は値を無視する必要があるため、他の値は誤解を招く可能性があります。Content-Typeヘッダーを誤って解析するクライアント、たとえば「application / json」と逐語的に比較するクライアント、またはutf-8エンコーディング以外を使用してjsonテキストをデコードしようとするクライアントのみを壊すことができます。

rfc準拠のソフトウェアは、charsetパラメーターを使用してコンテンツタイプapplication / jsonを生成できますか？

番号。application/jsonのパラメーターは定義されていません。

rfc準拠のソフトウェアはそのような要求を受け入れる必要がありますか？

はい、そうすべきです。の値はcharset無視する必要があります。

ECMA-404（JSONデータ交換形式）は、Unicodeコードポイントの観点からjsonテキストを定義します。つまり、json自体はエンコードの詳細に関する動作を指定しません。

ECMA-262（ECMAScript言語仕様）は、文字列（Unicodeタイプ）の上にjson形式も定義します。

于 2014-10-05T20:32:43.530 に答える
0

rfc準拠のソフトウェアはそのような要求を受け入れる必要がありますか？

ジュリアン・レシュケの答えによると、明らかにそうではありません。ただし、ご指摘のとおり、RFCに準拠していないホストと通信する場合は、実際に遭遇する可能性があり、それに対処する必要があります。

1つは、HTTPフレームワークのテキストベースのメッセージのコンテンツタイプの文字セット部分を処理するコードが配置されている場合、Accept-CharsetそれをJSONにも使用しないのはなぜですか？プログラミングに関しては、より簡単で（jsonに特別なルールはありません）、より一般的です。

個人的には、テキストのすべてのビットに対して（引用したエンコーディング検出を使用して）Unicodeを使用しましょう。残念ながら、Unicodeを処理しないが、のみを処理するクライアントデバイスがあります。たとえば、日本の携帯電話などです。そうでなければ、彼らは幸せなJSON消費者（そして有料の顧客）になるでしょう。で、どうするつもり？私の特定のケースでは、これらのクライアントを搭載するために、標準のHTTPメカニズムを介して文字セットを構成可能にしました。Shift_JIS

ちなみに、HTTP 2.0現在取り組んでおり、厳格に遵守された標準を作成したい場合は、受け入れテストを作成する必要があります。もちろん、ルールをときどき曲げることができない場合は、前述のレガシークライアントを除外することも意味します。

そして、あなた以外の誰もいない場合、準拠することのポイントは何ですか？Opera準拠しているのか、それとも、実装されているすべてのRFCを最初から明確に解釈できるのか、疑問に思います。私はそうは思いません、特にのような大きなものの場合はそうですHTTP。

これがHTTPバッシングのように聞こえる場合は、これを言いましょう。HTTPは、インターネットだけでなく革命を起こした概念を備えた優れた標準です。たとえば、リソースを指定する方法（ステートレス）、またはキャッシングを実行する方法は、多くのアプリケーションの実装に浸透している優れたパターンを確立しています。そして、HTTP 2は、1.1が中断したところから再開する可能性があります。SPDYが1対1で採用されないことを期待しましょう。言いたくないのですが、この場合、MicrosoftのHTTP Speed + Mobilityは、多くの点でGoogleのPUSHy（およびこれまでのところunRESTy）SPDYよりもHTTP -eyであるように見えます。

于 2012-10-29T00:40:27.273 に答える