Sujet : encoding
-
Variantes de base64 : alphabets standard et URL-safe, règles de padding et tolérance des décodeurs
La RFC 4648 définit les alphabets base64 standard et URL-safe et impose le padding par défaut, mais les JWT l'omettent explicitement ; MIME coupe les lignes à 76 caractères, tandis que le base64 de GNU fait de même tant qu'on ne lui passe pas -w0 ; enfin, les décodeurs, de Python au navigateur, ne s'accordent pas sur le fait de traiter comme des erreurs les caractères parasites et l'absence de padding.
-
Fins de ligne, encodages et chemins : ce qui casse quand un fichier change de système d'exploitation
CRLF contre LF, encodages par défaut incohérents de Windows PowerShell 5.1 face à l'UTF-8 sans BOM de PowerShell 7, EBCDIC sur les systèmes de la famille des mainframes IBM, et systèmes de fichiers qui divergent sur la sensibilité à la casse et la longueur maximale des chemins : une liste de points à vérifier avant de supposer qu'un fichier texte ou un chemin se comporte de la même façon sur un autre OS.
-
Accéder aux datasets z/OS depuis le shell UNIX : notation //'HLQ.NAME', tsocmd et balises d'encodage
Depuis un shell z/OS UNIX, les datasets classiques s'adressent avec la notation //'HLQ.DATA.SET', comprise par cp et d'autres utilitaires USS, ou en exécutant directement une commande TSO avec tsocmd. Les fichiers texte échangés entre datasets EBCDIC et fichiers USS ASCII exigent un marquage explicite via chtag ou le paramètre _BPXK_AUTOCVT ; sinon ils arrivent corrompus, et pas seulement mal affichés.
Lisible par machine : JSON