Binär-till-text-kodning

En binär-till-text-kodning är kodning av data i vanlig text . Mer exakt är det en kodning av binära data i en sekvens av utskrivbara tecken . Dessa kodningar är nödvändiga för överföring av data när kanalen inte tillåter binär data (som e-post eller NNTP ) eller inte är 8-bitars ren . PGP- dokumentation ( RFC 4880 ) använder termen " ASCII-pansar " för binär-till-text-kodning när man refererar till Base64 .

Översikt

Det grundläggande behovet av en binär-till-text-kodning kommer från ett behov av att kommunicera godtyckliga binära data över redan existerande kommunikationsprotokoll som utformades för att endast bära engelskspråkig text som kan läsas av människor . Dessa kommunikationsprotokoll kanske bara är 7-bitars säkra (och inom det undviker vissa ASCII-kontrollkoder), och kan kräva radbrytningar vid vissa maximala intervall och kanske inte bibehålla blanksteg . Således är endast de 94 utskrivbara ASCII-tecknen "säkra" att använda för att överföra data.

Beskrivning

ASCII - textkodningsstandarden använder 7 bitar för att koda tecken. Med detta är det möjligt att koda 128 (dvs. 2 ⁷ ) unika värden (0–127) för att representera de alfabetiska, numeriska och skiljetecken som vanligtvis används på engelska , plus ett urval av kontrollkoder som inte representerar utskrivbara tecken. Till exempel är den stora bokstaven A ASCII-tecken 65, siffran 2 är ASCII 50, tecknet } är ASCII 125 och metateckens vagnretur är ASCII 13. System baserade på ASCII använder sju bitar för att representera dessa värden digitalt.

Däremot lagrar de flesta datorer data i minnet organiserade i åtta-bitars byte . Filer som innehåller maskinkörbar kod och icke-textdata innehåller vanligtvis alla 256 möjliga åttabitars bytevärden. Många datorprogram kom att förlita sig på denna distinktion mellan sju-bitars text och åtta-bitars binära data, och skulle inte fungera korrekt om icke-ASCII-tecken förekom i data som förväntades innehålla endast ASCII-text. Till exempel, om värdet på den åttonde biten inte bevaras, kan programmet tolka ett bytevärde över 127 som en flagga som säger åt det att utföra någon funktion.

Ofta är det dock önskvärt att kunna skicka icke-textuell data genom textbaserade system, till exempel när man kan bifoga en bildfil till ett e-postmeddelande. För att åstadkomma detta kodas data på något sätt, så att åttabitars data kodas till sjubitars ASCII-tecken (vanligtvis med endast alfanumeriska tecken och skiljetecken – de utskrivbara ASCII-tecken ). Vid säker ankomst till sin destination avkodas den sedan tillbaka till sin åttabitars form. Denna process kallas binär till textkodning. Många program utför denna konvertering för att möjliggöra datatransport, såsom PGP och GNU Privacy Guard (GPG).

Kodning av vanlig text

Binär-till-text-kodningsmetoder används också som en mekanism för kodning av vanlig text . Till exempel:

Vissa system har en mer begränsad teckenuppsättning de kan hantera; inte bara är de inte 8-bitars rena , vissa kan inte ens hantera alla utskrivbara ASCII-tecken.
Andra system har begränsningar för antalet tecken som kan visas mellan radbrytningar , till exempel gränsen "1000 tecken per rad" för vissa SMTP -program, som tillåts av RFC 2821 .
Ytterligare andra lägger till rubriker eller trailers till texten.
Några få dåligt ansedda men fortfarande använda protokoll använder in-band signalering , vilket orsakar förvirring om specifika mönster visas i meddelandet. Den mest kända är strängen "Från " (inklusive efterföljande utrymme) i början av en rad som används för att separera e-postmeddelanden i filformatet mbox .

Genom att använda en binär-till-text-kodning på meddelanden som redan är ren text, och sedan avkoda i andra änden, kan man få sådana system att framstå som helt transparenta . Detta kallas ibland för "ASCII-pansar". använder ViewState-komponenten i ASP.NET base64- kodning för att säkert överföra text via HTTP POST, för att undvika kollision med avgränsare .

Kodningsstandarder

