Hexadezimal -Schreibweise

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Hallo zusamnen,

    ich bringe noch was von vor 40 Jahren bei Y-Tours.

    Wir hatten damals Sprechfunk- und Tastfunk-Übungen von einem anderen Verein aus dem Ausland entschlüsselt. Und die Erkenntnisse in einem speziell codierten Datenformat (was das Zeugs dazu gehabt haben könnte, zu einer Programmiersprache aufzusteigen) auf Fernschreibern eingeklimpert und auf Lochstreifen archiviert.

    Die 50- und 75-Baudot-Kisten waren sooooo seeeehr langsam, dass wir angehalten waren, nach einem ZV (Zeilenvorschub) nicht nur einen sondern 2 WR (Wagenrücklauf) zu codieren, damit die Mechanik auch die linke Spalte erreicht, und nicht das nächste Zeichen während des Wagenrücklaufes irgendwo auf dem Weg verliert.

    Ja, wir konnten den Lochcode sogar "lesen".

    Schade ist, dass die Bedeutung der meisten Steuercodes (\x00 ... \x1F) kaum noch bekannt sind geschweige denn umgesetzt werden. Stattdessen werden weitere Protokolle erfunden, was früher ein ACK (\x06) bestätigte oder ein NAK (\x15) ablehnte.

    Als Hinweis auf eine Störung setzte man ein \x06 ab (BEL), wodurch eine Glocke läutete oder ein akustisches Signal abgesetzt wurde.

    ...

    Beste Grüße

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

  • jar Also aus meiner Sicht ist das ja eine DOS/Windows-Besonderheit. Von C64 & Apple DOS/ProDOS/Macintosh kenne ich CR als Zeichen, und von Linux LF. Etwas exotisch, aber auch 1 Byte sind Atari's mit Bytewert 155 als Zeilenende. Bei zeilenorientierten Druckern kann man üblicherweise einstellen was bei CR passiert, also ob das nur den Wagenrücklauf macht, oder noch einen Zeilenvorschub dazu.

    “Dawn, n.: The time when men of reason go to bed.” — Ambrose Bierce, “The Devil's Dictionary”

  • hehe, ich hab ja alle Müllkalender der Stadt heruntergeladen und wie gewohnt mit bash pip es zerpflückt, bis ich gemerkt hab, da sind ja Windows Zeilenende drin.

    Man muss einfach Python lobend erwähnen, es hat es, mit windows oder linux Zeilenende gerendert :)

    Aber dos2unix war mir am Ende zu aufwendig die Man Page zu lesen :)

  • newline controls how universal newlines mode works (it only applies to text mode). It can be None, '', '\n', '\r', and '\r\n'. It works as follows:

    • When reading input from the stream, if newline is None, universal newlines mode is enabled. Lines in the input can end in '\n', '\r', or '\r\n', and these are translated into '\n' before being returned to the caller. If it is '', universal newlines mode is enabled, but line endings are returned to the caller untranslated. If it has any of the other legal values, input lines are only terminated by the given string, and the line ending is returned to the caller untranslated.
    • When writing output to the stream, if newline is None, any '\n' characters written are translated to the system default line separator, os.linesep. If newline is '' or '\n', no translation takes place. If newline is any of the other legal values, any '\n' characters written are translated to the given string.

    universal newlines

    A manner of interpreting text streams in which all of the following are recognized as ending a line: the Unix end-of-line convention '\n', the Windows convention '\r\n', and the old Macintosh convention '\r'. See PEP 278 and PEP 3116, as well as bytes.splitlines() for an additional use.

    Wenn man Dateien lesend im Textmodus öffnet und newline=None ist (Standard), werden die Zeilenenden \n, \r, \r\n in \n übersetzt. Das erleichtert die Handhabung von Zeilenenden Betriebssystemübergreifend im Quellcode.

    Wenn man die Datei schreibend im Textmodus öffnet und die Angabe von newline auslässt (newline=None), wird \n in os.linesep übersetzt und os.linesep ist vom Betriebssystem abhängig.

    linesep ist übrigens die Abkürzung für line sparator (Zeilentrennzeichen).

    Linux: \n

    MacOS: \n

    MacOS Classic: \r

    Windows: \r\n

    D.h. folgender Code erzeugt unter Windows, Mac und Linux Dateien mit gültigen Zeilenenden für das jeweilige Betriebssystem, dass aktuell genutzt wird:

    Code
    with open("foo.txt", "w") as fd:
        fd.write("Hello\nWorld\n")

    Unter Windows kommt eine Textdatei bei raus, in der \r\n als Zeilenende verwendet wird.

    Unter Mac und Linux bleibt das \n als Zeilentrennzeichen.

    Mir ist es letzendlich egal von wo eine Textdatei kommt. Das Zeilende wird automatisch übersetzt und wenn man das nicht braucht oder will, kann man newline="" setzen (leerer String). In diesem Fall wird das Zeilentrennzeichen nicht übersetzt.

    Das Tool dos2unix braucht man wenn man reguläre Textdateien von Windows nach Linux/Mac oder umgekehrt übersetzen will.

    Wenn man die Datei mit Python öffnet, braucht man das nicht.

    Andere Sprachen werden sicherlich auch Methoden haben, um die Kopfschmerzen weitestgehend zu reduzieren, wenn man Betriessystemübergreifend arbeiten muss. Zeilenende ist eine Sache. Oben drauf kommt noch das Encoding. Ein Text kann in ASCII encodiert sein oder z.B. mit utf8, utf16 mit bom ohne bom, latin1 usw..

    PS: Scheint auch im C-Standard zu sein:

    The C programming language provides the escape sequences '\n' (newline) and '\r' (carriage return). However, these are not required to be equivalent to the ASCII LF and CR control characters. The C standard only guarantees two things:

    1. Each of these escape sequences maps to a unique implementation-defined number that can be stored in a single char value.
    2. When writing to a file, device node, or socket/fifo in text mode, '\n' is transparently translated to the native newline sequence used by the system, which may be longer than one character. When reading in text mode, the native newline sequence is translated back to '\n'. In binary mode, no translation is performed, and the internal representation produced by '\n' is output directly.

    Also keine Besonderheit von Python.

    Einmal editiert, zuletzt von RestlessMud46765 (24. April 2021 um 21:56)

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!