Saubere 8 Bit beschreiben ein Computersystem, das richtig 8-Bit-Charakter encodings, wie der ISO 8859 Reihen und die UTF-8-Verschlüsselung von Unicode behandelt.

Geschichte

Bis zum Anfang der 1990er Jahre haben viele Programme und Datenübertragungskanäle angenommen, dass alle Charaktere als Zahlen zwischen 0 und 127 (7 Bit) vertreten würden. Auf Computern und Datenverbindungen mit 8-Bit-Bytes hat das das Spitzenbit jedes Bytes frei für den Gebrauch als eine Gleichheit verlassen, Fahne, hat oder meta Datenkontrollbit gebissen. 7-Bit-Systeme und Datenverbindungen sind unfähig, kompliziertere Charakter-Codes zu behandeln, die in englisch nichtsprechenden Ländern mit größeren Alphabeten gewöhnlich sind.

Binäre Dateien können durch 7-Bit-Datenkanäle direkt nicht übersandt werden. Um darum zu arbeiten, sind zum Text binäre encodings ausgedacht worden, die ASCII nur 7 Bit Charaktere verwenden. Einige dieser encodings sind uuencoding, Ascii85, SREC, BinHex, kermit und der Base64 der PANTOMIME. EBCDIC-basierte Systeme können alle in UUencoded Daten verwendeten Charaktere nicht behandeln. Jedoch hat die Base64-Verschlüsselung dieses Problem nicht.

Vielleicht wurde die End-7-Bit-Beschränkung, in erster Linie auferlegt wegen des durchdringenden Gebrauches des RS-232 Protokolls für Serienhäfen zwischen Geräten, namentlich Computern und Modems, Mitte der 1990er Jahre gehoben, als RS-232 durch Ethernet und durch USB größtenteils ersetzt wurde.

SMTP und NNTP 8-Bit-Sauberkeit

Historisch wurden verschiedene Medien verwendet, um Nachrichten, einige von ihnen nur das Unterstützen von 7-Bit-Daten zu übertragen, so hatte eine 8-Bit-Nachricht hohe Chancen, während der Übertragung im 20. Jahrhundert durcheinander gebracht zu werden. Aber einige Internetdurchführungen haben sich wirklich über das formelle Entmutigen der 8-Bit-Daten nicht gesorgt und haben hohen Bohrersatz-Bytes erlaubt durchzugehen.

Viele frühe Kommunikationsprotokoll-Standards, wie RFC 780, RFC 788, RFC 821 für SMTP, RFC 977 für NNTP, RFC 1056, RFC 2821, RFC 5321, wurden entworfen, um über solche "7-Bit-"-Nachrichtenverbindungen zu arbeiten. Sie erwähnen spezifisch den Gebrauch der ASCII Codierung "übersandt, weil ein 8-Bit-Byte mit der hohen Ordnung geklärt zur Null" und einige dieser gebissen

schränken Sie ausführlich alle Daten auf 7-Bit-Charaktere ein.

Seit den ersten paar Jahrzehnten von E-Mail-Netzen (1971 zum Anfang der 1990er Jahre),

die meisten E-Mail-Nachrichten waren Klartext in der 7-Bit-Codierung der US-ASCII.

Gemäß RFC 1428 der ursprüngliche RFC beschränkt 821 Definition von SMTP Internetpost auf

Linien (1000 Charaktere oder weniger) 7-Bit-Charaktere des US-ASCII.

Später wurde das Format von E-Mail-Nachrichten wiederdefiniert

um zu unterstützen

Nachrichten, die nicht völlig Text des US-ASCII sind

(SMS-Nachrichten in Codierungen

anders als US-ASCII,

und Nichtsms-Nachrichten,

solcher als Audio- und Images).

Die Internetgemeinschaft fügt allgemein Eigenschaften durch "die Erweiterung" hinzu, Kommunikation in beiden Richtungen zwischen beförderten Maschinen und noch nicht beförderten Maschinen erlaubend, anstatt früher standardentgegenkommende Vermächtnis-Software zu erklären, "gebrochen" zu werden und dass die ganze Software darauf bestehend, weltweit zum letzten Standard befördert werden.

Mitte der 1990er Jahre haben Leute gegen protestiert "gerade senden 8 Bit (an RFC 821 SMTP Server)",

vielleicht wegen einer Wahrnehmung, dass "gerade 8 Bit" senden

ist eine implizite Behauptung, dass ISO 8859-1 die neue "Standardverschlüsselung" werden, jeden in der Welt zwingend, dieselbe Codierung zu verwenden.

Statt dessen soll die empfohlene Weise, saubere 8-Bit-Verbindungen zwischen Maschinen auszunutzen, den ESMTP (RFC 1869) 8BITMIME Erweiterung verwenden.

Trotzdem ein MTAs, namentlich Exim und qmail, Relaispost zu Servern, die 8BITMIME nicht inserieren, ohne die Konvertierung zu 7-Bit-PANTOMIME (normalerweise angesetzt - druckfähig, "Q-P Konvertierung") erforderlich durch RFC 6152 durchzuführen. Diese "just-send-8" Einstellung verursacht Probleme in der Praxis nicht tatsächlich, da eigentlich alle modernen E-Mail-Server saubere 8 Bit sind.

Siehe auch

• Telnet#8-bit Daten
• 32 Bit reinigen