Tabellen nedan jämför de mest använda formerna av binär-till-text-kodningar. Effektiviteten som anges är förhållandet mellan antalet bitar i ingången och antalet bitar i den kodade utgången.

Kodning	Data typ	Effektivitet	Implementering av programmeringsspråk	Kommentarer
Ascii85	Slumpmässig	80 %	awk , C , C (2) , C# , F# , Go , Java Perl , Python , Python (2)	Det finns flera varianter av denna kodning, Base85 , btoa , et cetera.
Base32	Slumpmässig	62,5 %	ANSI C , Delphi , Go , Java , Python
Base36	Heltal	~64 %	bash , C , C++ , C# , Java , Perl , PHP , Python , Visual Basic , Swift , många andra	Använder de arabiska siffrorna 0–9 och de latinska bokstäverna A–Z (det grundläggande latinska ISO-alfabetet) . Används vanligtvis av URL-omdirigeringssystem som TinyURL eller SnipURL/Snipr som kompakta alfanumeriska identifierare.
Bas 45	Slumpmässig	~67 % (97 %)	Gå	Definierat i IETF-specifikationen RFC 9285 för att inkludera binär data kompakt i en QR-kod .
Base56	Heltal	—	PHP Python Go	En variant av Base58-kodning som ytterligare tar bort de gemena "i" och "o" tecknen för att minimera risken för bedrägerier och mänskliga misstag.
Base58	Heltal	~73 %	C++ , Python , C#	Liknar Base64, men modifierad för att undvika både icke-alfanumeriska tecken (+ och /) och bokstäver som kan se tvetydiga ut när de skrivs ut (0 – noll, I – stor i, O – stor o och l – gemen L). Base58 används för att representera bitcoin- adresser. Vissa meddelandesystem och sociala medier bryter linjer på icke-alfanumeriska strängar. Detta undviks genom att inte använda URI-reserverade tecken som +. För segwit ersattes den av Bech32, se nedan. Base58 i den ursprungliga bitcoin-källkoden
Base62	Slumpmässig	~74 %	Rost	Liknar Base64, men innehåller bara alfanumeriska tecken.
Base64	Slumpmässig	75 %	awk , C , C (2) , Delphi , Go , Python , många andra
Base85 ( RFC 1924 )	Slumpmässig	80 %	C , Python Python (2)	Reviderad version av Ascii85 .
Bas 91	Slumpmässig	81 %	C# F#	Variant med konstant bredd
basE91	Slumpmässig	81 %	C, Java, PHP, 8086 Assembly, AWK C# F# Rust	Variabel breddvariant
Bas 94	Slumpmässig	82 %	Python C
Bas 122	Slumpmässig	87,5 %	JavaScript Python Java Base125 Python och Javascript Go C
BaseXML	Slumpmässig	83,5 %	C Python JavaScript
Bech32	Slumpmässig	62,5 % + minst 8 tecken (etikett, separator, 6-tecken ECC )	C, C++, JavaScript, Go, Python, Haskell, Ruby, Rust	Specifikation. Används i Bitcoin och Lightning Network . Datadelen är kodad som Base32 med möjlighet att kontrollera och korrigera upp till 6 felskrivna tecken med hjälp av 6-tecken BCH-koden i slutet, som också kontrollerar/korrigerar HRP (Human Readable Part). Bech32m-varianten har en subtil förändring som gör den mer motståndskraftig mot längdförändringar.
BinHex	Slumpmässig	75 %	Perl , C , C (2)	MacOS Classic
Decimal	Heltal	~42 %	De flesta språk	Vanligtvis standardrepresentationen för input/output från/till människor.
Hexadecimal (Bas16)	Slumpmässig	50 %	De flesta språk	Finns i versaler och gemener
Intel HEX	Slumpmässig	≲50 %	C-bibliotek , C++	Används vanligtvis för att programmera EPROM , NOR-Flash minneschips
MIMA	Slumpmässig	Se Citat-utskrivbart och Base64	Se Citat-utskrivbart och Base64	Kodningsbehållare för e-postliknande formatering
Procentkodning	Text ( URI ), godtycklig ( RFC1738 )	~40 % (33–70 %)	C , Python , förmodligen många andra
Citerat-utskrivbart	Text	~33–100 %	Förmodligen många	Bevarar radbrytningar; skär rader med 76 tecken
S-rekord (Motorola hex)	Slumpmässig	49,6 %	C-bibliotek , C++	Används vanligtvis för att programmera EPROM , NOR-Flash minneschips. 49,6 % antar 255 binära byte per post.
Tektronix hex	Slumpmässig			Används vanligtvis för att programmera EPROM , NOR-Flash minneschips.
Uuencoding	Slumpmässig	~60 % ( upp till 70 % )	Perl , C , Delphi , Java , Python , förmodligen många andra	Till stor del ersatt av MIME och yEnc
Xxencoding	Slumpmässig	~75 % (liknar Uuencoding)	C , Delphi	Föreslagen (och används ibland) som ersättning för Uuencoding för att undvika teckenuppsättningsöversättningsproblem mellan ASCII och EBCDIC-systemen som kan korrumpera Uuencoded data
z85 ( ZeroMQ spec:32/Z85 )	Binär & ASCII	80 % (liknar Ascii85/Base85)	C (original), C# , Dart , Erlang , Go , Lua , Ruby , Rust och andra...	Specificerar en delmängd av ASCII som liknar Ascii85 , utelämnar några tecken som kan orsaka programbuggar ( ` \ " ' _ , ; ). Formatet överensstämmer med ZeroMQ spec:32/Z85 .
RFC 1751 ( S/KEY )	Slumpmässig	33 %	C, Python , ...	"En konvention för mänskligt läsbara 128-bitars nycklar". En serie små engelska ord är lättare för människor att läsa, komma ihåg och skriva in än decimaler eller andra binär-till-text-kodningssystem. Varje 64-bitars nummer mappas till sex korta ord, på ett till fyra tecken vardera, från en offentlig 2048-ords ordbok.

