Warum verwenden wir Base64?


275

Wikipedia sagt

Base64-Codierungsschemata werden häufig verwendet, wenn Binärdaten codiert werden müssen, die gespeichert und über Medien übertragen werden müssen, die für den Umgang mit Textdaten ausgelegt sind. Dies soll sicherstellen, dass die Daten während des Transports unverändert bleiben.

Aber ist es nicht so, dass Daten immer binär gespeichert / übertragen werden, weil der Speicher, den unsere Maschinen haben, binär gespeichert ist und es nur davon abhängt, wie Sie sie interpretieren? Unabhängig davon, ob Sie das Bitmuster 010011010110000101101110wie Manin ASCII oder TWFuin Base64 codieren , werden Sie schließlich dasselbe Bitmuster speichern.

Wenn die endgültige Codierung in Nullen und Einsen besteht und jede Maschine und jedes Medium damit umgehen kann, wie spielt es dann eine Rolle, ob die Daten als ASCII oder Base64 dargestellt werden?

Was bedeutet "Medien, die für den Umgang mit Textdaten ausgelegt sind"? Sie können mit Binär umgehen => sie können mit allem umgehen.


Vielen Dank an alle, ich glaube ich verstehe jetzt.

Wenn wir Daten senden, können wir nicht sicher sein, dass die Daten im gleichen Format interpretiert werden, wie wir es beabsichtigt haben. Wir senden also Daten, die in einem Format (wie Base64) codiert sind, das beide Parteien verstehen. Auf diese Weise werden die Daten auch dann nicht falsch interpretiert, wenn Sender und Empfänger dieselben Dinge unterschiedlich interpretieren. Da sie sich jedoch auf das codierte Format einigen.

Aus dem Beispiel von Mark Byers

Wenn ich senden möchte

Hello
world!

Eine Möglichkeit besteht darin, es wie in ASCII zu senden

72 101 108 108 111 10 119 111 114 108 100 33

Byte 10 wird jedoch möglicherweise nicht korrekt als Zeilenumbruch am anderen Ende interpretiert. Wir verwenden also eine Teilmenge von ASCII, um es so zu codieren

83 71 86 115 98 71 56 115 67 110 100 118 99 109 120 107 73 61 61

Dies sorgt auf Kosten von mehr Daten, die für dieselbe Informationsmenge übertragen werden, dafür, dass der Empfänger die Daten auf die beabsichtigte Weise decodieren kann, selbst wenn der Empfänger für den Rest des Zeichensatzes unterschiedliche Interpretationen hat.


6
Historischer Hintergrund: E-Mail-Server waren früher 7-Bit-ASCII. Viele von ihnen setzten das High-Bit auf 0, sodass Sie nur 7-Bit-Werte senden mussten. Siehe en.wikipedia.org/wiki/Email#Content_encoding
Harold L

53
Wir verwenden base64, weil es besser lesbar ist als Perl
Martin

2
@ Martin, du machst Witze. Perl ist schwer zu lesen, aber base64 ist überhaupt nicht lesbar.
Peter Long

1
@Lazer Ihr Bild fehlt
Mick

2
@Lazer, "Aber Byte 10 wird möglicherweise nicht richtig als Zeilenumbruch am anderen Ende interpretiert." Warum? Die beiden Parteien haben ASCII vereinbart und müssen es richtig interpretieren!
ProgramCpp

Antworten:


298

Ihr erster Fehler besteht darin, dass die ASCII-Codierung und die Base64-Codierung austauschbar sind. Sie sind nicht. Sie werden für verschiedene Zwecke verwendet.

  • Wenn Sie Text in ASCII codieren, beginnen Sie mit einer Textzeichenfolge und konvertieren sie in eine Folge von Bytes.
  • Wenn Sie Daten in Base64 codieren, beginnen Sie mit einer Folge von Bytes und konvertieren sie in eine Textzeichenfolge.

Um zu verstehen, warum Base64 überhaupt notwendig war, benötigen wir eine kleine Computergeschichte.


