Tema: encoding
-
Variantes de base64: alfabetos estándar y URL-safe, reglas de relleno y rigurosidad de los decodificadores
RFC 4648 define los alfabetos base64 estándar y URL-safe y exige relleno por defecto, pero los JWT lo omiten de forma explícita. MIME divide las líneas a 76 caracteres y el base64 de GNU necesita -w0 para no hacerlo, y los decodificadores, de Python al navegador, discrepan sobre si los caracteres sobrantes o la falta de relleno son errores.
-
Finales de línea, codificaciones y rutas: qué se rompe cuando un archivo se mueve entre sistemas operativos
CRLF frente a LF, los valores predeterminados de codificación inconsistentes de Windows PowerShell 5.1 frente al UTF-8 sin BOM de PowerShell 7, EBCDIC en sistemas de la familia de mainframes de IBM, y sistemas de archivos que difieren en la sensibilidad a mayúsculas/minúsculas y en la longitud máxima de ruta: una lista de comprobación de qué verificar antes de asumir que un archivo de texto o una ruta se comportan igual en otro sistema operativo.
-
Acceso a datasets de z/OS desde el shell de UNIX: la notación //'HLQ.NAME', tsocmd y las etiquetas de codificación
Desde un shell de z/OS UNIX, los datasets clásicos se direccionan con la notación //'HLQ.DATA.SET', que entienden cp y otras utilidades de USS, o ejecutando un comando TSO directamente con tsocmd. Los archivos de texto que pasan entre datasets EBCDIC y archivos USS en ASCII requieren etiquetado explícito con chtag o el ajuste _BPXK_AUTOCVT; de lo contrario llegan corruptos, no solo con aspecto extraño.
Legible por máquina: JSON