Codificador PEM Base64

Privacy-Enhanced Mail (PEM) es el envoltorio de texto en el que casi todo certificado, clave privada y clave pública sigue viajando: un cuerpo Base64 plegado en líneas de sesenta y cuatro caracteres entre marcadores coincidentes -----BEGIN LABEL----- y -----END LABEL-----. Los desarrolladores pegan estos bloques en configuraciones, secretos de CI, secretos TLS de Kubernetes y registros ACME; el personal de soporte reenvuelve un blob Base64 continuo para que OpenSSL lo acepte; los formadores muestran cómo una cabecera CERTIFICATE se diferencia de PRIVATE KEY sin instalar un kit criptográfico completo.

Codifique texto en un bloque PEM con líneas de 64 caracteres

Si omite label, el motor usa CERTIFICATE, que coincide con la intención de búsqueda más habitual para pegados de certificados; otras etiquetas frecuentes son PRIVATE KEY, RSA PRIVATE KEY, PUBLIC KEY y CERTIFICATE REQUEST.

El motor serializa la cadena como bytes UTF-8, mapea esos bytes al alfabeto Base64 estándar con relleno de iguales, pliega el Base64 continuo en líneas de exactamente sesenta y cuatro caracteres (con una línea final más corta si hace falta) y envuelve el cuerpo entre -----BEGIN LABEL----- y -----END LABEL----- usando la misma etiqueta en ambos lados. Las cargas vacías son legales: obtiene un PEM bien formado con cuerpo vacío y cabeceras coincidentes, útil para probar analizadores.

El texto multilingüe y la puntuación dan ida y vuelta porque el camino es UTF-8 completo, no un atajo Latin-1.

Decodifique un bloque PEM y gestione la entrada no válida con seguridad

Fije mode en decode y coloque un bloque PEM completo en text, incluidas las líneas BEGIN y END. Se tolera el espacio en blanco inicial y final alrededor del bloque para que los pegados multilínea de tickets y documentación sigan funcionando. El motor localiza la primera cabecera -----BEGIN LABEL-----, lee la etiqueta, encuentra el pie -----END LABEL----- coincidente y rechaza la petición si falta el pie, si la etiqueta END no coincide con BEGIN, o si aparece un límite de encapsulación inesperado dentro del cuerpo.

Las líneas del cuerpo se recortan y se unen; se eliminan espacios, tabuladores y saltos de línea dentro de la región Base64, y luego se valida el alfabeto continuo con las mismas reglas del Base64 estándar: caracteres ilegales, rellenos en medio, más de dos signos de igual de relleno, o una longitud cuyo módulo cuatro sea uno fallan con un mensaje explícito.

Prefiera esta capacidad cuando la intención de búsqueda sea el encuadre PEM—cabeceras más líneas de sesenta y cuatro caracteres—y no el Base64 crudo sin encapsulación ni alfabetos URL-safe de cookies que pertenecen a codificadores hermanos.

Usos habituales de los bloques PEM y sus límites

Use la herramienta gratuita PEM Base64 en el navegador para demostraciones en clase, guías de soporte y reenvueltos puntuales de un certificado pegado sin instalar OpenSSL. Un flujo típico codifica un secreto corto de configuración como PEM etiquetado para almacenarlo en un sistema de tickets y luego lo decodifica en el servicio receptor con mode decode, afirmando que bytes y label coinciden con el original.

Otro flujo normaliza un cuerpo de certificado Base64 continuo que llegó sin saltos de línea: encode no es obligatorio si ya tiene PEM, pero decode acepta cuerpos plegados o sin plegar siempre que existan las cabeceras BEGIN y END, y puede volver a codificar tras inspeccionar result si necesita de nuevo el plegado canónico de sesenta y cuatro caracteres.

Combine este extremo con herramientas de Base64 plano cuando una canalización deba tratar tanto tokens sin marco como claves envueltas en PEM, pero mantenga las landings separadas para que cada página coincida con una sola intención de búsqueda—codificador pem base64 frente a texto a base64.