Computer kommunizieren in Binärform - Nullen und Einsen -, aber die Benutzer möchten normalerweise mit umfangreicheren Formulardaten wie Text oder Bildern kommunizieren. Um diese Daten zwischen Computern zu übertragen, müssen sie zuerst in Nullen und Einsen codiert, gesendet und dann erneut decodiert werden. Um Text als Beispiel zu nehmen: Es gibt viele verschiedene Möglichkeiten, diese Codierung durchzuführen. Es wäre viel einfacher, wenn wir uns alle auf eine einzige Kodierung einigen könnten, aber leider ist dies nicht der Fall.

Ursprünglich wurden viele verschiedene Codierungen erstellt (z. B. Baudot-Code ), die eine unterschiedliche Anzahl von Bits pro Zeichen verwendeten, bis schließlich ASCII mit 7 Bits pro Zeichen zum Standard wurde. Die meisten Computer speichern Binärdaten jedoch in Bytes mit jeweils 8 Bit, sodass ASCII für die Übertragung dieser Art von Daten ungeeignet ist. Einige Systeme würden sogar das höchstwertige Bit löschen. Darüber hinaus bedeutet der Unterschied in den Zeilenendcodierungen zwischen den Systemen, dass die ASCII-Zeichen 10 und 13 manchmal auch geändert wurden.

Um diese Probleme zu lösen, wurde die Base64- Codierung eingeführt. Auf diese Weise können Sie beliebige Bytes in Bytes codieren, von denen bekannt ist, dass sie sicher gesendet werden können, ohne beschädigt zu werden (alphanumerische ASCII-Zeichen und einige Symbole). Der Nachteil ist, dass die Codierung der Nachricht mit Base64 die Länge erhöht - alle 3 Datenbytes werden in 4 ASCII-Zeichen codiert.

Um Text zuverlässig Sie können senden erste kodieren zu Bytes mit einem Textcodierung Ihrer Wahl (zB UTF-8) und dann anschließend Base64 kodieren die resultierenden Binärdaten in einer Textzeichenfolge , die sicher als ASCII senden verschlüsselt. Der Empfänger muss diesen Vorgang umkehren, um die ursprüngliche Nachricht wiederherzustellen. Dies setzt natürlich voraus, dass der Empfänger weiß, welche Codierungen verwendet wurden, und diese Informationen müssen häufig separat gesendet werden.

In der Vergangenheit wurde es verwendet, um Binärdaten in E-Mail-Nachrichten zu codieren, bei denen der E-Mail-Server möglicherweise die Zeilenenden ändert. Ein moderneres Beispiel ist die Verwendung der Base64-Codierung, um Bilddaten direkt in HTML-Quellcode einzubetten . Hier müssen die Daten codiert werden, um zu vermeiden, dass Zeichen wie '<' und '>' als Tags interpretiert werden.


Hier ist ein Arbeitsbeispiel:

Ich möchte eine Textnachricht mit zwei Zeilen senden:

Hallo
Welt!

Wenn ich es als ASCII (oder UTF-8) sende, sieht es folgendermaßen aus:

72 101 108 108 111 10 119 111 114 108 100 33

Das Byte 10 ist in einigen Systemen beschädigt, sodass wir diese Bytes als Base64-Zeichenfolge codieren können:

SGVsbG8sCndvcmxkIQ ==

Was bei Codierung mit ASCII folgendermaßen aussieht:

83 71 86 115 98 71 56 115 67 110 100 118 99 109 120 107 73 61 61

Alle Bytes hier sind als sichere Bytes bekannt, daher besteht nur eine sehr geringe Wahrscheinlichkeit, dass ein System diese Nachricht beschädigt. Ich kann dies anstelle meiner ursprünglichen Nachricht senden und den Empfänger den Vorgang umkehren lassen, um die ursprüngliche Nachricht wiederherzustellen.


4
"Die meisten modernen Kommunikationsprotokolle beschädigen keine Daten" - obwohl dies beispielsweise bei E-Mails der Fall sein könnte, wenn ein Zusteller die Zeichenfolge "\ nVon" durch "\ n> Von" ersetzt, wenn die Nachricht in einem Postfach gespeichert wird. Oder HTTP-Header werden mit Zeilenumbrüchen ohne umkehrbare Möglichkeit beendet, Zeilenumbrüchen in den Daten zu entgehen (Zeilenfortsetzung führt zu Leerzeichen), sodass Sie auch nicht einfach beliebiges ASCII in sie ausgeben können. base64 ist besser als nur 7-Bit-Safe, es ist alphanumerisch und - = + / sicher.
Steve Jessop

1
"Der Nachteil ist, dass das Codieren der Nachricht mit Base64 ihre Länge erhöht - alle 3 Datenbytes werden auf 4 Bytes codiert." Wie erhöht es sich auf 4 Bytes? Wird es nicht immer noch 3 * 8 = 24 Bit sein?
Lazer

4
@Lazer: nein. Schauen Sie sich Ihr eigenes Beispiel an - "Man" ist Base-64-codiert als "TWFu". 3 Bytes -> 4 Bytes. Dies liegt daran, dass die Eingabe eines der 2 ^ 8 = 256 möglichen Bytes sein darf, während die Ausgabe nur 2 ^ 6 = 64 davon verwendet (und =, um die Länge der Daten anzugeben). 8 Bits pro Quartett der Ausgabe werden "verschwendet", um zu verhindern, dass die Ausgabe "aufregende" Zeichen enthält, obwohl die Eingabe dies tut.
Steve Jessop

2
Es kann hilfreich sein, "Wenn Sie Daten in Base64 codieren, beginnen Sie mit einer Folge von Bytes und konvertieren sie in eine Textzeichenfolge" als "Wenn Sie Daten in Base64 codieren, beginnen Sie mit einer Folge von Bytes und konvertieren sie in eine." Folge von Bytes, die nur aus ASCII-Werten bestehen ". Eine Folge von Bytes, die nur aus ASCII-Zeichen besteht, wird von SMTP benötigt, weshalb Base64 (und in Anführungszeichen druckbar) als Inhaltsübertragungscodierungen verwendet werden. Hervorragende Übersicht!
ALEXintlsos

1
Ich würde wählen, hat aber 64 Stimmen. Entschuldigung, das ist perfekt.
Jessé Catrinck

61

Codierung von Binärdaten in XML

Angenommen, Sie möchten einige Bilder in ein XML-Dokument einbetten. Die Bilder sind Binärdaten, während das XML-Dokument Text ist. XML kann jedoch keine eingebetteten Binärdaten verarbeiten. Wie machst du das?

Eine Möglichkeit besteht darin, die Bilder in base64 zu codieren und die Binärdaten in Text umzuwandeln, den XML verarbeiten kann.

Anstatt:

<images>
  <image name="Sally">{binary gibberish that breaks XML parsers}</image>
  <image name="Bobby">{binary gibberish that breaks XML parsers}</image>
</images>

Sie machen:

<images>
  <image name="Sally" encoding="base64">j23894uaiAJSD3234kljasjkSD...</image>
  <image name="Bobby" encoding="base64">Ja3k23JKasil3452AsdfjlksKsasKD...</image>
</images>

Der XML-Parser kann das XML-Dokument korrekt analysieren und die Bilddaten extrahieren.


So könnte das alte .mhtFormat von Microsoft funktionieren (HTML-Datei + Bilder in einer einzigen Datei).
Sridhar Sarnobat

38

Schauen Sie sich den RFC an, der derzeit Base64 definiert .

Die Basiscodierung von Daten wird in vielen Situationen zum Speichern oder Übertragen von
Daten in Umgebungen verwendet, die möglicherweise aus Legacy-Gründen auf US-ASCII [1] -Daten beschränkt sind. Die Basiscodierung kann auch in neuen Anwendungen verwendet werden, für die keine Legacy-Einschränkungen gelten. einfach, weil es möglich ist, Objekte mit Texteditoren zu bearbeiten.

In der Vergangenheit hatten unterschiedliche Anwendungen unterschiedliche Anforderungen und implementierten daher manchmal Basiscodierungen auf leicht unterschiedliche Weise. Heutzutage verwenden Protokollspezifikationen manchmal Basiscodierungen im Allgemeinen und "base64" im Besonderen ohne genaue Beschreibung oder Referenz. MIME (Multipurpose Internet Mail Extensions) [4] wird häufig als Referenz für base64 verwendet, ohne die Konsequenzen für Zeilenumbrüche oder Nicht-Alphabet-Zeichen zu berücksichtigen. Der Zweck dieser Spezifikation besteht darin, allgemeine Überlegungen zum Alphabet und zur Codierung festzulegen. Dies wird hoffentlich die Mehrdeutigkeit in anderen Dokumenten verringern und zu einer besseren Interoperabilität führen.

Base64 wurde ursprünglich entwickelt, um das Anhängen von Binärdaten an E-Mails als Teil der Mehrzweck-Internet-Mail-Erweiterungen zu ermöglichen.


26

Medien, die für Textdaten entwickelt wurden, sind natürlich letztendlich auch binär, aber Textmedien verwenden häufig bestimmte Binärwerte für Steuerzeichen. Außerdem können Textmedien bestimmte Binärwerte als Nicht-Text ablehnen.

Die Base64-Codierung codiert Binärdaten als Werte, die nur als Text in Textmedien interpretiert werden können, und ist frei von Sonderzeichen und / oder Steuerzeichen, sodass die Daten auch über Textmedien hinweg erhalten bleiben.


So wie bei Base64 interpretieren meistens sowohl die Quelle als auch das Ziel die Daten auf dieselbe Weise, da sie diese 64 Zeichen höchstwahrscheinlich auf dieselbe Weise interpretieren, selbst wenn sie die Steuerzeichen auf unterschiedliche Weise interpretieren. Ist das richtig?
Lazer

6
Diese Daten können sogar während des Transports zerstört werden. Beispielsweise schreiben viele FTP-Programme Zeilenenden von 13,10 auf 10 oder umgekehrt um, wenn das Betriebssystem von Server und Client nicht übereinstimmt und die Übertragung als Textmodus gekennzeichnet ist. FTP ist nur das erste Beispiel, das mir in den Sinn gekommen ist. Es ist kein gutes Beispiel, da FTP einen Binärmodus unterstützt.
Hendrik Brummermann

@nhnb: Ich denke, FTP ist ein gutes Beispiel, da es zeigt, dass der Textmodus für Dinge ungeeignet ist, die Binärdaten wollen.
Jamesdlin

Was ist ein Textmedium?
Koray Tugay

18

Es ist mehr so, dass das Medium die Zeichenfolgencodierung validiert , daher möchten wir sicherstellen, dass die Daten von einer Handhabungsanwendung akzeptiert werden (und keine binäre Sequenz enthalten, die beispielsweise EOL darstellt).

Stellen Sie sich vor, Sie möchten Binärdaten in einer E-Mail mit UTF-8-Codierung senden. - Die E-Mail wird möglicherweise nicht richtig angezeigt, wenn der Strom von Einsen und Nullen eine Sequenz erstellt, die in UTF-8-Codierung keinen gültigen Unicode enthält.

Das Gleiche passiert in URLs, wenn wir Zeichen codieren möchten, die für eine URL in der URL selbst nicht gültig sind:

http://www.foo.com/hello mein Freund -> http://www.foo.com/hello%20my%20friend

Dies liegt daran, dass wir einen Raum über ein System senden möchten, das den Raum für stinkend hält.

Wir stellen lediglich sicher, dass eine 1: 1-Zuordnung zwischen einer bekannten guten, akzeptablen und nicht schädlichen Folge von Bits zu einer anderen wörtlichen Folge von Bits besteht und dass die Handhabungsanwendung die Codierung nicht unterscheidet .

In Ihrem Beispiel ist manmöglicherweise ASCII in der ersten Form gültig. Oft möchten Sie jedoch Werte übertragen, die zufällig binär sind (dh ein Bild in einer E-Mail senden):

MIME-Version: 1.0
Inhaltsbeschreibung: "Base64-Codierung von a.gif"
Inhaltstyp: image / gif; name = "a.gif"
Content-Transfer-Codierung: Base64
Content-Disposition: Anhang; Dateiname = "a.gif"

Hier sehen wir, dass ein GIF-Bild in base64 als Teil einer E-Mail codiert ist. Der E-Mail-Client liest die Header und dekodiert sie. Aufgrund der Codierung können wir sicher sein, dass das GIF nichts enthält, was als Protokoll interpretiert werden könnte, und wir vermeiden das Einfügen von Daten, die SMTP oder POP möglicherweise als signifikant erachten.


1
Das ist großartig - diese Erklärung hat es zum Klicken gebracht. Es geht nicht darum, Daten zu verschleiern oder zu komprimieren, sondern lediglich darum, die Verwendung spezieller Sequenzen zu vermeiden, die als Protokoll interpretiert werden können.
Patrick Michaelsen

13

Base64 anstatt Sonderzeichen zu entkommen

Ich gebe Ihnen ein ganz anderes, aber reales Beispiel: Ich schreibe Javascript-Code, der in einem Browser ausgeführt werden soll. HTML-Tags haben ID-Werte, es gibt jedoch Einschränkungen hinsichtlich der Gültigkeit von Zeichen in einer ID.

Ich möchte jedoch, dass meine ID verlustfrei auf Dateien in meinem Dateisystem verweist. Dateien in der Realität können alle möglichen seltsamen und wunderbaren Zeichen enthalten, von Ausrufezeichen über Zeichen mit Akzent bis hin zu Tilde und sogar Emoji! Ich kann das nicht tun:

<div id="/path/to/my_strangely_named_file!@().jpg">
    <img src="http://myserver.com/path/to/my_strangely_named_file!@().jpg">
    Here's a pic I took in Moscow.
</div>

Angenommen, ich möchte einen Code wie diesen ausführen:

# ERROR
document.getElementById("/path/to/my_strangely_named_file!@().jpg");

Ich denke, dieser Code wird bei der Ausführung fehlschlagen.

Mit Base64 kann ich mich auf etwas Kompliziertes beziehen, ohne mir Gedanken darüber zu machen, welche Sprache welche Sonderzeichen zulässt und welche entkommen müssen:

document.getElementById("18GerPD8fY4iTbNpC9hHNXNHyrDMampPLA");

Im Gegensatz zur Verwendung eines MD5 oder einer anderen Hashing-Funktion können Sie die Codierung umkehren, um herauszufinden, welche Daten genau tatsächlich nützlich waren.

Ich wünschte, ich wüsste vor Jahren von Base64. Ich hätte es vermieden, mir mit ' encodeURIComponent' und die Haare auszureißenstr.replace(‘\n’,’\\n’)

SSH-Übertragung von Text:

Wenn Sie versuchen, komplexe Daten über ssh zu übertragen (z. B. eine Punktdatei, damit Sie Ihre Shell-Personalisierungen erhalten können), viel Glück ohne Base 64. So würden Sie es mit Base 64 machen (ich weiß, dass Sie SCP verwenden können, Dies würde jedoch mehrere Befehle erfordern - was die Schlüsselbindungen für das Sshing in einen Server erschwert):


12

Ein Beispiel dafür, wann ich es praktisch fand, war der Versuch, Binärdaten in XML einzubetten . Einige der Binärdaten wurden vom SAX-Parser falsch interpretiert, da diese Daten buchstäblich alles sein können, einschließlich XML-Sonderzeichen. Base64, das die Daten auf der sendenden Seite codiert und auf der empfangenden Seite decodiert, hat dieses Problem behoben.


1
+1 - aber dies ist keineswegs SAX-spezifisch. Dies würde jedem XML-Parser passieren, dh DOM oder XLINQ.
Billy ONeal

1
@ Billy: Ja, absolut. Ich habe gerade einen SAX-Parser für diese Anwendung verwendet.
Bill the Lizard

Verschiedene Engines, beispielsweise der SAX-Parser, interpretieren möglicherweise einige der ASCII-Werte auf unterschiedliche Weise (unterschiedliche Steuerzeichen). Die Idee hier ist also, die Teilmenge von ASCII zu verwenden, die allgemein die gemeinsame Bedeutung hat. Richtig?
Lazer

1
@Lazer: Richtig. Nicht codierte Binärdaten enthalten nur zufällig Steuerzeichen, wenn Sie versuchen, sie als ASCII zu interpretieren (was in diesem Fall nicht der Fall war).
Bill the Lizard

10

Die meisten Computer speichern Daten im 8-Bit-Binärformat, dies ist jedoch keine Voraussetzung. Einige Maschinen und Übertragungsmedien können jeweils nur 7 Bit (oder sogar weniger) verarbeiten. Ein solches Medium würde den Stream in Vielfachen von 7 Bit interpretieren. Wenn Sie also 8-Bit-Daten senden, erhalten Sie auf der anderen Seite nicht das, was Sie erwarten. Base-64 ist nur eine Möglichkeit, dieses Problem zu lösen: Sie codieren die Eingabe in ein 6-Bit-Format, senden sie über Ihr Medium und decodieren sie auf der Empfangsseite zurück in das 8-Bit-Format.


3
Warum ist es ein Problem, wenn der Stream nach 7 Bits unterbricht? Am Ende hat der andere Computer alle Daten über den Stream empfangen, kann er dann 8-Bit-Format für die Anzeige wählen? Was ist los mit meinem Verstand!
Mallaudin

6

Zusätzlich zu den anderen (etwas langwierigen) Antworten: Selbst wenn alte Systeme ignoriert werden, die nur 7-Bit-ASCII unterstützen, sind grundlegende Probleme bei der Bereitstellung von Binärdaten im Textmodus:

  • Zeilenumbrüche werden normalerweise im Textmodus transformiert.
  • Man muss darauf achten, ein NUL-Byte nicht als das Ende einer Textzeichenfolge zu behandeln, was in jedem Programm mit C-Abstammung allzu einfach ist.

Es gibt auch Steuerzeichen wie ^ C, ^ D und ^ Z, die auf einigen Plattformen als Dateiende interpretiert werden.
Dan04

5

Was bedeutet "Medien, die für den Umgang mit Textdaten ausgelegt sind"?

Diese Protokolle wurden entwickelt, um Text (oft nur englischen Text) anstelle von Binärdaten (wie PNG- und JPG-Bilder) zu verarbeiten.

Sie können mit Binär umgehen => sie können mit allem umgehen.

Aber das Gegenteil ist nicht wahr. Ein Protokoll zur Darstellung von Text behandelt möglicherweise Binärdaten, die Folgendes enthalten:

  • Die Bytes 0x0A und 0x0D, die für Zeilenenden verwendet werden, die sich je nach Plattform unterscheiden.
  • Andere Steuerzeichen wie 0x00 (NULL = C-String-Terminator), 0x03 (ENDE DES TEXTES), 0x04 (ENDE DER ÜBERTRAGUNG) oder 0x1A (DOS-Dateiende), die möglicherweise das Ende der Daten vorzeitig signalisieren.
  • Bytes über 0x7F (wenn das Protokoll für ASCII entwickelt wurde).
  • Byte-Sequenzen, die ungültig sind UTF-8.

Sie können also nicht einfach Binärdaten über ein textbasiertes Protokoll senden. Sie sind auf die Bytes beschränkt, die die Nicht-Leerzeichen-Nicht-Kontroll-ASCII-Zeichen darstellen, von denen es 94 gibt. Der Grund, warum Base 64 ausgewählt wurde, war, dass es schneller ist, mit Zweierpotenzen zu arbeiten, und 64 ist das größte, das funktioniert .