De 95 isprint -koderna 32 till 126 är kända som de utskrivbara ASCII-tecken .

Vissa äldre och idag ovanliga format inkluderar BOO, BTOA och USR-kodning.

De flesta av dessa kodningar genererar text som bara innehåller en delmängd av alla utskrivbara ASCII- tecken: till exempel genererar base64 -kodningen text som bara innehåller stora och små bokstäver, (A–Z, a–z), siffror (0–9) och symbolerna "+", "/" och "=".

Vissa av dessa kodningar (utskrivbara citerade och procentkodningar) är baserade på en uppsättning tillåtna tecken och ett enda escape-tecken . De tillåtna tecknen lämnas oförändrade, medan alla andra tecken konverteras till en sträng som börjar med escape-tecknet. Denna typ av konvertering gör att den resulterande texten är nästan läsbar, eftersom bokstäver och siffror är en del av de tillåtna tecknen och därför lämnas som de är i den kodade texten. Dessa kodningar ger den kortaste vanliga ASCII-utgången för indata som mestadels är utskrivbar ASCII.

Vissa andra kodningar ( base64 , uuencoding ) är baserade på att mappa alla möjliga sekvenser av sex bitar till olika utskrivbara tecken. Eftersom det finns fler än 2 ⁶ = 64 utskrivbara tecken är detta möjligt. En given sekvens av bytes översätts genom att se den som en ström av bitar, bryta denna ström i bitar om sex bitar och generera sekvensen av motsvarande tecken. De olika kodningarna skiljer sig åt i mappningen mellan sekvenser av bitar och tecken och i hur den resulterande texten formateras.

Vissa kodningar (originalversionen av BinHex och den rekommenderade kodningen för CipherSaber ) använder fyra bitar istället för sex, och mappar alla möjliga sekvenser av 4 bitar på de 16 standard hexadecimala siffrorna. Att använda 4 bitar per kodat tecken leder till en 50 % längre utdata än base64, men förenklar kodning och avkodning – att expandera varje byte i källan oberoende till två kodade byte är enklare än base64:s expanderande 3 källbyte till 4 kodade byte.

Av PETSCII: s första 192 koder har 164 synliga representationer när de citeras: 5 (vit), 17–20 och 28–31 (färger och markörkontroller), 32–90 (motsvarande ascii), 91–127 (grafik), 129 (orange), 133–140 (funktionstangenter), 144–159 (färger och markörkontroller) och 160–192 (grafik). Detta tillåter teoretiskt sett kodningar, såsom base128, mellan PETSCII-talande maskiner.

Se även

Anteckningar