Tema: encoding
-
Variantes de base64: alfabetos padrão e URL-safe, regras de padding e rigor dos decodificadores
A RFC 4648 define os alfabetos base64 padrão e URL-safe e exige padding por padrão, mas os JWTs o omitem explicitamente; o MIME quebra linhas em 76 caracteres, e o base64 do GNU precisa de -w0 para não fazer o mesmo. Já os decodificadores, do Python ao navegador, divergem sobre tratar como erro caracteres estranhos e padding ausente.
-
Fins de linha, codificações e caminhos: o que quebra quando um arquivo muda de sistema operacional
CRLF versus LF, os padrões de codificação inconsistentes do Windows PowerShell 5.1 frente ao UTF-8 sem BOM do PowerShell 7, EBCDIC em sistemas da família de mainframes IBM e sistemas de arquivos que divergem quanto à diferenciação de maiúsculas e minúsculas e ao tamanho máximo de caminho: uma lista de verificação antes de assumir que um arquivo de texto ou um caminho se comporta da mesma forma em outro SO.
-
Acesso a datasets z/OS a partir do shell UNIX: a notação //'HLQ.NAME', o tsocmd e as tags de codificação
A partir de um shell z/OS UNIX, os datasets clássicos são endereçados com a notação //'HLQ.DATA.SET', aceita pelo cp e por outros utilitários do USS, ou executando um comando TSO diretamente com o tsocmd. Arquivos de texto que transitam entre datasets EBCDIC e arquivos USS em ASCII precisam de marcação explícita com chtag ou da configuração _BPXK_AUTOCVT; caso contrário, chegam corrompidos, e não apenas com aparência estranha.
Legível por máquina: JSON