ietf-charset

Edit New

charset (文字コード)

[55] charset は、文字コードを表す短い識別子 (によって表される文字コード) です。

仕様書

呼称

[56] charset は、「ちゃーせっと」、「きゃらせっと」などと発音されるようです。

定義

[846]

A charset is a method of mapping a sequence of octets to a sequence of abstract characters. A charset is, in effect, a combination of one or more CCSs with a CES. Charset names are registered by the IANA according to procedures documented in [RFC2278]. <NONE>

Many protocol definitions use the term "character set" in their descriptions. The terms "charset" or "character encoding scheme" are strongly preferred over the term "character set" because "character set" has other definitions in other contexts and this can be confusing.

RFC 3536 - Terminology Used in Internationalization in the IETF ( 版) http://tools.ietf.org/html/rfc3536#page-6

構文

[916] HTTP においては、 charset名は字句で、大文字・小文字不区別とされています >>846。

quoted-string

[116] MIME/HTTP で使われる媒体型の charset 引数の指定方法では、引数値は他の引数同様に value です。つまり、 token または quoted-string を1つ使って指定できます。

例:

(すべて等価)

[117] WinIE6 は引用符があるものに対応していないみたいです。

簡単な傍証:

  1. charset=iso-8859-1 の実体を表示
  2. 次のどちらか:

引用符をつけていると見事に化けます。

もちろんこのような杜撰な実装は規格不適合です。

文脈

[75] MIME では、 RFC 2231 で拡張された引数の値の構文で登録された IANA charset 名を使うことができるとされています。

[157] 他に次のプロトコル要素が「charset」を名乗っています。

ほわっといず charset?

char は文字 character の略として業界(どこ)では頻用される語句です。 set はその通りセットですが、数学の set と同じ(ような)意味で、 正統的(謎)には集合と訳します。

ですから、そのまま解釈すると文字集合ということになります。

しかし、この辺の用語の混乱は激しくて、大抵は単なる文字の集合 のことだけではなくて、その文字の集合に数字を割り振ったものとか、 その数字と計算機上の表現の対応の定義とか、そういう (文字を計算機で扱うのに必要な) 余計な色々までひっくるめて、 charset と呼びます。

MIME charset

MIME が定義する charset が、一番有名でしょう。

RFC 2045 〜 2049 には charset という語の定義は出てきませんが、 "charset" parameter は文字集合 character set を示すパラメーター らしいので、 character set = charset と考えて良いと思われます、

文字集合 Character Set (RFC 2045 2.2)

   The term "character set" is used in MIME to refer to a method of
   converting a sequence of octets into a sequence of characters.  Note
   that unconditional and unambiguous conversion in the other direction
   is not required, in that not all characters may be representable by a
   given character set and a character set may provide more than one
   sequence of octets to represent a particular sequence of characters.

用語「character set」 「文字集合」 は MIME ではオクテット列を 文字列に変換する方法を表します。なお、逆方向への無条件かつ曖昧でない 変換は必須ではありません。全ての文字が当該文字集合で表現可能でない かもしれませんし、その文字集合で特定の文字列を表現するのに 複数のオクテット列が使えても構いません。

   This definition is intended to allow various kinds of character
   encodings, from simple single-table mappings such as US-ASCII to
   complex table switching methods such as those that use ISO 2022's
   techniques, to be used as character sets.  However, the definition
   associated with a MIME character set name must fully specify the
   mapping to be performed.  In particular, use of external profiling
   information to determine the exact mapping is not permitted.

この定義は、 US-ASCII のように簡単な単一表対応付けから ISO 2022 技術を使うものまで、様々な種類の文字符号化を文字集合として 使うことを認めるものです。しかし、 MIME 文字集合名に関連付けられる定義は 使われる対応付けを完全に規定するものでなければなりません。 特に、正確な対応付けに外部プロファイル情報を使うのは認められません。

   NOTE: The term "character set" was originally to describe such
   straightforward schemes as US-ASCII and ISO-8859-1 which have a
   simple one-to-one mapping from single octets to single characters.
   Multi-octet coded character sets and switching techniques make the
   situation more complex. For example, some communities use the term
   "character encoding" for what MIME calls a "character set", while
   using the phrase "coded character set" to denote an abstract mapping
   from integers (not octets) to characters.

参考: 用語「character set」「文字集合」は元々は US-ASCII や ISO-8859-1 のように単一オクテットと単一文字の一対一の単純な対応付けを持つ 分かりやすい方式を指していました。多オクテット符号化文字集合や 切り替え技術のおかげで状況が複雑になりました。例えば、 用語「文字符号化 character encoding」を MIME で言うところの 「文字集合 character set」に使い、語句「符号化文字集合 coded character set」 で整数 (オクテットで無しに) から文字への抽象的な対応付けを示す 世間もあります。 (訳注: CES/CCS 論のことらしい。 Ned じーさんは、 CCS/CES 論は charset の1種ではあるが charset はそれに限定されない とおっしゃってます。)

[66] Re: Media types for RDF languages N3 and Turtle (Sean B. Palmer 著, 2007-12-17 15:51:29 +09:00 版) http://permalink.gmane.org/gmane.ietf.types/953

IANA charset

[103] IANA 文字符号化登録簿 (Character Sets registry) は、文字符号化 (charset) の名前に関する IANA による IETF の登録簿 (IANAREG) です。

[917] charset名は、 RFC 2978 により IANA に登録するべき (ought to) です >>846。

charset 値の一覧

[194] MIME charset / IANA charset

