8ビットクリーン

コンピュータネットワークにおいて、システムが8ビットクリーンであるとは、 8ビット文字エンコーディングを処理する際に、最上位ビットを変更したり、バイトを帯域内制御コードとして扱ったりしない場合を指します。この特性は、通信プロトコルと、そのようなプロトコルを実装するソフトウェアやデバイスの両方に当てはまります。初期の電子メールシステムの多くは7ビットデータしかサポートしていませんでしたが、現代の電子メールシステムの大部分は8ビットクリーンです。

1990年代初頭まで、多くのプログラムやデータ伝送チャネルは文字指向であり、テキストの末尾文字(ETX)などの一部の文字を制御文字として扱っていました。その他は、0 から 127 の間の値を持つ 7 ビット文字のストリームを想定していました。たとえば、ASCII規格では、データ伝送コストを節約するために8 ビット表現を避け、1 文字あたり 7 ビットのみを使用していました。8ビット バイトを使用するコンピュータやデータ リンクでは、各バイトの最上位ビットがパリティ ビット、フラグ ビット、またはメタデータ制御ビットとして使用できるようになっていました。7 ビット システムやデータ リンクでは、より大きなアルファベットを使用する英語圏以外の国で一般的な、より複雑な文字コードを直接処理することはできません。

8ビットオクテットで構成されるバイナリファイルは、 7ビットデータチャネルを介して直接送信することはできません。この問題を回避するために、7ビットASCII文字のみを使用するバイナリからテキストへのエンコード方式が考案されました。これらのエンコード方式には、 uuencoding、Ascii85、SREC、BinHex、kermit、MIMEのBase64などがあります。EBCDICベースのシステムでは、 UUエンコードされたデータで使用されるすべての文字を処理できません。しかし、Base64エンコードにはこの問題はありません。

歴史的に、メッセージの転送にはさまざまな媒体が使用されてきましたが、その中には7ビットデータしかサポートしていないものもあったため、20世紀には8ビットメッセージは送信中に破損する可能性が高かったのです。一部の実装では、8ビットデータの使用を推奨しないという公式な方針を無視し、最上位ビットがセットされたバイトを通過させていました。このような実装は8ビットクリーンであると言われています。一般的に、通信プロトコルは、通信プロセスにおいて各バイトの最上位ビットを正しく通過させる場合に、8ビットクリーンであると言われます。

RFC 780、788、821、2821、5321（SMTP用）、RFC 977 （NNTP用）、RFC 1056などの初期の通信プロトコル標準の多くは、このような「7ビット」通信リンク上で動作するように設計されていました。これらは特に「最上位ビットをゼロにクリアした8ビットバイトとして送信される」ASCIIの使用を要求しており、これらのいくつかは^{[ 1 ]}すべてのデータを7ビット文字に明示的に制限しています。   

電子メールネットワークの最初の数十年間（1971年から1990年代初頭まで）は、ほとんどの電子メールメッセージは7ビットUS-ASCII文字セットのプレーンテキストでした。 ^{[ 2 ]}

SMTP の RFC 788 の定義は、前身の RFC 780 と同様に、インターネット メールを 7 ビット US-ASCII 文字の行 (1000 文字以下) に制限しています。^{[ 3 ] [ 4 ] [ 5 ] [ 6 ]}

その後、電子メールメッセージのフォーマットは、完全にUS-ASCIIテキストではないメッセージ（US-ASCII以外の文字セットのテキストメッセージ、および音声や画像などの非テキストメッセージ）をサポートするために再定義されました。^{[ 6 ]}ヘッダーフィールドContent-Transfer-Encoding=binary ^{[ a ]}は、8ビットのクリーンなトランスポートを必要とします。

RFC 3977 ^{[ 7 ]}では、「NNTP は、信頼性の高い双方向 8 ビット幅のデータ ストリーム チャネル上で動作する」と規定し、コマンドの文字セットをUTF-8に変更しています。しかし、RFC 5536 ^{[ 8 ]}では、文字セットを ASCII に制限しており、RFC 2047 ^{[ 9 ]}および RFC 2231 ^{[ 10 ]}による非 ASCII データの MIME エンコーディングも含まれています。

インターネット コミュニティは一般的に、以前は標準に準拠していたレガシー ソフトウェアが壊れていると宣言して世界中のすべてのソフトウェアを最新の標準にアップグレードすることを要求するのではなく、拡張機能によって機能を追加し、アップグレードされたマシンとまだアップグレードされていないマシンの間で双方向の通信を可能にします。マシン間の 8 ビット クリーン リンクを活用する推奨方法は、メッセージ本文に ESMTP ( RFC 1869 ) 8BITMIME拡張機能^{[ 11 ] [ 12 ]}を、メッセージ ヘッダーに SMTP SMTPUTF8 ^{[ 13 ]}拡張機能を使用することです。これにもかかわらず、Eximやqmailなどの一部のメール転送エージェントは、RFC 6152 で要求されている 7 ビット MIME (通常はquoted-printable、「QP 変換」)への変換を実行せずに、 8BITMIMEを宣伝していないサーバーにメールを中継します。実際には、この「8 ビットで送信する」という姿勢は、事実上すべての最新のメール サーバーが 8 ビット クリーンであるため、実際には問題を引き起こしません。^{[ 14 ]}  

• 32ビットクリーン
• MIME § コンテンツ転送エンコーディング
• Telnet