Thema: encoding
-
Base64-Varianten: Standard- und URL-sichere Alphabete, Padding-Regeln und Strenge der Decoder
RFC 4648 definiert sowohl das Standard- als auch das URL-sichere Base64-Alphabet und verlangt standardmässig Padding. JWTs lassen es ausdrücklich weg, MIME bricht Zeilen nach 76 Zeichen um (GNU base64 tut dies ebenfalls, solange nicht -w0 gesetzt ist), und Decoder von Python bis zum Browser behandeln fremde Zeichen und fehlendes Padding unterschiedlich streng.
-
Zeilenenden, Kodierungen und Pfade: was schiefgeht, wenn eine Datei zwischen Betriebssystemen wechselt
CRLF gegenüber LF, die uneinheitlichen Kodierungs-Standardwerte von Windows PowerShell 5.1 gegenüber BOM-losem UTF-8 in PowerShell 7, EBCDIC auf Systemen der IBM-Mainframe-Familie sowie Dateisysteme mit unterschiedlicher Gross-/Kleinschreibung und maximaler Pfadlänge: eine Checkliste, was zu prüfen ist, bevor man annimmt, dass sich eine Textdatei oder ein Pfad auf einem anderen Betriebssystem gleich verhält.
-
z/OS-Datasets aus der UNIX-Shell erreichen: die Notation //'HLQ.NAME', tsocmd und Encoding-Tags
Aus einer z/OS-UNIX-Shell werden klassische Datasets mit der Notation //'HLQ.DATA.SET' angesprochen, die cp und andere USS-Utilities verstehen, oder indem ein TSO-Befehl direkt mit tsocmd ausgeführt wird. Textdateien, die zwischen EBCDIC-Datasets und ASCII-USS-Dateien wechseln, müssen explizit mit chtag oder über die Einstellung _BPXK_AUTOCVT getaggt werden, sonst kommen sie nicht bloss falsch dargestellt, sondern beschädigt an.
Maschinenlesbar: JSON