text/* の charset 引数

[885] MIME型 text/* の charset 引数については、 text/* を参照してください。

仕様書

意味

[127] text/plain の charset 引数は、文字集合 (character set) を指定するものです >>265。

[129] 他の text/* MIME型も、この charset 引数を使うと規定できます >>265。 その意味は、 text/plain の場合と同じとするべきです >>265。

[134] その他の MIME型も、この charset 引数を使うと規定できます >>265。テキスト情報が主に想定されていますが、 それ以外でも使うことができます >>265。

[135] 規定されていない MIME型では charset 引数を使うことはできません。

構文

[133] RFC 2046 で規定された値の他、 IANA登録簿にも値を登録できます >>265。

[58] IANA登録簿に登録される text/* MIME型の charset 引数は、値として RFC 2978 charset を指定するものでなければなりません >>57。

[143] インターネットメールでは、 RFC 2046 で規定された値、 IANA登録簿の値、 x- で始まる値しか使うことはできません >>265。

[130] text/plain 以外の text/* MIME型では、 値を制限することもできます >>265。

[128] 値は、大文字・小文字不区別です >>265。

[59] 実際の MIME型は必ずしもこの規定に従っていません。例えば text/html や text/css の charset 引数は IANA charset ではなく Encoding Standard の符号化ラベルとして解釈されます。

[131] MIME では、 text/* の改行の規則に従わない文字集合を使うことはできません >>265。

[132] UTF-16 や EBCDIC を使うことはできません。

[136] text/* 以外の MIME型で charset 引数が適用される場合は、 MIME でもそのような文字集合を使えます >>265。

文脈

[142] 文字コードが US-ASCII 以外なら、 常に明示的に指定しなければなりません >>265。

[60] charset 引数は、 charset 情報が payload 内部に含まれる場合は、指定するべきではありません >>57。

[61] 例えば text/xml >>57 で encoding 疑似属性を指定する時は、 charset 引数を指定するべきではありません。

[62] 両方を指定するべきではないというだけで、内部の指定を使うべきとは言っていないようです。

[152] multipart/form-data の本体部分の text/plain では、 使っても構いませんが、一般的な実装は使いません >>153。

既定値

[137] charset 引数は明示することが強く推奨されています >>265。

[63] charset 引数を規定する時は、必須の引数として規定するべきです。必須としない強い理由がある時は既定値を規定しても構いませんし、 既定値がないと規定しても構いません。既定値は UTF-8 とするべきです。 >>57

[64] 必須とするべきなのは既定値を指定する必要がないから >>57 とされています。 必須とするか否かに関わらず、既定値を定義しないと相互運用性はどうやって確保するのでしょうかね??

[65] いずれにせよ text/* を IANA登録簿に登録する際は charset の決定方法を明確に規定しなければなりません >>57。

[264] RFC 2046 (およびそれ以前の MIME RFC) によれば text/* の charset 引数の既定値は US-ASCII でした >>265。

[267] RFC 2616 (およびそれ以前の HTTP RFC) はこの既定値を (HTTP においては) ISO-8859-1 に変更しました >>266。

[268] RFC 6657 は、そのどちらも現状に合っていないとして、 RFC 2046 を更新して次のように規定しています >>262, >>57。

[275] charset 引数を必須にするのはプロトコルや実装によってはあまり現実的ではないと思いますが・・・。
[276] HTTP の規定を上書きするものではないみたいです。

[215] その後出版された RFC 7231 は >>267 の既定値を削除しています >>214。

[154] multipart/form-data の本体部分の text/plain では、フォームの提出の文字コードを使って構わない >>151 ことになっている一方、 charset 引数は強制されていません >>153。

処理

[145] 一般に MIME の生成ソフトウェアは、可能な限り「最小公倍数」 たる文字集合を使うべきです >>265。

[146] 例えば ISO-8859-X の左半分しか使わないなら、 US-ASCII を使うべきです >>265。

[147] しかし現在となってはむしろ常に UTF-8 を使う方が相互運用性は高いかもしれません。

[102] MIME では未知の text/* MIME型は text/plain として扱うことになっています。 charset 引数がこの際どう扱われるかは不明です。

歴史

XML の charset 引数

[101] XML MIME型でも charset 引数があります。 詳細は規定されていませんが (ひどい)、MIME charset を指定するもので、 XML encoding 疑似属性より優先されるものと解されています。

[923] 詳しくはXMLにおける文字コードを参照してください。

文字集合

charset は省略形のように見えます。元々はそうなのでしょうが、 今となっては charset は charset であって charset でしかない、 と考えるのが適当かもしれません。訳にあたっても、 訳して原文のニュアンスが失われるとアレなので (ニュアンスなんて そもそも残らないかもしれませんけど。) そのまま charset とするのが良いのではないでしょうか。

正規形のように見える character set は、文字集合と訳すのが 定着してます。こちらの語は、 (やはり charset と同様の混乱はあるものの) より本来の意味 (文字の集合) で使われていると思われます。

[180] HTTP::Message - search.cpan.org () http://search.cpan.org/~oalders/HTTP-Message-6.13/lib/HTTP/Message.pm は charset の値 none を無変換として解釈します。

CGI における charset 引数

CGI 要求における既定値

[861] CGI のメタ変数 CONTENT_TYPE においては、 既定値が次の優先度で定義されています。

  1. MIME型依存でシステム定義の既定値を定めても構いません。
  2. text/* については RFC 2616 に従い ISO-8859-1 です。
  3. MIME型で既定値が定義されていれば、それです。
  4. US-ASCII です。

[863] HTTP との実質的な違いは第1位のシステム定義の既定値が認められていることです。 CGI はシステムの慣習によって鯖からCGIスクリプトに値を引き渡す前に諸々の変換を施すことが認められているので、 charset についても同様の取り扱いを行えるように、との配慮なのでしょうか。

CGI 応答における既定値

[864] 特にシステム定義がなければ、クライアントによって text/* の既定の charset が HTTP なら ISO-8859-1、そうでなければ US-ASCII とみなされます。そのためCGIスクリプトは charset 引数を含めるべきです。 >>865

[866] 明記されていませんが、システム定義があれば実装は charset の変換を適宜行うことになるでしょうし、 charset が指定されていなかったり不適切だったりすると適宜書き換えるものと思われます。

EBCDIC/POSIX

[868] EBCDIC を使う POSIX 環境では、既定の charset は IBM1047 です。これは text/* とその他実装定義の MIME型に適用されます。 >>867

meta 要素 charset 属性 (HTML)

[89] meta 要素の charset 属性は、文書の文字符号化を指定する文字符号化宣言です >>88。

属性値

[90] 属性値は、 UTF-8 にASCII大文字・小文字不区別で一致する値でなければなりません >>88。

[183] かつてはこの規定はXML文書にのみ適用されていました。 XML文書では <meta charset> は意味を持たず、 HTML と XML との相互変換の便宜のためのみを目的に認められていました >>88。

[91] の改訂でHTML文書は UTF-8 でなければならないと改められたため、本規定は HTML文書にも適用されることとなりました。

文脈

[92] <meta charset> 要素は、メタデータ内容として使えます。

[93] <meta charset> 要素は、文書中に複数あってはなりません >>88。

[184] 歴史的には HTTPヘッダー Content-Type: の charset 引数に文字コードを指定するのが正統と考えられていたことから、現在に至るまで charset 引数が指定される場合には、 <meta charset> を指定する必要はないとされています。

@charset 規則 (CSS)

[54] CSS の@規則 @charset は、当該 CSSスタイルシートの文字コードを表します。

[53] @charset を参照。

異体説明における charset 属性

[78] 異体説明では charset 異体属性は Content-Type: ヘッダーの charset 引数に相当します >>77。

[79] type 異体属性から charset 引数は除外します。

構文

[80] 属性値は、 charset です >>77。

[81] RFC 2068 の定義が参照されています。

charset (SDP)

CAP における charset

[210] <greeting localize> も参照。

範囲

[918] HTTP の Accept-Charset: ヘッダーや HTML の accept-charset 属性では、 charset のリストを指定することができます。更に HTTP のヘッダーでは、 優先順位を指定したり、その他を表す「*」を指定したりできます。

charset の一覧

[138] MIME は、インターネットメールで使う単一の文字集合があるのが好ましいながら、 近い将来のうちに統一は望めないとして、少数だけ標準の文字集合を定義する >>265 としていました。

[139] MIME が開発された90年代には、 Unicode への統一は困難とも思われていました。

[140] MIME は次のものを規定しています >>265。

[141] これは比較的論争とならなかったもののみであり、 US-ASCII 以外の特定の文字集合を推奨するものではない >>265 とされています。 MIME の時代、文字コードの選択は宗教的な問題を含む大きな関心事でした。

[144] 実装者は、どうしても必要な場合を除き、新しい文字集合を定義するべきではありません (discouraged) >>265。

[150] 次のような値がありました。

[212] Character Set Recognition, InetSDK, , https://web.archive.org/web/20001202085600/http://msdn.microsoft.com/workshop/Author/dhtml/reference/charsets/charset4.asp

charset 引数が使われている MIME 型とその定義のバリエーション

MIME の charset 引数と互換な定義

[14]

MIME の charset 引数の部分集合な定義

[838]

Turtle

[874] R2RML である Turtle について: charset 引数を使うべきです >>873。

[904] >>903 によれば値は UTF-8 のみ。非ASCII文字を含むなら必須。

RFC 3023 の charset と同じ定義

[840]

RFC 3023 application/xml と同じ定義

[839]

RFC 7303 application/xml の charset 引数と同じ定義

RFC 3023 application/xml の charset 引数の部分集合な定義

[27]

RFC 3023 の text/xml の charset と同じ定義

[40]

RFC 3023 を参照した定義

TTML

[172] application/ttml+xml には charset 引数があります。省略可能です >>170。

[171] XML の符号化宣言と同じ、または符号化宣言が無い場合には実際の符号化 >>170 とされています。符号化宣言と同じなら実際の符号化と異なっていても良いのか、 と思ってしまいますが、 TTML の符号化は UTF-8 と UTF-16 に制限されているようですから、そちらに違反してしまいます。なお、「実際の符号化」 は、どう指定するのか明記されていません。自明だと思ったのかもしれませんが、 大文字と小文字が区別されるのかどうか、 UTF-16BE のような指定も認められるのか、など不明です。

[173] TTML の処理で本引数をどのように用いるべきなのかは規定がありません。 符号化に関して RFC 3023 も参照されているので、エスパーするなら、 XML MIME型と同じ方法と推測するべきでしょうか。 UTF-8 と UTF-16 に限定されている上 XML の符号化宣言があるので、 本質的には本引数は不要です。

OWL

SQL

UTF-8 のみ指定できるもの

[162]

charset を定義しないと明記しているもの

[906] application/json (>>305) では charset 引数がしばしば用いられていますが、 RFC 7159 は charset 引数がないと明記しています。

[100] 現実については application/json を参照。

歴史

RFC 1345

[124] 後の IANA charset の元となったものを定義していたのが RFC 1345 でした。

  • 2002-09-23 (Mon) 11:42:47 名無しさん : RFC 1345 の charset 表の前半の ISO-IR 典拠のは、かなりが嘘 charset。
  • 2002-09-23 (Mon) 11:43:22 名無しさん : 補助文字集合があたかも単独で使われるような書き方がしてある。
  • 2002-09-23 (Mon) 11:44:21 名無しさん : 十数個の charset はこのかた一度もつかわれてないに違いない。
  • 2002-09-23 (Mon) 11:46:07 名無しさん : 作った当時の ietf-822ext の記事読んでみたけど、まあ仕方無かったのかなぁ。
  • 2002-09-23 (Mon) 11:46:45 名無しさん : あと、表の g0esc みたいな項目は、単なる参考情報で charset 自体には関係ない。
  • 2002-09-23 (Mon) 11:47:20 名無しさん : 1345 charsets はすべて平面上の文字集合。
  • 2002-09-23 (Mon) 11:48:42 名無しさん : 4つの多バイト文字集合は制御文字が定義されてない。 (説明もそう言ってる。でもって表には G0 で示してある、と。)
  • 2002-09-23 (Mon) 11:50:06 名無しさん : そのままでは使い物にならないことを半ば承知の上で定義したんじゃないかと思う。 ietf-822ext の過去の記事を読んだ上でそう思った。

MIME

[105] RFC 2046

A critical parameter that may be specified in the Content-Type field for "text/plain" data is the character set. This is specified with a "charset" parameter, as in:

"text/plain" データの Content-Type 領域に指定しても良いパラメーターは 文字集合です、これは "charset" パラメーターで次のように指定します。

     Content-type: text/plain; charset=iso-8859-1

Unlike some other parameter values, the values of the charset parameter are NOT case sensitive. The default character set, which must be assumed in the absence of a charset parameter, is US-ASCII.

他の幾つかのパラメーター値とは違って、 charset パラメーターの値は 大文字・小文字を区別しません。 charset パラメーターが無い場合に 仮定しなければならない既定の文字集合は、 US-ASCII です。

   The specification for any future subtypes of "text" must specify
   whether or not they will also utilize a "charset" parameter, and may
   possibly restrict its values as well.  For other subtypes of "text"
   than "text/plain", the semantics of the "charset" parameter should be
   defined to be identical to those specified here for "text/plain",
   i.e., the body consists entirely of characters in the given charset.
   In particular, definers of future "text" subtypes should pay close
   attention to the implications of multioctet character sets for their
   subtype definitions.

将来の "text" の亜型の仕様は "charset" パラメーターを利用するかどうか 規定しなければなりません。また、その値を制限しても構いません。 "text/plain" 以外の "text" 亜型には、 "charset" パラメーターの意味は ここで "text/plain" 用に既定するのと同じ様に定義するべきです。 つまり、本文は完全に与えた charset で構成されます。特に、 将来の "text" 亜型の定義者は多オクテット文字集合とその亜型定義 との関係についてしっかり注意するべきです。

   The charset parameter for subtypes of "text" gives a name of a
   character set, as "character set" is defined in RFC 2045.  The rules
   regarding line breaks detailed in the previous section must also be
   observed -- a character set whose definition does not conform to
   these rules cannot be used in a MIME "text" subtype.

"text" 亜型の charset パラメーターは文字集合の名前を与えます。 ここで「文字集合 character set」は RFC 2045 で定義したものです。 前の節で詳しく述べた改行に関する規則にも注意して下さい。 この規則に適合しない文字集合は MIME "text" 亜型で使うことは出来ません。

An initial list of predefined character set names can be found at the end of this section. Additional character sets may be registered with IANA.

予め定義した文字集合名はこの節の終わりにあります。追加の文字集合を IANA で登録しても構いません。

Other media types than subtypes of "text" might choose to employ the charset parameter as defined here, but with the CRLF/line break restriction removed. Therefore, all character sets that conform to the general definition of "character set" in RFC 2045 can be registered for MIME use.

"text" の亜型以外の媒体型もここで定義した charset パラメーターを使う ことにしても構いませんが、 CRLF/改行制限は削除されます。 ですから、 RFC 2045 の「文字集合 character set」の定義に適合する 全ての文字集合を MIME で使用するのに登録出来ます。

   Note that if the specified character set includes 8-bit characters
   and such characters are used in the body, a Content-Transfer-Encoding
   header field and a corresponding encoding on the data are required in
   order to transmit the body via some mail transfer protocols, such as
   SMTP [RFC-821].

なお、指定文字集合が8ビット文字を含んでいてそのような文字が本文で 使われている場合、 Content-Transfer-Encoding 頭領域と対応するデータの符号化 が本文を SMTP のような幾つかのメイル転送プロトコルで転送するために 施す必要があります。

   The default character set, US-ASCII, has been the subject of some
   confusion and ambiguity in the past.  Not only were there some
   ambiguities in the definition, there have been wide variations in
   practice.  In order to eliminate such ambiguity and variations in the
   future, it is strongly recommended that new user agents explicitly
   specify a character set as a media type parameter in the Content-Type
   header field. "US-ASCII" does not indicate an arbitrary 7-bit
   character set, but specifies that all octets in the body must be
   interpreted as characters according to the US-ASCII character set.
   National and application-oriented versions of ISO 646 [ISO-646] are
   usually NOT identical to US-ASCII, and in that case their use in
   Internet mail is explicitly discouraged.  The omission of the ISO 646
   character set from this document is deliberate in this regard.  The
   character set name of "US-ASCII" explicitly refers to the character
   set defined in ANSI X3.4-1986 [US- ASCII].  The new international
   reference version (IRV) of the 1991 edition of ISO 646 is identical
   to US-ASCII.  The character set name "ASCII" is reserved and must not
   be used for any purpose.

既定の文字集合 US-ASCII は過去より混乱と曖昧がありました。定義に曖昧性がある だけではなく、慣習上多様な変種があります。将来このような曖昧性と変種を 取り除くため、新しい利用者代理者は明示的に文字集合を Content-Type 頭領域の媒体型パラメーターとして指定することを強く推奨します。 "US-ASCII" は任意の7ビット文字集合を示すのではなく、本文の 全てのオクテットを US-ASCII 文字集合によって文字として解釈しなければならない と指定します。国家・応用指向の ISO 646 の版は一般に US-ASCII と同一ではなく、この場合 Internet メイルでの利用は明白に非推奨です。 ISO 646 文字集合をこの文書から省いたのは、このためわざとそうしたのです。 "US-ASCII" の名前の文字集合は明白に、 ANSI X3.4-1986 で定義された文字集合を 参照します。 ISO 646 の 1991 年版の新しい国際基準版 (IRV) は US-ASCII と同一です。文字集合名 "ASCII" は保留され、どんな目的にも使ってはいけません。

   NOTE: RFC 821 explicitly specifies "ASCII", and references an earlier
   version of the American Standard.  Insofar as one of the purposes of
   specifying a media type and character set is to permit the receiver
   to unambiguously determine how the sender intended the coded message
   to be interpreted, assuming anything other than "strict ASCII" as the
   default would risk unintentional and incompatible changes to the
   semantics of messages now being transmitted.  This also implies that
   messages containing characters coded according to other versions of
   ISO 646 than US-ASCII and the 1991 IRV, or using code-switching
   procedures (e.g., those of ISO 2022), as well as 8bit or multiple
   octet character encodings MUST use an appropriate character set
   specification to be consistent with MIME.
   The complete US-ASCII character set is listed in ANSI X3.4- 1986.
   Note that the control characters including DEL (0-31, 127) have no
   defined meaning in apart from the combination CRLF (US-ASCII values
   13 and 10) indicating a new line.  Two of the characters have de
   facto meanings in wide use: FF (12) often means "start subsequent
   text on the beginning of a new page"; and TAB or HT (9) often (though
   not always) means "move the cursor to the next available column after
   the current position where the column number is a multiple of 8
   (counting the first column as column 0)."  Aside from these
   conventions, any use of the control characters or DEL in a body must
   either occur
    (1)   because a subtype of text other than "plain"
          specifically assigns some additional meaning, or
    (2)   within the context of a private agreement between the
          sender and recipient. Such private agreements are
          discouraged and should be replaced by the other
          capabilities of this document.
   NOTE: An enormous proliferation of character sets exist beyond US-
   ASCII.  A large number of partially or totally overlapping character
   sets is NOT a good thing.  A SINGLE character set that can be used
   universally for representing all of the world's languages in Internet
   mail would be preferrable.  Unfortunately, existing practice in
   several communities seems to point to the continued use of multiple
   character sets in the near future.  A small number of standard
   character sets are, therefore, defined for Internet use in this
   document.

The defined charset values are:

定義されている charset 値は次の通りです。

    (1)   US-ASCII -- as defined in ANSI X3.4-1986 [US-ASCII].

(1) US-ASCII ANSI X3.4-1986 で定義されたもの。

    (2)   ISO-8859-X -- where "X" is to be replaced, as
          necessary, for the parts of ISO-8859 [ISO-8859].  Note
          that the ISO 646 character sets have deliberately been
          omitted in favor of their 8859 replacements, which are
          the designated character sets for Internet mail.  As of
          the publication of this document, the legitimate values
          for "X" are the digits 1 through 10.

(2) ISO-8859-X ここで "X" は ISO-8859 の部分で置き換えたもの。 なお、 ISO 646 の文字集合達は代わりの Internet メイルの指示文字集合 である 8859 があるので故意に省いています。この文書の出版の時点では、 "X" の適当な値は数字 1 から 10 です。

Characters in the range 128-159 has no assigned meaning in ISO-8859-X. Characters with values below 128 in ISO-8859-X have the same assigned meaning as they do in US-ASCII.

範囲 128〜159 の文字は ISO-8859-X で割り当てられた意味はありません。 ISO-8859-X で128以下の値は US-ASCII で割り当てられたのと同じ意味を持ちます。

   Part 6 of ISO 8859 (Latin/Arabic alphabet) and part 8 (Latin/Hebrew
   alphabet) includes both characters for which the normal writing
   direction is right to left and characters for which it is left to
   right, but do not define a canonical ordering method for representing
   bi-directional text.  The charset values "ISO-8859-6" and "ISO-8859-
   8", however, specify that the visual method is used [RFC-1556].
   All of these character sets are used as pure 7bit or 8bit sets
   without any shift or escape functions.  The meaning of shift and
   escape sequences in these character sets is not defined.
   The character sets specified above are the ones that were relatively
   uncontroversial during the drafting of MIME.  This document does not
   endorse the use of any particular character set other than US-ASCII,
   and recognizes that the future evolution of world character sets
   remains unclear.

Note that the character set used, if anything other than US- ASCII, must always be explicitly specified in the Content-Type field.

なお、 US-ASCII 以外の文字集合が使われている時は、必ず Content-Type 領域に明示しなければなりません。

   No character set name other than those defined above may be used in
   Internet mail without the publication of a formal specification and
   its registration with IANA, or by private agreement, in which case
   the character set name must begin with "X-".

Implementors are discouraged from defining new character sets unless absolutely necessary.

実装者が新しい文字集合を定義するのは完全に必要でない限り非推奨です。

   The "charset" parameter has been defined primarily for the purpose of
   textual data, and is described in this section for that reason.
   However, it is conceivable that non-textual data might also wish to
   specify a charset value for some purpose, in which case the same
   syntax and values should be used.
   In general, composition software should always use the "lowest common
   denominator" character set possible.  For example, if a body contains
   only US-ASCII characters, it SHOULD be marked as being in the US-
   ASCII character set, not ISO-8859-1, which, like all the ISO-8859
   family of character sets, is a superset of US-ASCII.  More generally,
   if a widely-used character set is a subset of another character set,
   and a body contains only characters in the widely-used subset, it
   should be labelled as being in that subset.  This will increase the
   chances that the recipient will be able to view the resulting entity
   correctly.

[125] charset に関する議論は ietf-charset メーリングリストで行われています。

[126] 実在する charset であってもこのメーリングリストの議論で登録を断念したものがいくつもあるようです。

RFC 1922

[106] RFC 1922 は charset 引数と併用するものとして charset-edition 引数と charset-extension 引数を定義していました。

[107] RFC 1922 4. Two New MIME parameters

Here we define two new MIME parameters to be used with "charset" parameters.

ここに、 "charset" パラメーターと共に使う、 2つの新しい MIME パラメーターを定義します。

4.1. "charset-edition"

   This parameter is used after the MIME "charset" parameter, using four
   digits (AD) to indicate what the year of edition is for the character
   set standard shown in "charset".  Its use is optional.
   Implementations should ignore this parameter unless the
   implementation has specific support for that particular character set
   edition.
   The reason for defining this parameter is that there are often
   differences in the defined characters between editions of a character
   set standard.  Sometimes, the difference can not be ignored,
   otherwise implementations would have problems when processing it.
   There are only two ways to indicate this difference, in the current
   MIME syntax.  One way is to indicate the edition in the charset name,
   such as CN-GB-1988-80 (the 1980's edition of GB 1988).  The other way
   is to define a new optional parameter such as "charset-edition".  The
   latter way is better because receiving applications that can only
   process an older edition can still recognize the character set and
   offer to display the text in the older edition.  This display may
   have a few mistakes, but it is better than refusing to display any
   text at all or defaulting to an inappropriate character set such as
   US-ASCII or ISO-8859-1.

4.2. "charset-extension"

   This parameter is also used after the MIME "charset" parameter.  It
   is case-insensitive and optional, and any value of this parameter
   should be registered in IANA.  Unregistered value should start with
   "x-" as with any MIME extension-token.  Implementations should ignore
   this parameter unless the implementation has specific support for
   that particular character set extension.
   A character set extension has displayed glyphs for code points that
   are not assigned in the character set, for example, vendor-specific
   extensions of standard character sets.  This parameter provides the
   option of using these extensions.  Although character set extensions
   may cause interoperability problems, we recognize the existence of
   such extensions.
   For example:
      Content-Type: text/plain; charset=CN-Big5; charset-edition=1984;
       charset-extension=ETen-2.00.03-DOS
   This may indicate Eten company's extension of Big5: ETen 2.00.03 for
   DOS, assuming that "ETen-2.00.03-DOS" is registered with the IANA..

4.3. Formal Syntax:

The following changes and additions are made to the MIME syntax:

MIME 構文に対して、次の通り変更・追加します。

   charset-edition   := "charset-edition" "=" 4DIGIT
                         ; year of edition in four digits
   charset-extension := "charset-extension" "=" extension-token

[192] charset-edition の値は4桁西暦年と定義されていました。

[193] CN-GB (GB 2312、中華人民共和国向け) や CN-Big5 (Big5、中華民国台湾向け) との併用が想定されていました。 中華人民共和国の紀年法は公元ですが、 中華民国の紀年法は中華民国です。 しかしその違いは配慮されず、西暦年のみが許されていました。

[108] charset-edition の定義は 4DIGIT ですが、10000年問題 を考慮して、4*DIGIT とするのがよさげ。2000年問題対策 と称して 2DIGIT に1900足したりする必要はないと思います。 そういうのを受け取っても、 西暦1世紀に制定された charset だということにしてはどーですか?

[109] charset-extension の登録簿は IANA には無いみたい。

古い Netscape Navigator の charset パラメーター認識問題

[110] 古い NetscapeNavigator (2 以前?) には、 charset パラメーターを特定の値 (hard coding で実装されている名前) 以外の場合、手動で符号化方法を指定することさえ出来なくなり、結果 (多くの場合) 文字化けするという問題があります。

[111] 特に日本語系文字コードでは、 x-euc-jp 及び x-sjis という私用名にしか対応しておらず、 NN2 より後に登録された IANA 名 euc-jp 及び shift_jis や windows-31j が指定されていると文字化けします。

[113] なお、 iso-2022-jp については問題は起こりません。

[112] なお、この指定は HTTP 頭内の Content-Type:欄に指定しても無視されるようで、 HTML の meta要素で http-equiv属性を使って指定する必要があります。

[114] この指定とは関係なしに文書の一部が文字化けする現象がありますが、原因はよくわかりません。

[115] >>110-114 問題を Netscape Navigator 2.01 で確認しますた。 (っていうかこんな古い版はやく捨てましょう。)

IANA charset 登録簿

[195] RFC 2278 - IANA Charset Registration Procedures, , https://tools.ietf.org/html/rfc2278

[196] RFC 2978 - IANA Charset Registration Procedures, , https://tools.ietf.org/html/rfc2978

[197] RFC Errata Report » RFC Editor, https://www.rfc-editor.org/errata_search.php?rfc=2978

メモ

[118] RFC3023 は、 XML 系の媒体型のための charset 引数を規定しています。

[119] >>118 text/xml などは、省略時の既定値が MIME でも HTTP でも us-ascii です。また、 application/xml などは、省略時には既定値なしで、 xml宣言などを参照します。

[120] >>118-119 他の +xml 系媒体型がよく定義にこの RFC を参照していますから、影響力は大きいです。

[122] Bug 1697 - multipart/form-data 送出時に Content-Type が送られない http://bugzilla.mozilla.gr.jp/show_bug.cgi?id=1697, Bug 116346 - Content-Type should be supplied for form data of 'enctype="multipart/form-data"'[from sub] http://bugzilla.mozilla.org/show_bug.cgi?id=116346 : multipart/form-data を送るときに Mozilla が charset 引数をつけなかったという問題。だけどこれは特定の媒体型や特定の実装に固有じゃない、実は大きな問題をはらんでいます。「ファイル添付」のような、 MIME 実体を生成する応用を単に通過するだけのデータのメタ情報をどうやって得るのかとか、多文字化された実装で charset 情報とどう向き合うのかとか。 MIME は10年も前の規格で、こんなことなんて考えてもいなかったわけですけど、この先どうなるでしょう。やっぱりこれまで通り騙し騙し無理しながら現状維持し続けるしか方法はないのかな。

[121] charset=136 ってのみかけたけど、中身は Big5 だった。どうしてこんな値になったんだ?

[123] >>121 はちなみに spam。

[25] Charset parameter of +xml media types from Bjoern Hoehrmann on 2006-09-05 (www-archive@w3.org from September 2006) http://lists.w3.org/Archives/Public/www-archive/2006Sep/0003 (名無しさん 2006-09-07 23:19:07 +00:00)

[30] I'm not a Klingon : Expected names of Microsoft Windows "ANSI" Code Pages (Encodings) http://blogs.msdn.com/shawnste/archive/2006/11/06/expected-names-of-microsoft-windows-ansi-code-pages-encodings.aspx (名無しさん [sage])

[34] Re: Unicode distribution? from Erik van der Poel on 2007-01-05 (www-international@w3.org from January to March 2007) (Erik van der Poel (erikv@google.com) 著, 2007-01-07 23:27:03 +09:00 版) http://lists.w3.org/Archives/Public/www-international/2007JanMar/0004 (名無しさん 2007-01-12 21:09:39 +00:00)

[43] ハーブティー、アロマオイル、アロマランプを種類豊富に販売ユーン 卸販売 (2007-06-11 01:15:22 +09:00 版) http://www.yuwn.com/

この鯖は全部設定がおかしいみたい。 charset=0 になってる。 (名無しさん 2007-06-10 16:18:27 +00:00)

[48] openssl-engine-0.9.6a/test/CAss.cnf - Google Code Search (2007-09-19 10:28:09 +09:00 版) http://www.google.com/codesearch?hl=en&q=show:gp2a770O6xs:Oe1g97XTGPk:6T5s7D-EE9I&sa=N&ct=rd&cs_p=http://www.openssl.org/source/openssl-engine-0.9.6a.tar.gz&cs_f=openssl-engine-0.9.6a/test/CAss.cnf&start=1

Content-Type: text/html; charset=UTF-8; charset=UTF-8

(名無しさん)

[49] >>48 User-Agent: か何かによっては後者が ISO-8859-1 になることもある模様。

(名無しさん 2007-09-19 01:33:01 +00:00)

[38] TMX Specification (2007-02-24 17:51:20 +09:00 版) http://www.lisa.org/standards/tmx/tmx.html#base (名無しさん [sage])

[39] TMX Specification (2007-02-24 17:51:20 +09:00 版) http://www.lisa.org/standards/tmx/tmx.html#oencoding (名無しさん [sage])

[42] Kazuho@Cybozu Labs: Re: PoCo::Client::HTTP が勝手に文字コードを変えてしまう件 (2007-04-24 06:52:47 +09:00 版) http://labs.cybozu.co.jp/blog/kazuho/archives/2007/04/poco_patch.php

charset=iso-8859-1 default Breaks the Web. (名無しさん 2007-04-23 21:54:55 +00:00)

[47] hoshikuzu | star_dust の書斎 (2007-08-10 22:40:44 +09:00 版) http://d.hatena.ne.jp/hoshikuzu/20070807#p1 (名無しさん)

[51] feel部屋:皆様に幸と笑いあれ♪ - 轟轟戦隊 (2007-09-24 14:10:56 +09:00 版) http://feel.g.hatena.ne.jp/keyword/%e8%bd%9f%e8%bd%9f%e6%88%a6%e9%9a%8a

<link rel="stylesheet" href="/diary_css/base.css" type="text/css" media="all" charset="euc-jp">
<link rel="stylesheet" href="/theme/hazakura/hazakura.css" type="text/css" media="all" charset="euc-jp">

リンク先の CSS スタイル・シートは、 @charset の指定はあるものの HTTP Content-Type: charset は指定なし。 (名無しさん)

[52] メモ - 葉っぱ日記 (2007-11-28 12:10:50 +09:00 版) http://d.hatena.ne.jp/hasegawayosuke/20071120/p1

[68] Re: Unsupported transport-layer encodings (Alexey Proskuryakov 著, 2008-07-22 20:55:40 +09:00 版) http://lists.w3.org/Archives/Public/public-html/2008Jul/0279.html (名無しさん)

[69] Charset usage data (Philip Taylor 著, 2008-03-06 02:52:53 +09:00 版) http://lists.w3.org/Archives/Public/public-html/2008Mar/0029.html (名無しさん)

[71] HTML5のFPWDとmeta要素のcharset属性 - vantguarde - web:g ( 版) http://web.g.hatena.ne.jp/vantguarde/20080123/1201089589

[74] TAG Finding: Internet Media Type registration, consistency of use ( 版) http://www.w3.org/2001/tag/2002/0129-mime#char-encoding

[825] MAMA: Document Encodings - Opera Developer Community ( 版) http://dev.opera.com/articles/view/mama-document-encodings/

[826] Firefox 3 は script charset が指定されていないとスクリプトの Content-Type charset に従いますが (たぶん ― 自動判別かどうかは未調査)、 WinIE 7 はそうじゃないみたいです (たぶん HTML charcterSet と同じとみなす)。

[828] The WHATWG Blog » Blog Archive » The Road to HTML 5: character encoding ( 版) http://blog.whatwg.org/the-road-to-html-5-character-encoding

[829] (X)HTML5 Tracking ( 版) http://html5.org/tools/web-apps-tracker?from=4125&to=4126

[832] RFC 5537 - Netnews Architecture and Protocols ( 版) http://tools.ietf.org/html/rfc5537

[833] 世界史講義録 ( 版) http://www.geocities.jp/timeway/

This page is encoded in euc-jp, but its Content-Type is text/html (with no charset parameter). The page includes ...

<meta name="META HTTP-EQUIV="
content="text/html;CHRSET=iso-2022-jp">
... but it is broken in various ways, sigh.

Firefox correctly decodes the page as euc-jp, while Chrome fails to decode the page, by recognizing the content as shift_jis.

[834] HTML5 Revision Tracker ( 版) http://html5.org/tools/web-apps-tracker?from=5041&to=5042

[835] XProc: An XML Pipeline Language ( 版) http://www.w3.org/TR/2010/REC-xproc-20100511/#p.data

[836] XProc: An XML Pipeline Language ( 版) http://www.w3.org/TR/2010/REC-xproc-20100511/#c.response_body

[842] [CITE@@en[Web Applications 1.0 r5295 <meta charset> should only work for ASCII-compatible encodings.Fixing http://www.w3.org/Bugs/Public/show_bug.cgi?id=10260]] ( ( 版)) http://html5.org/tools/web-apps-tracker?from=5294&to=5295

[843] [CITE@@en[Web Applications 1.0 r5414 Allow authors to override WebSRT's encoding using <track charset>.]] ( ( 版)) http://html5.org/tools/web-apps-tracker?from=5413&to=5414

[844] IRC logs: freenode / #whatwg / 20101126 ( ( 版)) http://krijnhoetmer.nl/irc-logs/whatwg/20101126#l-354

[848] RFC 6047 - iCalendar Message-Based Interoperability Protocol (iMIP) ( ( 版)) http://tools.ietf.org/html/rfc6047#section-2.4

[849] draft-melnikov-mime-default-charset-00 - Update to MIME regarding Charset Parameter Handling in Textual Media Types ( 版) http://tools.ietf.org/html/draft-melnikov-mime-default-charset-00

[855] Web Applications 1.0 r6641 Mention that application/x-www-form-urlencoded;charset does nothing. ( ( 版)) http://html5.org/tools/web-apps-tracker?from=6640&to=6641

[856] RFC 6365 - Terminology Used in Internationalization in the IETF ( 版) http://tools.ietf.org/html/rfc6365#page-8

[857]

However, it is important to point out that the MIME concept of 'charset' in some cases cuts across several layers of components in our model. While this can be accepted in existing registrations, we also recommend that the MIME registration procedure for character sets be modified to show how a proposed character set deals with the CCS and the CES. Most 'charsets' have a well defined CCS and CES, they should merely be teased apart for the registration.

RFC 2130 - The Report of the IAB Character Set Workshop held 29 February - 1 March, 1996 ( 版) http://tools.ietf.org/html/rfc2130#page-10

[859] RFC 2277 - IETF Policy on Character Sets and Languages ( ( 版)) http://tools.ietf.org/html/rfc2277#section-3

[860] IRC logs: freenode / #whatwg / 20111218 ( ( 版)) http://krijnhoetmer.nl/irc-logs/whatwg/20111218

[869] Web Applications 1.0 r7160 Require an encoding declaration. ( ( 版)) http://html5.org/tools/web-apps-tracker?from=7159&to=7160

[870] [whatwg] Encoding sniffing algorithm ( ( 版)) http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-September/037190.html

[871] Web Applications 1.0 r7324 Attempt to slightly more closely align with reality. ( ( 版)) http://html5.org/tools/web-apps-tracker?from=7323&to=7324

[872] Web Applications 1.0 r7360 Make a BOM override HTTP headers. ( ( 版)) http://html5.org/tools/web-apps-tracker?from=7359&to=7360

[890] Web Applications 1.0 r7958 New encoding defaults based on more data. ( ( 版)) http://html5.org/tools/web-apps-tracker?from=7957&to=7958

[893] IRC logs: freenode / #whatwg / 20131029 ( ( 版)) http://krijnhoetmer.nl/irc-logs/whatwg/20131029#l-348

[894] IRC logs: freenode / #whatwg / 20131030 ( ( 版)) http://krijnhoetmer.nl/irc-logs/whatwg/20131030#l-312

[895] Attachment #8336745 for bug #910211 ( ( 版)) https://bugzilla.mozilla.org/attachment.cgi?id=8336745&action=diff#a/dom/encoding/domainsfallbacks.properties_sec2

[898] Bug 14703 – Integrate style sheet loading with CSSOM ( ( 版)) https://www.w3.org/Bugs/Public/show_bug.cgi?id=14703

[899] Web Applications 1.0 r8391 Define how <link charset> works. ( ( 版)) http://html5.org/tools/web-apps-tracker?from=8390&to=8391

[900] Please consider if your locale could default to UTF-8 for outgoing email - Google グループ ( ( 版)) https://groups.google.com/forum/#!topic/mozilla.dev.l10n/PH7tF9m8vUY

[907] Welcome to Netscape Navigator Version 2.0 ( ( 版)) http://web.archive.org/web/20030202175634/http://wp.netscape.com/eng/mozilla/2.0/relnotes/windows-2.0.html#Images

[908] Welcome to Netscape Navigator Version 1.1 ( ( 版)) http://web.archive.org/web/20030203042026/http://wp.netscape.com/eng/mozilla/1.1/relnotes/windows-1.1.html#Images

[910] Character Model for the World Wide Web 1.0: Fundamentals ( ( 版)) http://www.w3.org/TR/charmod/#sec-EncodingIdent

[911] Bug 25534 – HTML spec should not encourage to auto-detect UTF-8 ( ( 版)) https://www.w3.org/Bugs/Public/show_bug.cgi?id=25534

[913] Internationalization Tag Set (ITS) Version 2.0 ( ( 版)) http://www.w3.org/TR/its20/#storagesize

[924] Bug 26655 – Support mistakenly `utf-`-prefixed encodings seen in the wild ( ( 版)) https://www.w3.org/Bugs/Public/show_bug.cgi?id=26655

[925] RFC 5987 - Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters ( ( 版)) http://tools.ietf.org/html/rfc5987#section-3.2

[85] OASIS Open Document Format for Office Applications (OpenDocument) Version 1.2 - Part 1: OpenDocument Schema ( 版) http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#a18_3_35textEncoding

A character encoding in the notation described in the §4.3.3 of [XML1.0], or the value x-symbol. The value is x-symbol means that the character encoding is not enumerated by §4.3.3 of [XML1.0].

[86] OASIS Open Document Format for Office Applications (OpenDocument) Version 1.2 - Part 1: OpenDocument Schema ( 版) http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#a19_479style_font-charset

The value of this attributes can be x-symbol or a character encoding in the notation described in the §4.3.3 of [XML1.0]. If the value is x-symbol, the font does not define glyphs according to the semantics of [UNICODE].

[87] OASIS Open Document Format for Office Applications (OpenDocument) Version 1.2 - Part 1: OpenDocument Schema ( 版) http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#a20_260style_font-charset

The value of this attributes can be x-symbol or a character encoding in the notation described in the §4.3.3 of [XML1.0]. If the value is x-symbol, the font does not define glyphs according to the semantics of [UNICODE]. If the value is one of the encodings or transformations of [UNICODE], the font does define glyphs according to the semantics of [UNICODE]. The use of other values is deprecated.

[94] ( 版) http://lynx.isc.org/current/CHANGES2.6

06-07-96

* Moved the Kanji handling variables into HText structure elements to make

the GridText.c functions reentrant for them, and added code for regulating

them via charset parameters in server headers or META tags. The recognized

parameters are EUC-JP, Shift-JIS, ISO-2022-JP, ISO-2022-JP-2, and EUC-KR.

E.g., a META with:

HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=Shift-JIS"

will set up handling of the document as Shift-JIS. - FM

[95] ハングル工房 綾瀬 - internet上のハングル ( 版) http://www.han-lab.gr.jp/~mizuno/com/web.html

[96] Welcome to Netscape Navigator Version 2.0 ( 版) http://web.archive.org/web/20030202175634/http://wp.netscape.com/eng/mozilla/2.0/relnotes/windows-2.0.html

MIME charsets supported include:

"us-ascii", "iso-8859-1", "x-mac-roman", "iso-8859-2", "x-mac-ce"

"iso-2022-jp","x-sjis", "x-euc-jp",

"euc-kr", "iso-2022-kr",

"gb2312", "gb_2312-80"

"x-euc-tw", "x-cns11643-1", "x-cns11643-2", "big5"

[97] Welcome to Netscape Navigator Version 2.0 ( 版) http://web.archive.org/web/20030202175634/http://wp.netscape.com/eng/mozilla/2.0/relnotes/windows-2.0.html

The IETF draft on Internationalization of the Hypertext Markup Language proposes an extension to the HTML META tag to allow MIME charset information to be contained in the HTML document:

<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-2022-JP">

This support is in Navigator 2.0 and the MIME charset values supported includes all the charsets mentioned above in the section on "Additional Languages and MIME Charsets" Supported.

[98] XHTML™ 2.0 - XHTML Embedding Attributes Module ( 版) http://www.w3.org/TR/2010/NOTE-xhtml2-20101216/mod-embedding.html

[99] Authoring Techniques for XHTML & HTML Internationalization: Characters and Encodings 1.0 ( ( 版)) http://www.w3.org/TR/2015/NOTE-i18n-html-tech-char-20150127/

[156] Only replace charset parameter values that do not case-insensitively … · whatwg/xhr@a1f8e14 ( 版) https://github.com/whatwg/xhr/commit/a1f8e140fef9e3ee8255ef58a2c71ff9d75933d2

[158] 各ブラウザが解釈可能なcharsetのリスト ( 版) http://l0.cm/encodings/list/

[159] Add <script type="module"> and module resolution/fetching/evaluation · whatwg/html@cd1a9fb ( 版) https://github.com/whatwg/html/commit/cd1a9fb1e83f7d0bc30be8b34ecdaf444a0b19a4

[161] Update integration with Encoding Standard · whatwg/html@6a31c26 ( 版) https://github.com/whatwg/html/commit/6a31c26cf12e39dab1a488e75dd56c03d6786d39

[174] oauth.access method | Slack (Slack著, ) https://api.slack.com/methods/oauth.access

superfluous_charset

The method was called via a POST request, and the specified Content-Type is not defined to understand the charset parameter. However, charset was in fact present. Specifically, form-data content types (e.g. multipart/form-data) are the ones for which charset is superfluous.

[177] 18338 – Registries (IANA): text/html MIME type definition should require that charset="" value be valid and correct () https://www.w3.org/Bugs/Public/show_bug.cgi?id=18338

[178] [c] (0) Outlaw <meta http-equiv=content-type content=t&#x0065;xt/html… (Hixie著, ) https://github.com/whatwg/html/commit/ea48293c495d6c863ff4813cac17f37d32fdaf63

[179] [ct] (0) Require that if a <meta> charset is included, the encoding b… (Hixie著, ) https://github.com/whatwg/html/commit/ac3cdabc9466b5530e5d7f21f4586c95e19c3b5e

[181] Improve <style> and <script> processing and conformance (domenic著, ) https://github.com/whatwg/html/commit/9c612ac8641b5174849a2d3cb924fe662a8d3a09

[182] Require UTF-8 (sideshowbarker著, ) https://github.com/whatwg/html/commit/fae77e3c558b9f083dfb9086752863a4789268f5

[185] Require utf-8 when specifying character encoding by sideshowbarker · Pull Request #3091 · whatwg/html () https://github.com/whatwg/html/pull/3091

[186] Invitation to attend upcoming IETF meetings · Issue #58 · whatwg/meta () https://github.com/whatwg/meta/issues/58

[187] Define Content-Type manipulation in terms of MIME Sniffing (annevk著, ) https://github.com/whatwg/xhr/commit/edc6f8f16f58d201afb49e40ca166b8bc1ae74a3

[188] Fix send() charset overriding to use new MIME type infrastructure · Issue #188 · whatwg/xhr () https://github.com/whatwg/xhr/issues/188

[189] Define Content-Type manipulation in terms of MIME Sniffing by annevk · Pull Request #176 · whatwg/xhr () https://github.com/whatwg/xhr/pull/176

[190] Fix overrideMimeType() again (annevk著, ) https://github.com/whatwg/xhr/commit/121cee50b6f51215f046266642964b4c53a02a7c

[191] Look at overrideMimeType() again · Issue #157 · whatwg/xhr () https://github.com/whatwg/xhr/issues/157

[203] rfc3808, https://datatracker.ietf.org/doc/html/rfc3808

[204] rfc3659 () https://datatracker.ietf.org/doc/html/rfc3659#section-7.5

Updated: