Binary to Text

Konvertierung zwischen rohen Bits und lesbarem Text

1. Wähle eine Richtung mit den Modus-Tabs: "Text → Binär" kodiert deine eingegebenen Zeichen zu 0/1-Ziffern; "Binär → Text" kehrt den Vorgang um.
2. Füge deine Eingabe ein oder tippe sie in das Eingabefeld. Im Textmodus wird jedes Unicode-Zeichen akzeptiert (Emoji, CJK, RTL). Im Binärmodus füge eine Folge von 0en und 1en ein, optional durch Leerzeichen getrennt; andere Zeichen werden entfernt.
3. Schalte "Leerzeichengetrennte Bytes" um, um ein Leerzeichen zwischen jedem Byte-Chunk einzufügen (oder zu verlangen). So werden die meisten akademischen und Lehrbuchbeispiele formatiert (01001000 01101001).
4. Schalte "8-Bit-Auffüllung" um, um das Binär jedes Zeichens auf genau 8 Bit aufzufüllen. Das Ausschalten erzeugt variable Breite für ASCII-Bereichszeichen (7 Bit), was Platz spart, aber die Mehrbyte-Kompatibilität bricht.
5. Lies die Ausgabe, die live beim Tippen aktualisiert wird. Es ist kein Klicken einer Schaltfläche erforderlich - die Transformation läuft bei jedem Tastenanschlag über den onInput-Handler. Klicke die Kopierschaltfläche, um die Ausgabe in die Zwischenablage zu legen.

Unicode-Codepunkte, UTF-8-Bytes und warum sie sich unterscheiden

Der Text-zu-Binär-Pfad ruft codePointAt(0).toString(2) für jedes Zeichen auf. Das unterscheidet sich subtil von UTF-8: Es erzeugt den rohen Unicode-Skalarwert, sodass "A" (U+0041) zu 01000001 wird und das Emoji "😀" (U+1F600) ein 17-Bit-Wert wird. Echtes UTF-8 würde dieses Emoji als 4 Bytes kodieren. Die Darstellung dieses Werkzeugs ist näher an UCS-2-Code-Units als an Wire-Format-UTF-8, gut für Lehr-Demos und passend zu den meisten "Binär-zu-Text"-Werkzeugen. Für die eigentliche UTF-8-Byte-Ausgabe (Netzwerkprotokoll-Debugging) führe zuerst durch new TextEncoder().encode(str) - den Pfad, den die Hashing- und HMAC-Werkzeuge auf dieser Seite verwenden. Das Dekodieren kehrt den Vorgang um: in Blöcke aufteilen, parseInt(chunk, 2), String.fromCodePoint.

Wann du dieses Werkzeug tatsächlich benötigst

• CTF-Aufgaben (Capture The Flag) lösen, bei denen die Flagge als Binärziffern in einem Bild oder einer Textdatei versteckt ist.
• Einem Studenten erklären, wie ASCII oder Unicode Zeichen auf Zahlen abbildet - das Umschalten der 8-Bit-Auffüllung zeigt die mit Nullen aufgefüllten Byte-Grenzen, die im Speicherlayout wichtig sind.
• Ein Protokoll debuggen, bei dem Bytes als Einsen und Nullen protokolliert werden (selten in modernen Stacks, aber häufig in Legacy-Telekommunikation oder RS-232-Serien-Dumps).
• Eine Rätsel- oder Rätselinhalt vorbereiten: einen Satz kodieren, den Binär-String senden, der Empfänger dekodiert ihn mit demselben Werkzeug.
• Überprüfen, ob eine Bitmanipulationsfunktion in deinem Code das erwartete Binär für ein bekanntes Eingabezeichen erzeugt.
• Einen Binär-String aus einem Eingebetteten-Systeme-Datenblatt-Beispiel in menschenlesbaren Text umwandeln, um zu überprüfen, ob du die Kodierung verstanden hast.

Fallstricke beim Hin-und-Rück-Reisen durch Binär

