[13] [[ASCII]] との[[互換性]]が求められることがしばしばあります。 何をもって[[互換]]というかには色々な解釈があります。 [36] 似て非なる定義がいくつかあって、 それらの意味も不明瞭なところがあり、 混乱の元となるのでこうした用語は使うべきではないのかもしれません。 * ASCII 互換文字符号化 (Web) [2] [DFN[[RUBYB[ASCII 互換文字符号化]@en[ASCII-compatible character encoding]]]]とは、ある程度 [[ASCII]] と互換性のある[[文字符号化方式]]を表す [[HTML]] 仕様上の用語です。 ** 仕様書 [REFS[ - [1] [CITE@en-US-x-hixie[HTML Standard]] ([TIME[2013-11-22 20:38:38 +09:00]] 版) ]REFS] ** 定義 [3] [[単一バイト]]または可変長の[[符号化]]であって、 0x09, 0x0A, 0x0C, 0x0D, 0x20 - 0x22, 0x26, 0x27, 0x2C - 0x3F, 0x41 - 0x5A, 0x61 - 0x7A の範囲の第1[[バイト]]がすべて [[Windows-1252]] と同じ [[Unicode文字]]を表すものを[[ASCII互換文字符号化]]といいます。 [SRC[>>1]] [4] この定義だと [[ISO-2022-JP]] や [[HZ-GB-2312]] は ASCII 非互換のように思えますが、 仕様書の注釈によってこれらは ASCII 互換に含まれるとされています。 [5] 同じく注釈によると [[UTF-16]]、[[UTF-7]]、[[GSM03.38]]、[[EBCDIC]] は非互換とされています。 ;; [6] >>4 が含まれるなら [[UTF-7]] も ASCII 互換に含まれていいようなものですが、 [CODE[[[+]]]] などが条件に合致しないのでしょう。 [7] [[Encoding Standard]] の範囲では、 [[UTF-16]] ([[utf-16be]] と [[utf-16]]) と [[replacement]] 以外はすべて [[ASCII互換文字符号化]]です。 [37] [[ISO/IEC 646の版]]は [[ASCII互換文字符号化]]です。 (おそらく意図的にそう定義されているのでしょう。) ** 歴史 [12] [CITE@en[Remove allow non-ASCII-compatible encodings flag · whatwg/html@c485b70]] ([TIME[2016-02-10 21:55:19 +09:00]] 版) * US-ASCII と互換 (HTTP) [10] [[RFC 7617]] は、[[基本認証]]における「[[US-ASCII]]と互換」を、 [[US-ASCII]] の[[文字]]が [[US-ASCII]] の[[文字コード]]と同じ1バイトに[[写像]]されるもの [SRC[>>9]] と定義しています。 [[ASCII互換文字符号化]]より厳しい制約です。 ;; [11] こちらの定義でも [[ISO-2022-JP]] や [[EUC-JP]] や [[Encoding Standard]] の [[shift_jis]] は[[ASCII互換]]です。 [[HZ-GB-2312]] や [[UTF-7]] は [[ASCII互換]]ではありません。 [REFS[ - [9] [CITE@en[RFC 7617 - The 'Basic' HTTP Authentication Scheme]] ([TIME[2015-10-01 09:47:40 +09:00]] 版) ]REFS] * ASCII 互換エンコーディング (Ruby) [14] [[Ruby]] における[DFN[ASCII互換エンコーディング]]は、 > [SNIP[]] US-ASCII に含まれる文字を \x00-\x7F で表し、ロッキングシフトを用いない エンコーディング[SNIP[]] です。 [SRC[>>15]] [16] 具体例として [[shift_jis]] や [[EUC-JP]] や [[UTF-8]] が挙げられています。 また、逆に [[ASCII 互換でないエンコーディング]]の例として、 [[ISO-2022-JP]] や [[UTF-16]] が挙げられています。 [SRC[>>15]] [17] 通常の [[ISO-2022-JP]] は [[ASCII]] を [ [N[0x00]], [N[0x7F]] ] で表し、[[固定シフト]]を用いないので、 [[ASCII互換エンコーディング]]の定義に当てはまりそうですが、 そうではないと説明されています。「ロッキングシフト」は [[ISO/IEC 2022]] の定める通常の意味とは違って、[[指示シーケンス]]などの状態遷移を行うもの全般を指すのかもしれません。 [18] [[shift_jis]] が[[ASCII互換エンコーディング]]であると明記されていることから、 [[ASCII文字]]以外が [ [N[0x00]], [N[0x7F]] ] を使うことは定義に反しないようです。 [19] また、「Ruby のエンコーディングのサポート水準」 として、 - [20] [[ASCII互換エンコーディング]] - [21] [[ASCII互換ではないエンコーディング]] - [22] [[ダミーエンコーディング]] ... の3段階があります。ここで、 [[ASCII互換ではないエンコーディング]]には [[UTF-16BE]] や [[UTF-16LE]] が含まれ、 [[ダミーエンコーディング]]には [[ISO-2022-JP]] や [[UTF-7]] が含まれます。 [SRC[>>15]] [23] [DFN[ダミーエンコーディング]]とは > [SNIP[]] Ruby が名前を知っているが、 文字の列としての処理に対応していないエンコーディングのことです。 実際には ISO-2022-JP や UTF-7 のようなステートフルエンコーディングがダミーエンコーディングになります。 [SNIP[]] と説明されています。 [SRC[>>15]] [24] つまり、[[ASCII互換ではないエンコーディング]]は広義には[[ダミーエンコーディング]]を含み、 狭義には含まないということのようです。 ;; [25] [[ASCII互換]]かどうかは構造に基づく名称で、 ダミーかどうかは [[Ruby]] の実装上の状態に基づく名称で、 2つの異なる評価軸が混ざって用語定義が難しくなっています。 [REFS[ - [15] [CITE@ja-JP[多言語化 (Ruby 1.9.3)]], [TIME[2016-08-28T13:48:39.000Z]], [TIME[2025-11-06T08:21:21.595Z]] ]REFS] -*-*- [26] [[Ruby]] には [DFN[[CODE[ASCII-8BIT]]]] という名前の[[エンコーディング]]があり、 > Ruby の String は、文字の列を扱うためだけでなく、バイトの列を扱うためにも使われます。 しかし、Ruby M17N には直接にバイナリを表すエンコーディングは存在しません。 このため、バイナリを String で扱う際には、ASCII 互換オクテット列を意味する ASCII-8BIT を用います。[SNIP[]] と説明されています。 [SRC[>>15]] [27] つまり[[ASCII互換エンコーディング]]の中に一般の[[文字符号化]]に相当する[[エンコーディング]]に加えて、 [DFN[ASCII互換オクテット列]] = [CODE[ASCII-8BIT]] なる[[バイナリーデータ]]のための[[エンコーディング]]があります。 ;; [28] 任意の[[バイナリーデータ]]は [[ASCII互換]]かどうか定かではないわけで、 「ASCII互換オクテット列」 とみなすべきものはプログラム開発者が [[ASCII互換]]と認識しているデータだけのはずであって、 [[ASCII互換]]ではない[[バイナリーデータ]]とは分けて扱う必要がありそうですが、 そのあたりがどうモデル化されているのかはこのドキュメントからは明らかではありません。 * 7ビットクリーン [34] [DFN[7ビットクリーン]]なる語が [[ASCII互換]]と似たような (しかし同じとも限らない) 意味で使われることがあるようです。 ;; [35] [[8ビットクリーン]]という語がよく使われますが、これは[[通信路]]の性質を表すもので、 まったく用法が異なります。しかしどちらも [[ASCII]] と関係が深い言葉であり、 もしかすると[[7ビットクリーン]]も[[8ビットクリーン]]からの連想で作られた言葉かもしれません。 しかし、[[7ビットクリーン]]という言葉はほとんど聞きませんし、 どのへんに「クリーン」さを感じて使っている語なのかもいまいちはっきりしません。 多用される[[8ビットクリーン]]との対比になっていないわかりにくい語なので、 使うべきではないでしょう。 [29] [[Ruby]] のドキュメントには次のような説明があります。 [SRC[>>15]] >ASCII互換エンコーディングである文字列や正規表現は、7bit クリーンな文字列や正規表現と、 結合・比較・マッチ等を行うことができます。 >[B[7bit クリーンな文字列]] >ASCII 互換エンコーディングをもつ 7bit クリーンな文字列は、 他の ASCII 互換エンコーディングを持つ文字列と結合・比較が可能です。 例えば、ASCII 互換エンコーディングをもつ文字列に、 7bit クリーンな文字列をエンコーディングの変換なしで結合することができます。 また、通常 Ruby の文字列比較メソッドである String#== は、 2 つの文字列のエンコーディングが異なっていると、バイト列としては一致していても false を返します。 しかし、7bit クリーンな文字列同士の比較の際は、 両者の文字エンコーディングが異なっていても、バイト列として一致していれば true を返します。 >[SNIP[]]このため、バイナリを String で扱う際には、ASCII 互換オクテット列を意味する ASCII-8BIT を用います。 これにより、ASCII 互換であるこの String は 7bit クリーンな文字列と比較・結合が可能となります。 >[SNIP[]]ダミーエンコーディングを持つ文字列の扱いは以下のように制限されます。 > -[SNIP[]] - エンコーディングの異なる 7bit クリーンな文字列との結合ができません。 例外 (EncodingCompatibilityError) が発生します。 [30] この説明から何が[DFN[7bit クリーンな文字列]]の定義であるのかははっきりしませんが、 どうやら[[非ASCII文字]]を含まないことは最低条件であると思われます。 -*-*- [32] >>31 は [[Python]] で[[インターネットメール]]を扱う[[ライブラリー]]の説明であり、 [CODE[Content-Transfer-Encoding]] の [CODE[7bit]] の説明で >all data must be "7 bit clean" (ASCII-only). [SNIP[]] とあります。すなわち [DFN[7 bit clean]] とは [[ASCII]] のみであることを意味すると説明されています。 [33] ただし、 [[MIME]] の [CODE[7bit]] は [[ASCII]] のみであることを意味しているのではなく、 [[7ビット]]の[[バイト]]で構成され、[[改行文字]]などの要件を満たしていることを意味しています。 この乖離が当該[[ライブラリー]]の機能に関係する正しい説明なのか、 ドキュメントの筆者の知識不足による誤った解説なのかは不明です。 [REFS[ - [31] [CITE@ja[19.1.4. email.policy: ポリシーオブジェクト — Python 3.6.15 ドキュメント]], [TIME[2021-12-29T22:58:39.000Z]], [TIME[2025-11-06T08:49:22.038Z]] ]REFS] * ACE (ドメイン名) [8] [[IDN]] の [[ACE]] は、 [[Unicode]] を [[DNS]] 等のために [[ASCII文字]]に変換する手法です。 [SEE[ [[ACE]] ]] * 関連