Eine Frage allerdings. Wie ist es, dass sich Systeme immer noch nicht auf eine gemeinsame Codierungstechnik wie die so übliche UTF-8 einigen?

Zumindest im Web haben sie meistens. Die meisten Websites verwenden UTF-8 .

Das Problem im Westen ist, dass es eine Menge alter Software gibt, die 1 Byte = 1 Zeichen annimmt und nicht mit UTF-8 funktioniert.

Das Problem im Osten ist ihre Bindung an Codierungen wie GB2312 und Shift_JIS.

Und die Tatsache, dass Microsoft immer noch nicht darüber hinweggekommen zu sein scheint, die falsche UTF-Codierung ausgewählt zu haben. Wenn Sie die Windows-API oder die Microsoft C-Laufzeitbibliothek verwenden möchten, sind Sie auf UTF-16 oder die "ANSI" -Codierung des Gebietsschemas beschränkt. Dies macht es schmerzhaft, UTF-8 zu verwenden, da Sie ständig konvertieren müssen.


5

Warum / Wie verwenden wir die Base64-Codierung?

Base64 ist eines der Binär-Text-Codierungsschemata mit einer Effizienz von 75%. Es wird verwendet, damit typische Binärdaten (wie Bilder) sicher über ältere "nicht 8-Bit-Clean" -Kanäle gesendet werden können. In früheren E-Mail-Netzwerken (bis Anfang der neunziger Jahre) waren die meisten E-Mail-Nachrichten Klartext im 7-Bit-US-ASCII-Zeichensatz. So viele frühe Kommunikationsprotokollstandards wurden entwickelt, um über "7-Bit" -Kommunikationsverbindungen "nicht 8-Bit-sauber" zu arbeiten. Die Schemaeffizienz ist das Verhältnis zwischen der Anzahl der Bits in der Eingabe und der Anzahl der Bits in der codierten Ausgabe. Hexadezimal (Base16) ist auch eines der Binär-Text-Codierungsschemata mit einer Effizienz von 50%.

Base64-Codierungsschritte (vereinfacht):

  1. Binärdaten sind in fortlaufenden Blöcken von jeweils 24 Bit (3 Byte) angeordnet.
  2. Jeder 24-Bit-Block ist in vier Teile zu je 6 Bit gruppiert.
  3. Jede 6-Bit-Gruppe wird in ihre entsprechenden Base64-Zeichenwerte konvertiert, dh die Base64-Codierung konvertiert drei Oktette in vier codierte Zeichen. Das Verhältnis von Ausgangsbytes zu Eingangsbytes beträgt 4: 3 (33% Overhead).
  4. Interessanterweise werden dieselben Zeichen je nach ihrer Position innerhalb der Drei-Oktett-Gruppe, die zur Erzeugung der vier Zeichen codiert wird, unterschiedlich codiert.
  5. Der Empfänger muss diesen Vorgang umkehren, um die ursprüngliche Nachricht wiederherzustellen.

3

Was bedeutet "Medien, die für den Umgang mit Textdaten ausgelegt sind"?

Damals, als ASCII die Welt regierte, war der Umgang mit Nicht-ASCII-Werten ein Problem. Die Leute sprangen durch alle möglichen Reifen, um diese über den Draht zu übertragen, ohne Informationen zu verlieren.


3
Früher wurde ASCII nicht überall verwendet. Viele Protokolle hatten einen separaten Text- und Binärmodus für die Datenübertragung, E-Mails damals leider nicht. Der Textmodus ist genau deshalb notwendig, weil keine einzige Textcodierung die Welt beherrschte, nicht ASCII; Jedes Computernetzwerk hat seine eigene Lieblingscodierung. Daher gibt es Gateways, deren Aufgabe es ist, den ausgetauschten Text in die lokale Codierung umzuwandeln, damit ein japanisches Unternehmen ohne Mojibake E-Mails an einen amerikanischen Unternehmensberater senden kann. Diese Konvertierung ist offensichtlich beim Senden von Binärdaten unerwünscht.
Lie Ryan
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.