Der häufigste Fehler sind nicht übereinstimmende Auffüllungseinstellungen zwischen Kodierung und Dekodierung. Wenn du "Hi" mit eingeschalteter 8-Bit-Auffüllung kodierst, erhältst du 0100100001101001; wenn du denselben String mit ausgeschalteter Auffüllung (7-Bit-Blöcke erwartet) dekodierst, teilt das Werkzeug ihn als 0100100 0011010 01 auf und erzeugt Unsinn. Beide Seiten müssen sich auf die Blockgröße einigen. Zweitens belegen Nicht-BMP-Unicode-Zeichen (Emoji, CJK-Erweiterungen) zwei UTF-16-Code-Units oder einen einzigen Codepunkt über U+FFFF; dieses Werkzeug liest [...text], was nach Codepunkt iteriert, sodass Emoji korrekt hin-und-zurück-kodiert werden, aber eine handgeschriebene Schleife mit text[i] würde ein Surrogatpaar aufteilen und fehlerhafte Ausgabe erzeugen. Drittens verwirft der Binär-zu-Text-Pfad silent Nicht-01-Zeichen über .replace(/[^01\\s]/g, ''), was nachsichtig, aber bedeutet, dass ein Tippfehler wie "01001oo01" ohne Beschwerde zu "0100101" bereinigt wird. Viertens wird ein Block, der Codepunkt 0 (ein Null-Zeichen) repräsentiert, aus der Ausgabe verworfen, um die Anzeige mit unsichtbaren Nullen zu vermeiden; das ist eine absichtliche Abweichung vom strikten verlustfreien Hin-und-Zurück-Reisen.

Die breitere Binär-zu-Text-Kodierungslandschaft

Reines Binär ist pädagogisch, aber ineffizient - 8 Zeichen pro Byte. Echte Protokolle verwenden dichtere Kodierungen. Base64 (RFC 4648 Abschnitt 4) packt 3 Bytes in 4 Zeichen mit A-Z, a-z, 0-9, +, /; URL-sicheres Base64 (Abschnitt 5) tauscht + und / gegen - und _ aus. Base32 (Abschnitt 6) verwendet A-Z plus 2-7, ohne Beachtung von Groß-/Kleinschreibung und ohne 0/O/1/I-Verwechslung - verwendet für TOTP-Geheimnisse und BIP-39. Ascii85 (PDF-Streams) packt 4 Bytes in 5 Zeichen für 25 Prozent bessere Dichte als Base64. Z85 ist eine URL-sichere Ascii85-Variante. Quoted-Printable (RFC 2045) kodiert nur Nicht-ASCII als =XX-Hex, sodass der meiste E-Mail-Text lesbar bleibt. Hexadezimal ist Basis 16. Jedes tauscht Dichte gegen Alphabet-Sicherheit.

Binär vs. Base64, xxd und System-Werkzeuge

Unter Unix erzeugt echo "Hi" | xxd -b die Binärdarstellung jedes Bytes (00101001 01001000 01101001...) und ist das nächste CLI-Äquivalent. xxd ohne Flags gibt Hex aus; base64 dateiname erzeugt Base64; od -An -tb dateiname erzeugt oktales Binär. All diese verarbeiten beliebig große Dateien und streamen von der Festplatte. Der Vorteil dieses Werkzeugs ist die interaktive Live-Vorschau und das Ausführen in einem Browser-Tab. Sein Nachteil ist konzeptionell: Das Text-zu-Binär hier bildet auf Codepunkte ab, nicht auf Wire-Format-UTF-8-Bytes, sodass ein byte-genaues Debug-Dump xxd -b oder ein ähnliches natives Werkzeug verwenden sollte. Für echte UTF-8-Bytes verwende die Hash-Generator-Werkzeuge auf dieser Seite (die Text vor dem Hashing in UTF-8 kodieren) oder verwende new TextEncoder().encode(str) in Nodes REPL. Die eigenen Base64-, Base32- und URL-Encoder-Werkzeuge auf dieser Seite decken die anderen Einträge in der Kodierungslandschaft ab.