PEM-Base64-Encoder

Privacy-Enhanced Mail (PEM) ist die Text-Hülle, in der fast jedes Zertifikat, jeder private Schlüssel und jeder öffentliche Schlüssel noch unterwegs ist: eine Base64-Nutzlast, gefaltet in Zeilen von vierundsechzig Zeichen zwischen passenden -----BEGIN LABEL----- und -----END LABEL----- Markern. Entwickler fügen diese Blöcke in Konfigurationen, CI-Secrets, Kubernetes-TLS-Secrets und ACME-Logs ein; Support-Ingenieure wickeln einen durchgehenden Base64-Blob neu, damit OpenSSL ihn akzeptiert; Lehrkräfte zeigen, wie sich ein CERTIFICATE-Header von PRIVATE KEY unterscheidet, ohne ein volles Krypto-Toolkit zu installieren.

Text in einen PEM-Block mit 64-Zeichen-Zeilen kodieren

Wenn label weggelassen wird, verwendet die Engine CERTIFICATE, was der häufigsten Suchintention für Zertifikat-Einfügungen entspricht; weitere gängige Labels sind PRIVATE KEY, RSA PRIVATE KEY, PUBLIC KEY und CERTIFICATE REQUEST. Die Engine serialisiert den String als UTF-8-Bytes, mappt diese Bytes auf das Standard-Base64-Alphabet mit Gleichheitszeichen-Padding, faltet das durchgehende Base64 in Zeilen von genau vierundsechzig Zeichen mit einer kürzeren letzten Zeile bei Bedarf und wickelt den Body zwischen -----BEGIN LABEL----- und -----END LABEL----- mit demselben Label auf beiden Seiten.

Leere Nutzlasten sind erlaubt: Sie erhalten weiterhin ein wohlgeformtes PEM mit leerem Body und passenden Headern, nützlich zum Testen von Parsern. Mehrsprachiger Text und Interpunktion runden ab, weil der Pfad volles UTF-8 ist, kein Latin-1-Shortcut.

Einen PEM-Block dekodieren und ungültige Eingabe sicher behandeln

Setzen Sie mode auf decode und legen Sie einen vollständigen PEM-Block in text ab, einschließlich der BEGIN- und END-Zeilen. Führender und abschließender Leerraum um den Block wird toleriert, damit mehrzeilige Einfügungen aus Tickets und Dokumentation weiterhin funktionieren. Die Engine findet den ersten -----BEGIN LABEL----- Header, liest das Label, findet den passenden -----END LABEL----- Footer und lehnt die Anfrage ab, wenn der Footer fehlt, wenn das END-Label nicht dem BEGIN-Label entspricht oder wenn eine unerwartete Kapselungsgrenze im Body erscheint.

Body-Zeilen werden getrimmt und verbunden; Leerzeichen, Tabs und Zeilenumbrüche in der Base64-Region werden entfernt, danach wird das durchgehende Alphabet mit denselben Regeln wie Standard-Base64 validiert: illegale Zeichen, Pads in der Mitte, mehr als zwei Padding-Gleichheitszeichen oder eine Länge, deren Modulo vier eins ist, scheitern mit einer expliziten Meldung. Bevorzugen Sie diese Fähigkeit, wenn die Suchintention PEM-Framing ist—Header plus vierundsechzig-Zeichen-Zeilen—statt rohem Base64 ohne Kapselung oder URL-sicheren Cookie-Alphabeten, die zu Geschwister-Encodern gehören.

Wofür PEM-Blöcke im Alltag dienen

Nutzen Sie das kostenlose PEM-Base64-Werkzeug im Browser für Unterrichtsdemos, Support-Playbooks und einmaliges Neuwickeln einer Zertifikat-Einfügung ohne OpenSSL-Installation. Ein typischer Workflow kodiert ein kurzes Konfigurationsgeheimnis als gelabeltes PEM zur Ablage in einem Ticket-System und dekodiert es auf dem empfangenden Dienst mit mode decode und prüft, dass bytes und label dem Original entsprechen.

Ein anderer Workflow normalisiert einen durchgehenden Base64-Zertifikatskörper, der ohne Zeilenumbrüche ankam: encode ist nicht nötig, wenn Sie bereits PEM haben, aber decode akzeptiert gefaltete oder ungefaltete Bodies, solange BEGIN- und END-Header vorhanden sind, und Sie können nach Inspektion von result erneut kodieren, wenn Sie wieder die kanonische Faltung mit vierundsechzig Zeichen brauchen. Kombinieren Sie diesen Endpunkt mit einfachen Base64-Werkzeugen, wenn eine Pipeline sowohl ungerahmte Token als auch PEM-gewickelte Schlüssel verarbeiten muss, halten Sie die Landings aber getrennt, damit jede Seite einer einzigen Suchintention entspricht—pem-base64-encoder versus text zu base64.