8 -bit ren - 8-bit clean

8-bit clean er en egenskab for computersystemer , kommunikationskanaler og andre enheder og software, der håndterer 8-bit tegnkoder korrekt. Sådan kodning omfatter ISO 8859- serien og UTF-8- kodning af Unicode .

Historie

Indtil begyndelsen af ​​1990'erne var mange programmer og dataoverførselskanaler karakterorienterede og behandlede nogle tegn, f.eks. ETX , som kontroltegn . Andre antog en strøm af syv-bit tegn med værdier mellem 0 og 127; for eksempel brugte ASCII- standarden kun syv bits pr. tegn, hvilket undgik en 8-bit repræsentation for at spare på dataoverførselsomkostninger. På computere og dataforbindelser, der bruger 8-bit bytes, forlod dette den øverste bit af hver byte fri til brug som paritet , flagbit eller metadatakontrolbit. 7-bit-systemer og dataforbindelser er i stand til direkte at håndtere mere komplekse tegnkoder, som er almindelige i ikke- engelsk talende lande med større alfabeter .

Binære filer med oktetter kan ikke transmitteres direkte via 7-bit datakanaler. For at omgå dette er der udviklet binær-til-tekst-kodninger , der kun bruger 7-bit ASCII- tegn. Nogle af disse kodninger er uuencoding , Ascii85 , SREC , BinHex , kermit og MIME 's Base64 . EBCDIC -baserede systemer kan ikke håndtere alle tegn, der bruges i UU -kodede data. Base64 -kodningen har imidlertid ikke dette problem.

SMTP og NNTP 8-bit renhed

Historisk blev forskellige medier brugt til at overføre meddelelser, nogle af dem understøttede kun 7-bit data, så en 8-bit besked havde store chancer for at blive forvansket under transmission i det 20. århundrede. Men nogle implementeringer var virkelig ligeglade med formel afskrækkelse af 8-bit data og lod højbit-sæt bytes passere. Sådanne implementeringer siges at være 8-bit rene. Generelt siges en kommunikationsprotokol at være 8-bit ren, hvis den korrekt passerer gennem den høje bit af hver byte i kommunikationsprocessen.

Mange tidlige kommunikationsprotokolstandarder , såsom RFC  780 , 788 , 821 , 2821 , 5321 (til SMTP ), RFC  977 (til NNTP ) og RFC  1056 , var designet til at fungere over sådanne "7-bit" kommunikationsforbindelser. De kræver specifikt brug af ASCII-tegnsæt "transmitteret som en 8-bit byte med højordensbiten ryddet til nul", og nogle af disse begrænser eksplicit alle data til 7-bit-tegn.

I de første årtiers e-mail-netværk (1971 til begyndelsen af ​​1990'erne) var de fleste e-mail-meddelelser almindelig tekst i 7-bit US-ASCII-tegnsættet.

Den RFC  788 Definitionen af SMTP, ligesom sin forgænger RFC  780 , begrænser Internet Mail til linier (1000 tegn eller mindre) af 7-bit US-ASCII-tegn.

Senere blev formatet på e-mail-beskeder gendefineret for at understøtte meddelelser, der ikke helt er US-ASCII-tekst (tekstbeskeder i andre tegnsæt end US-ASCII, og ikke-tekstbeskeder, f.eks. Lyd og billeder).

RFC  3977 specificerer "NNTP fungerer over enhver pålidelig tovejs 8-bit bred datastrømskanal." og ændrer tegnsættet for kommandoer til UTF-8. RFC  5536 begrænser imidlertid stadig tegnsættet til ASCII, herunder RFC  2047 og RFC  2231 MIME-kodning af ikke-ASCII-data.

Internetsamfundet tilføjer generelt funktioner i forlængelse , hvilket tillader kommunikation i begge retninger mellem opgraderede maskiner og endnu ikke opgraderede maskiner i stedet for at erklære, at tidligere software, der er i overensstemmelse med ældre software, er "brudt" og insisterer på, at al software i hele verden skal opgraderes til det nyeste standard. I midten af ​​1990'erne protesterede folk mod "bare at sende 8 bit (til RFC  821 SMTP-servere)", måske på grund af en opfattelse af, at "bare send 8 bits" er en implicit erklæring om, at ISO 8859-1 bliver den nye "standardkodning ", hvilket tvinger alle i verden til at bruge det samme tegnsæt . I stedet er den anbefalede måde at drage fordel af 8-bit-rene links mellem maskiner ved at bruge ESMTP ( RFC  1869 ) 8BITMIME- udvidelsen til meddelelseslegemer og SMTP SMTPUTF8- udvidelsen til beskedoverskrifter . På trods af dette videresender nogle e- mailoverførselsagenter , især Exim og qmail , mail til servere, der ikke annoncerer 8BITMIME uden at udføre konverteringen til 7-bit MIME (typisk citeret udskrivbar , "QP-konvertering"), der kræves af RFC  6152 . Denne "bare-send-8" -holdning medfører faktisk ikke problemer i praksis, da stort set alle moderne e-mailservere er 8-bit rene.

Se også

Referencer