pl: Parameter Typisierung

0 103

Parameter Typisierung

pl
  • sonstiges
  • web
  1. 0
    Tabellenkalk
    1. 0
      pl
      1. 0
        pl
        1. 0
          dedlfix
          1. 0
            pl
            1. 2
              dedlfix
              1. 0
                Tabellenkalk
                1. 0
                  dedlfix
                  1. 0
                    Tabellenkalk
                    1. 0
                      dedlfix
                      1. 0
                        Tabellenkalk
                        1. 0
                          dedlfix
              2. 0
                MudGuard
                1. 0
                  dedlfix
              3. 0
                pl
                1. 1
                  dedlfix
                  1. 0
                    pl
                2. 3
                  klawischnigg
                  1. 0
                    pl
                  2. 0

                    Wittgenstein

                    pl
                    1. 0
                      klawischnigg
              4. 0
                pl
                1. 0
                  1unitedpower
                  1. 0
                    pl
                    1. 0
                      dedlfix
                      1. 0
                        pl
                        1. 1
                          dedlfix
                          1. -1
                            pl
                          2. 0
                            pl
                            1. 0
                              dedlfix
                              1. -1
                                pl
                                1. 0
                                  dedlfix
                                  1. 0
                                    pl
                                    1. 0
                                      Fritz
                                      1. -1
                                        pl
                                        • zu diesem forum
                              2. -1
                                pl
                                1. 0
                                  dedlfix
                                  1. -1
                                    pl
                              3. 0
                                pl
                  2. 0
                    pl
  2. -1
    pl
  3. 0

    Parameter Typisierung/ Zeitserver nach RFC 868

    pl
    1. -1
      pl
      1. 0
        1unitedpower
        1. 1
          pl
          1. 0
            1unitedpower
        2. 0
          pl
          1. 0
            1unitedpower
            1. 0
              pl
              1. 0
                1unitedpower
                1. 0
                  pl
            2. 0
              pl
              1. 1
                1unitedpower
            3. 0
              Matthias Apsel
  4. 0

    Warum Typisierung

    pl
    1. 0
      Matthias Apsel
      1. -1
        pl
      2. -2
        pl
      3. 0
        pl
        1. 0
          Robert B.
          • sonstiges
          1. 0
            pl
          2. 0
            pl
            1. 0
              Robert B.
              1. 0
                pl
                1. 0
                  Matthias Apsel
                  1. 0
                    pl
                2. 0
                  Robert B.
                  • sonstiges
                  • zeichencodierung
                  1. 0
                    pl
                  2. 0
                    pl
                    1. 0
                      Robert B.
                      1. 0
                        pl
                        1. 1
                          dedlfix
                          1. 0
                            pl
                            1. 1
                              dedlfix
                              1. -1
                                pl
                                1. 2
                                  dedlfix
                                  1. 0
                                    pl
                                    1. 1
                                      dedlfix
                                      1. -1
                                        pl
                                      2. 0
                                        pl
                                2. 1
                                  Matthias Apsel
                                  1. -1
                                    pl
                                    • zu diesem forum
                                    1. 3
                                      Tabellenkalk
                              2. 0
                                pl
    2. 6
      dedlfix
      1. -2
        pl
        1. 0
          dedlfix
          1. 0
            pl
            1. 0
              dedlfix
              1. 0
                Christian Kruse
                1. -1
                  pl
                  1. 2
                    Christian Kruse
                    1. 0
                      pl
                    2. 0
                      pl
                      1. 0
                        Christian Kruse
                        1. 0
                          pl
              2. -1
                pl
                1. 0
                  Mitleser
                  1. 0
                    pl
                    1. 0
                      Matthias Apsel
                      1. 0
                        pl
                        • zu diesem forum
                        1. 0
                          dedlfix

hi und siehe Thema,

kurzum: in welchen Fällen würde denn eine Typisierung von Parametern sinvoll sein? Mir fällt jetzt nur das Beispiel Alter ein was da ein unsigned integer (char) sein könnte, aber da gibt bestimmt noch mehr Fälle.

Bitte mal um Hinweise, MfG

  1. Hallo,

    kurzum: in welchen Fällen würde denn eine Typisierung von Parametern sinvoll sein? Mir fällt jetzt nur das Beispiel Alter ein was da ein unsigned integer (char) sein könnte, aber da gibt bestimmt noch mehr Fälle.

    Gewicht, Länge, Breite und Höhe als Abmessung kann ich mir grad auch nur schwer negativ vorstellen.

    Bitte mal um Hinweise, MfG

    Bitte mal mehr Kontext,

    Gruß
    Kalk

    1. Hallo,

      kurzum: in welchen Fällen würde denn eine Typisierung von Parametern sinvoll sein? Mir fällt jetzt nur das Beispiel Alter ein was da ein unsigned integer (char) sein könnte, aber da gibt bestimmt noch mehr Fälle.

      Gewicht, Länge, Breite und Höhe als Abmessung kann ich mir grad auch nur schwer negativ vorstellen.

      Bitte mal um Hinweise, MfG

      Bitte mal mehr Kontext,

      Gerne 😉

      Ich werde diese Demo noch um ein c-struct erweitern. D.h. um einen Datentyp char[255] welcher mit Nullen aufgefüllt wird was den string auch nullterminiert (wie in c üblich). Vorausgesetzt, es gibt eine Methode womit man das auch in JS machen kann: Einen Blob in einen ArrayBuffer setzen (was ich mal stark annehme daß das möglich ist).

      MfG

      1. problematische Seite

        Moin,

        Ich werde diese Demo noch um ein c-struct erweitern.

        Done Beim Testen zeigte sich, daß FF/Chrome mit nullterminierten Strings unterchiedlich umgehen, Chrome entfernt auch alle aufgefüllten Nullbytes. Aber darauf kommt es hier nicht an, vielmehr ist das eine weitere Demonstration dafür daß man Datentypen auch plattformübergreifend verwenden kann. Die in Perl üblichen Schablonen gibt es auch in PHP und in c bzw. JS dem entsprechende Datentypen.

        XML RPC Fachleute haben bestimmt noch viel mehr Beispiele welchen Nutzen eine plattformübergreifende Typisierung mit sich bringt. Über diesbezügliche Beispiele freute ich mich.

        MfG

        1. problematische Seite

          Tach!

          XML RPC Fachleute haben bestimmt noch viel mehr Beispiele welchen Nutzen eine plattformübergreifende Typisierung mit sich bringt. Über diesbezügliche Beispiele freute ich mich.

          Ich bin kein XML-RPC-Fachleut, aber ehrlich gesagt, sehe ich keinen Sinn darin, in den gegebenen Formaten (XML-RPC oder beispielsweise JSON) ein Problem zu sehen, oder anders gesagt sehe ich keinen Anwendungsfall für eine systemübergreifende Typisierung. Was nützt mir ein Typ, wenn das Zielsystem diesen nicht in unterstützt? Was nützt mir zum Beispiel ein uintXX in Javascript, wenn es da nur den Typ number gibt?

          XML-RPC definiert nur sehr allgemeine Typen und die jeweilgen Systeme können die Werte von und zu einem internen Format konvertieren, wie es für sie am besten geeignet ist. Ähnlich verfährt da JSON, nur dass es nicht primär als Austauschformat zwischen unterschiedlichen Systemen gedacht ist, sondern eher von und zu Javascript. Deswegen spielen da auch Binärdaten keine weitere Rolle, weil für die Verarbeitung in Javascript im Allgmeinen nicht sehr viel Bedarf besteht.

          Es ist auch für das Debugging nicht vorteilhaft, wenn da eine Binärwurst daherkommt, die ich erstmal mühsehlich auseinandernehmen muss, um die eigentlichen Werte zu erkennen. Bei der Kommunikation zwischen unterschiedlichen Systemen halte ich die Lesbarkeit für wesentlich wichtiger, als eine Typinformation, die auf dem Zielsystem nebensächlich bis irrelevant ist.

          dedlfix.

          1. problematische Seite

            Tach!

            XML RPC Fachleute haben bestimmt noch viel mehr Beispiele welchen Nutzen eine plattformübergreifende Typisierung mit sich bringt. Über diesbezügliche Beispiele freute ich mich.

            Ich bin kein XML-RPC-Fachleut, aber ehrlich gesagt, sehe ich keinen Sinn darin, in den gegebenen Formaten (XML-RPC oder beispielsweise JSON) ein Problem zu sehen, oder anders gesagt sehe ich keinen Anwendungsfall für eine systemübergreifende Typisierung. Was nützt mir ein Typ, wenn das Zielsystem diesen nicht in unterstützt? Was nützt mir zum Beispiel ein uintXX in Javascript, wenn es da nur den Typ number gibt?

            Nun, ich habe doch gezeigt es diese Typen gibt. Und zwr in JS, PHP, c, und Perl gleichermaßen und ganz sicher auch in JAVA c# usw.

            XML-RPC definiert nur sehr allgemeine Typen und die jeweilgen Systeme können die Werte von und zu einem internen Format konvertieren, wie es für sie am besten geeignet ist.

            Genau. Und ebendiese Konvertierung kann man sich sparen wie mein Artikel zeigt.

            Über weitere Beispiele warum XML RPC Datentypen nutzt, würde ich mich freuen.

            MfG

            PS: Demo ergänzt um ein SendeBeispiel. Die Wiederherstellung der Daten ist an Einfachheit nicht zu übertreffen 😉

            1. problematische Seite

              Tach!

              Was nützt mir zum Beispiel ein uintXX in Javascript, wenn es da nur den Typ number gibt?

              Nun, ich habe doch gezeigt es diese Typen gibt. Und zwr in JS, PHP, c, und Perl gleichermaßen und ganz sicher auch in JAVA c# usw.

              Wenn du von Typen sprichst und dabei auf die Programmiersprachen verweist, dann gibt es da nur die Typen, die die jeweilige Sprache definiert. Du führst Uint als Beispiel für einen Typ an, den gibt es nicht in Javascript. Es gibt nur Number, der sowohl Integer als auch Floats aufnehmen kann.

              Auf der anderen Seite stehen die fachlichen Anforderungen, die in den meisten Fällen nicht 1:1 auf die vorhandenen Typen der Programmierumgebung abgebildet werden können, und man nimmt dann den nächstbesten Typ, der mindestens den Wertebereich der Anforderung umfasst.

              Anscheinend meinst du die fachlichen Typen (z.B. Alter ist eine ganze Zahl im Bereich von 0 bis 100) und mischst das begrifflicherweise munter mit den Typen der jeweiligen Sprachen. Und dann kommt sowas raus, dass man deiner Aussage entnehmen kann, es gäbe einen Unsigned Integer in Javascript.

              XML-RPC definiert nur sehr allgemeine Typen und die jeweilgen Systeme können die Werte von und zu einem internen Format konvertieren, wie es für sie am besten geeignet ist.

              Genau. Und ebendiese Konvertierung kann man sich sparen wie mein Artikel zeigt.

              Da wird gar nichts gespart, da wird nur eine andere Verpackung gewählt, und für die muss genauso konvertiert werden.

              PS: Demo ergänzt um ein SendeBeispiel. Die Wiederherstellung der Daten ist an Einfachheit nicht zu übertreffen 😉

              Einfach? Man muss wissen, an und von welchen Positionen man die Daten schreiben und lesen muss. Ganz zu schweigen, dass es dabei zu Überläufen kommen kann. Unter einfach verstehe ich sowas wie das folgende, und zusätzlichen Code musste ich dafür auch nicht einbinden.

              data = JSON.stringify(object);
              object = JSON.parse(data); // zuzüglich Abfangen von Parsefehlern
              

              dedlfix.

              1. problematische Seite

                Hallo,

                (z.B. Alter ist eine ganze Zahl im Bereich von 0 bis 100)

                (du, ich hab hier ein Buch im Regal stehen, da ist das Alter fast 200…)

                Gruß
                Kalk

                1. problematische Seite

                  Tach!

                  (z.B. Alter ist eine ganze Zahl im Bereich von 0 bis 100)

                  (du, ich hab hier ein Buch im Regal stehen, da ist das Alter fast 200…)

                  Durchaus. Das ist aber ein anderer Anwendungsfall, als der auf den ich mich bezog. Meiner war angelehnt an pls Beispiel mit den Daten einer Person.

                  dedlfix.

                  1. problematische Seite

                    Hallo,

                    pls Beispiel mit den Daten einer Person.

                    hm, dann hast du da mehr gesehen/gelesen als ich…

                    Edith sagt:
                    ah, ok. pls Ergänzung in seiner „demo“ hatte ich nicht gelesen. Da ist tatsächlich der Kontext „Daten einer Person“.

                    Aber es soll auch Person mit einem Alter >100 geben…

                    Gruß
                    Kalk

                    1. problematische Seite

                      Tach!

                      pls Beispiel mit den Daten einer Person.

                      hm, dann hast du da mehr gesehen/gelesen als ich…

                      Sieht so aus, aber bei sowas wie

                      Und das wird ausgegeben:
                       Alter: 68
                       Vorname: Fritz
                       Name: Müller
                      

                      und ähnlichen Vorkommen auf der von ihm verlinkten Seite sollte man davon ausgehen können, dass die drei Werte dasselbe Objekt beschreiben, was hier wohl eine Person ist.

                      Ist aber letztlich auch egal, das Beispiel war ein Beispiel einer möglichen Anwendung und nichts mit einem Generalanspruch für alles, das als "Alter" bezeichnet wird.

                      dedlfix.

                      1. problematische Seite

                        Hallo,

                        Sieht so aus, aber bei sowas wie

                        Und das wird ausgegeben:
                         Alter: 68
                         Vorname: Fritz
                         Name: Müller
                        

                        und ähnlichen Vorkommen

                        exakt dieses meinte ich mit „pls Ergänzung“.

                        Ist aber letztlich auch egal,

                        stimmt.

                        Gruß
                        Kalk

                        1. problematische Seite

                          Tach!

                          exakt dieses meinte ich mit „pls Ergänzung“.

                          Gut, deine Ergänzung hatte ich vor dem Absenden meines Postings noch nicht gesehen und bin deshalb nur auf deine ursprüngliche Antwort eingegangen.

                          dedlfix.

              2. problematische Seite

                Hi,

                Anscheinend meinst du die fachlichen Typen (z.B. Alter ist eine ganze Zahl im Bereich von 0 bis 100)

                Hm. Queen Mom, Johannes Heesters, Jeanne Calment, …

                Paßt also schon nicht für Personen-Alter. Für das Alter von Gegenständen/Gebäuden oder ähnlichem erst recht nicht …

                cu,
                Andreas a/k/a MudGuard

                1. problematische Seite

                  Tach!

                  Anscheinend meinst du die fachlichen Typen (z.B. Alter ist eine ganze Zahl im Bereich von 0 bis 100)

                  Hm. Queen Mom, Johannes Heesters, Jeanne Calment, …

                  Paßt also schon nicht für Personen-Alter. Für das Alter von Gegenständen/Gebäuden oder ähnlichem erst recht nicht …

                  Ja und? Das ist ein fiktiver Anwendungsfall, der muss nicht auf alle anderen Anwendungsfälle passen.

                  dedlfix.

              3. problematische Seite

                Tach!

                Was nützt mir zum Beispiel ein uintXX in Javascript, wenn es da nur den Typ number gibt?

                Nun, ich habe doch gezeigt es diese Typen gibt. Und zwr in JS, PHP, c, und Perl gleichermaßen und ganz sicher auch in JAVA c# usw.

                Wenn du von Typen sprichst und dabei auf die Programmiersprachen verweist, dann gibt es da nur die Typen, die die jeweilige Sprache definiert. Du führst Uint als Beispiel für einen Typ an, den gibt es nicht in Javascript.

                Da bist Du falsch informiert. Diese Datentypen gibt es alle siehe ebenda auch in JavaScript.

                Und mein Artikel zeigt die Verwendung inklusive eines Beispiels zum Ausprobieen.

                MfG

                PS: Weitere Beispiele zur Typisierung in XML RPC?

                1. problematische Seite

                  Tach!

                  Du führst Uint als Beispiel für einen Typ an, den gibt es nicht in Javascript.

                  Da bist Du falsch informiert. Diese Datentypen gibt es alle siehe ebenda auch in JavaScript.

                  Dann lass dir mal typeof() davon ausgeben. Die deutsche Übersetzung lässt mehr sprachlichen Interpretationsspielraum als der englische Text und ist wohl eher nicht präzise formuliert. Das "gets" ist mehr im Sinne von "holen" zu sehen und nicht im Sinne von "geben".

                  The getUint32() method gets an unsigned 32-bit integer (unsigned long) at the specified byte offset from the start of the DataView.

                  Die getUint32() Methode gibt eine ganze vorzeichenlose 8-Bit Zahl (Unsigned Byte) vom spezifizierten Offset der DataView zurück.

                  Das heißt nur, das sein solcher Wert aus dem ArrayBuffer geholt wird. Der Rückgabewert ist aber trotzdem vom Typ Number. Der eigentliche Typ des Rückgabwertes wird auf dieser Dokumentationsseite nicht thematisiert.

                  dedlfix.

                  1. problematische Seite

                    Tach!

                    Du führst Uint als Beispiel für einen Typ an, den gibt es nicht in Javascript.

                    Da bist Du falsch informiert. Diese Datentypen gibt es alle siehe ebenda auch in JavaScript.

                    Dann lass dir mal typeof() davon ausgeben.

                    In meinem Artikel geht es nicht nur um JavaScript. Clients kann man auch in anderen Programmier~ bzw. Scriptsprachen entwickeln.

                    Bitte weitere Beispiele zur Typisierung betreff XML RPC.

                    Danke und Gruß.

                2. problematische Seite

                  Hi there,

                  Wenn du von Typen sprichst und dabei auf die Programmiersprachen verweist, dann gibt es da nur die Typen, die die jeweilige Sprache definiert. Du führst Uint als Beispiel für einen Typ an, den gibt es nicht in Javascript.

                  Da bist Du falsch informiert. Diese Datentypen gibt es alle siehe ebenda auch in JavaScript.

                  Du verwechselst "gibt es" mit "sieht in Javascript so aus wie und kann verwendet werden", oder, um Wittgenstein zu strapazieren, die Bedeutung eines Zeichens ergibt sich aus seiner Verwendung. Einfache Datentypen lassen sich im Prinzip alle einfach als Zeichenkette darstellen, die interne Speicherung resp. Repräsentation ergibt sich (oder, ergab sich) aus Effizienz- und Implementierungsgründen. Irgendwie kommt mir das, was Dir da erstrebenswert erscheint, vor wie die Eroberung des Nutzlosen…

                  1. problematische Seite

                    Hi there,

                    um Wittgenstein zu strapazieren, die Bedeutung eines Zeichens ergibt sich aus seiner Verwendung.

                    Das sehe ich auch für meine Artikel so: Die Bedeutung ergibt sich aus der Verwendung.

                    Irgendwie kommt mir das, was Dir da erstrebenswert erscheint, vor wie die Eroberung des Nutzlosen…

                    Ich publiziere nur. D.h., daß es das über das ich schreibe auch ohne mich gibt.

                    MfG

                  2. problematische Seite

                    Hi there,

                    .. um Wittgenstein zu strapazieren,

                    Apropos Wittgenstein

                    Alles klar 😉

                    1. problematische Seite

                      Hi there,

                      .. um Wittgenstein zu strapazieren,

                      Apropos Wittgenstein

                      Sorry, versteh' ich nicht…

              4. problematische Seite

                Tach!

                XML-RPC definiert nur sehr allgemeine Typen und die jeweilgen Systeme können die Werte von und zu einem internen Format konvertieren, wie es für sie am besten geeignet ist.

                Genau. Und ebendiese Konvertierung kann man sich sparen wie mein Artikel zeigt.

                Da wird gar nichts gespart, da wird nur eine andere Verpackung gewählt, und für die muss genauso konvertiert werden.

                Nein. Datentypen sind ja eben dazu da daß man sie nicht extra verpacken muss. Eine Deklaration like uint8_t beeinhaltet ja einen Datentyp der nicht nur 8 Bit im Hauptspeicher sondern auch genau 1 Byte zum Transport benötigt, also keine weitere Verpackung. Genau darum gehts ja auch in meinem Artikel: Um die Portierbarkeit.

                MfG

                1. problematische Seite

                  Nein. Datentypen sind ja eben dazu da daß man sie nicht extra verpacken muss. Eine Deklaration like uint8_t beeinhaltet ja einen Datentyp der nicht nur 8 Bit im Hauptspeicher sondern auch genau 1 Byte zum Transport benötigt, also keine weitere Verpackung.

                  Wenn du ein XML-RPC-Anfrage

                  <param>
                         <value><int>10</int></value>
                  </param>
                  

                  UTF-8-kodiert verschickst, wird aus dem Text 10 der zweistellige Bytestring 0x31 0x30. Bei UTF-32LE-Kodierung wird daraus sogar der 8-stellige Bytestring 0x31 0x00 0x00 0x00 0x30 0x00 0x00 0x00. Der Typ <int> sagt einfach, dass beim Dekodieren des Bytestrings daraus eine 32-Bit-Ganzzahl gemacht werden soll. Umgekehrt musst du, wenn du den uint8 Wert 10 in UTF-32LE kodiertem XML ausgeben willst auch die wieder eine 8-stellige Bytesequenz erzeugen. Heißt, was ein Byte im Hauptspeicher braucht, kann beim Transport durchaus zu längeren Bytestrings werden.

                  1. problematische Seite

                    Wobei die Zeichenkodierung im Grunde genommen ja auch nur eine Typisierung ist, was UTF-32 abstrahiert bzw. andeutet:

                    Um in einer Datei ein bestimmte Zeichen zu finden, würde es, wenn sichergestellt ist daß jedes Zeichen mit genau 4 Byte kodiert ist, genügen die Datei in Schritten von genau 4 Byte zu lesen. Ansonsten müsste man, da es ja auch Zeichen mit 1 Byte Länge gibt, die Datei in Schritten von 1 Byte lesen.

                    Somit ist abstrakt gesehen die Zeichenkodierung im Gunde genommen eine Typisierung und wenn es Letztere nicht geben würde, wäre ist nicht möglich eine CSV-Datei am Trennzeichen zu splitten oder eine XML-Datei zu parsen.

                    MfG

                    1. problematische Seite

                      Tach!

                      Wobei die Zeichenkodierung im Grunde genommen ja auch nur eine Typisierung ist, was UTF-32 abstrahiert bzw. andeutet:

                      Um in einer Datei ein bestimmte Zeichen zu finden, würde es, wenn sichergestellt ist daß jedes Zeichen mit genau 4 Byte kodiert ist, genügen die Datei in Schritten von genau 4 Byte zu lesen. Ansonsten müsste man, da es ja auch Zeichen mit 1 Byte Länge gibt, die Datei in Schritten von 1 Byte lesen.

                      Um die Sache zu vereinfachen, behandelt man heutzutage die Zeichenkodierung getrennt von der Struktur der Daten, solange es sich durchgängig um ein Textformat mit derselben Kodierung handelt, wie es zum Beispiel bei XML oder JSON der Fall ist. Der File-Reader liest die Datei/den Stream entsprechend der Zeichenkodierung und liefert nur noch einen String oder allgemein gesagt eine Folge von Unicode-Zeichen, wobei der Datentyp des Zeichen wegabstrahiert hat, wie es intern im Speicher liegt. Nun interpretiert man nur noch zeichenweise, ohne darüber nachdenken zu müssen, ob das Ding als ein oder mehrere Bytes dahergekommen ist, weil das auf dieser Ebene der Verarbeitung nicht mehr relevant ist.

                      Auf diese Weise kann man Systeme wie Javascript schaffen, die größtenteils (sprich: solange es nicht um einen Transport von und nach extern geht) ohne Betrachtung/Beachtung irgendwelcher Zeichenkodierung auskommen. Das macht das Arbeiten damit einfacher, weil man sich nicht noch um einen Nebenschauplatz kümmern muss.

                      Somit ist abstrakt gesehen die Zeichenkodierung im Gunde genommen eine Typisierung und wenn es Letztere nicht geben würde, wäre ist nicht möglich eine CSV-Datei am Trennzeichen zu splitten oder eine XML-Datei zu parsen.

                      Seh ich nicht zwangsläufig so, weil man Dekodierung und anschließendes Interpretieren arbeitstechnisch und damit auch gedanklich voneinander trennen kann.

                      dedlfix.

                      1. problematische Seite

                        Tach!

                        Wobei die Zeichenkodierung im Grunde genommen ja auch nur eine Typisierung ist, was UTF-32 abstrahiert bzw. andeutet:

                        Um in einer Datei ein bestimmte Zeichen zu finden, würde es, wenn sichergestellt ist daß jedes Zeichen mit genau 4 Byte kodiert ist, genügen die Datei in Schritten von genau 4 Byte zu lesen. Ansonsten müsste man, da es ja auch Zeichen mit 1 Byte Länge gibt, die Datei in Schritten von 1 Byte lesen.

                        Um die Sache zu vereinfachen, behandelt man heutzutage die Zeichenkodierung getrennt von der Struktur der Daten, solange es sich durchgängig um ein Textformat mit derselben Kodierung handelt, wie es zum Beispiel bei XML oder JSON der Fall ist.

                        Genau. Die zur Strukturierung verwendeten Zeichen haben deswegen stets eine bekannte Länge, z.B. 1 Byte. Und da ASCII schon immer eine Teilmenge der für XML/JSON zwingend vorgesehenen Deklaration einer Kodierung ist, müssen solche Dateien im Fall einer UTF-8-Kodierung in Schritten von 1 Byte gelesen werden. Ansonsten würde der Parser diese Zeichen nicht finden.

                        Die Typisierung ist eine Grundvoraussetzung für den wahlfreien Zugriff und dafür dass Daten gespeichert sowie transportiert werden können

                        MfG

                        1. problematische Seite

                          Tach!

                          Um die Sache zu vereinfachen, behandelt man heutzutage die Zeichenkodierung getrennt von der Struktur der Daten, solange es sich durchgängig um ein Textformat mit derselben Kodierung handelt, wie es zum Beispiel bei XML oder JSON der Fall ist.

                          Genau. Die zur Strukturierung verwendeten Zeichen haben deswegen stets eine bekannte Länge, z.B. 1 Byte.

                          Nein, nichts mit "genau". Meine Aussage war eine andere. Ich sehe da auch keinen kausalen Zusammenhang. Es liegt wohl vielmehr in der Verfügbarkeit dieser Zeichen auf der Tastatur begründet.

                          Und da ASCII schon immer eine Teilmenge der für XML/JSON zwingend vorgesehenen Deklaration einer Kodierung ist, müssen solche Dateien im Fall einer UTF-8-Kodierung in Schritten von 1 Byte gelesen werden. Ansonsten würde der Parser diese Zeichen nicht finden.

                          Auch hier wieder nein, der Parser in meiner Argumentation arbeitet nicht mit Bytelängen, weil er bereits die Zeichen bekommt und die internen physikalisch-technisch bedingten Merkmale der Daten für ihn uninteressant sind. Wie der Zugriff im Speicher zu erledigen ist, wissen die Systemfunktionen, derer er sich bedient. Der Parser braucht dazu kein Wissen. Natürlich kann man aus Optimierungsgründen diese Trennung aufgeben, der Preis ist dann aber ein Code, der mehrere Aufgaben zu erledigen hat. Davon geht man aber lieber weg, weil es eine unnötig hohe Komplexität auf eine Stelle konzentriert.

                          Zudem ist ein Arbeiten anhand von Bytelängen ja nur bei auf ASCII basierenden Kodierungen möglich. Es gibt andere Kodierungen, bei denen sind die ASCII-Zeichen nicht vorwärts und rückwärts eindeutig anhand ihres Bytewertes erkennbar. Man möchte auch nicht für jede Kodierung einen eigenen Parser schreiben. Deswegen erst dekodieren und dann unabhängig von der Transportkodierung interpretieren.

                          Die Typisierung ist eine Grundvoraussetzung für den wahlfreien Zugriff und dafür dass Daten gespeichert sowie transportiert werden können

                          Wahlfreier Zugriff - in dem Sinne, dass man genau berechnen kann, wo bestimmte Daten liegen - ist heutzutage nicht mehr so wichtig. Das hat man damals in den 70/80/90ern gebraucht, weil da die Technik noch nicht so schnell und Speicher teuer und damit knapp war. Heutzutage ist es wesentlich unkomplizierter, auch mit sequenziellen Daten zu arbeiten.

                          Ich sehe auch keine zwingende Notwendigkeit, einen Typ wissen zu müssen, um Daten zu transportieren. Der Mensch speichert und übermittelt schon seit langer Zeit erfolgreich Informationen, ohne sich über Typisierungen Gedanken zu machen. Meist bestimmt nur der Kontext, wie die Daten zu interpretieren sind. Aber auch bei einigen der heute üblichen Datenübertragungen spielt ein Typ keine Rolle. Zwei Beispiele:

                          http://example.com/path?foo=bar;qux=42 -> keine Typen, lediglich Trennzeichen.

                          foo;bar;23
                          bla;fasel;4711
                          

                          -> CSV: Keine Typen, lediglich Trennzeichen.

                          Es liegt bei solchen Formaten am Empfänger, ob er die Einzeldaten in für ihn interessanten Typen ablegt oder auch nicht. Solange keine weitergehende Verarbeitung stattfindet, für die Typen einen Vorteil bieten (z.B. Berechnungen), ist ein Typ von Bestandteilen in einem Datenstrom belanglos.

                          dedlfix.

                          1. problematische Seite

                            Hi

                            -> CSV: Keine Typen, lediglich Trennzeichen.

                            Genau. Das Zeichen könnte auch eine Länge von 4 Byte haben (UTF-32). Ohne Wissen ob der Kodierung (+Endianess) wird man dieses Zeichen niemals finden geschweige denn daran splitten können.

                            MfG

                          2. problematische Seite

                            Tach!

                            Wahlfreier Zugriff - in dem Sinne, dass man genau berechnen kann, wo bestimmte Daten liegen - ist heutzutage nicht mehr so wichtig.

                            Ach was!? Gerade bei einem Zugriff in den Random Access Memory ist die Typisierung insofern wichtig als daß es nicht reicht zu wissen wo die Daten liegen sondern auch wie lang die sind.

                            MfG

                            1. problematische Seite

                              Tach!

                              Wahlfreier Zugriff - in dem Sinne, dass man genau berechnen kann, wo bestimmte Daten liegen - ist heutzutage nicht mehr so wichtig.

                              Ach was!? Gerade bei einem Zugriff in den Random Access Memory ist die Typisierung insofern wichtig als daß es nicht reicht zu wissen wo die Daten liegen sondern auch wie lang die sind.

                              Von Trennzeichen bis Trennzeichen ist auch eine Möglichkeit, die Daten zu finden. Ebenso sind nullterminierte Strings in einigen Systemen üblich. Eine Längenangabe ist also kein Erfordernis. Außerdem ging es bisher nur um den Transport und ist RAM eine ganz andere Baustelle. Und darum kümmert sich das Betriebssystem und die System-Library der Programmiersprache. Mit Speicheradressen und -verwaltung kam ich seit Assemblerzeiten nicht mehr in Berührung. (C-Programmierern mag es da anders gehen.)

                              dedlfix.

                              1. problematische Seite

                                Tach!

                                Wahlfreier Zugriff - in dem Sinne, dass man genau berechnen kann, wo bestimmte Daten liegen - ist heutzutage nicht mehr so wichtig.

                                Ach was!? Gerade bei einem Zugriff in den Random Access Memory ist die Typisierung insofern wichtig als daß es nicht reicht zu wissen wo die Daten liegen sondern auch wie lang die sind.

                                Von Trennzeichen bis Trennzeichen ist auch eine Möglichkeit, die Daten zu finden.

                                Richtig. Dazu muss man das Trennzeichen finden was nur klappt, wenn man die zum Trennzeichen gehörige Bytesequenz kennt. Genau das macht ein Parser und der kann auch nur diejenigen Daten für den Wahlfreien Zugriff zur Verfügung stellen die er selbst in der Datei adressieren kann.

                                Näheres im Artikel im Abschnitt Numerische Datentypen.

                                MfG

                                1. problematische Seite

                                  Tach!

                                  Richtig. Dazu muss man das Trennzeichen finden was nur klappt, wenn man die zum Trennzeichen gehörige Bytesequenz kennt.

                                  Hab ich doch schon widerlegt, dass das nicht notwendig ist, wenn man die Dekodierung vorher vornimmt. Dann vergleicht man Zeichen mit Zeichen und die interne Darstellung interessiert genausowenig, wie dass dazu noch viel weiter unten irgendwelche Elektronen sich von A nach B bewegen müssen.

                                  Genau das macht ein Parser und der kann auch nur diejenigen Daten für den Wahlfreien Zugriff zur Verfügung stellen die er selbst in der Datei adressieren kann.

                                  Es gibt genügend Parser, die sequenzielle Datenströme parsen, bei denen sie nicht wissen, wo irgendetwas anfängt oder aufhört, jenseits von "Zeichen" als kleinster Einheit, und daraus auch andere Strukturen erzeugen als solche mit wahlfreiem Zugriff. HTML zu DOM beispielsweise. Darin muss man sich an den Eltern- und Kindelementen entlanghangeln, um zum Ziel zu kommen. Ein wahlfreier Zugriff kann aber durch getElementById() und Konsorten simuliert werden.

                                  dedlfix.

                                  1. problematische Seite

                                    Tach!

                                    Richtig. Dazu muss man das Trennzeichen finden was nur klappt, wenn man die zum Trennzeichen gehörige Bytesequenz kennt.

                                    Hab ich doch schon widerlegt, dass das nicht notwendig ist, wenn man die Dekodierung vorher vornimmt. Dann vergleicht man Zeichen mit Zeichen

                                    Was man nur tun kann wenn man diese Zeichen im wahlfreien Zugriff hat, also im Hauptspeicher. Und wenn programmintern die Kodierung bekannt ist. D.h., daß dem Programm selbst bekannt sein muß ob es bytesemantisch oder zeichenorientiert vergleichen soll.

                                    Wobei bei UTF-8-kodierten Zeichen das erste Byte eine Offsetangabe darstellt nämlich dafür wie lang das Zeichen ist, genauso viel Platz braucht es ja auch im Hauptspeicher. Die Kodierung selbst wird in der Symboltabelle vorgehalten, zumindest ist das in Perl so.

                                    Näheres im Artikel. MfG

                                    1. problematische Seite

                                      Näheres im Artikel

                                      der wahrscheinlich nicht umsonst als problematische Seite verlinkt ist 😂

                                      1. problematische Seite

                                        Näheres im Artikel

                                        der wahrscheinlich nicht umsonst als problematische Seite verlinkt ist 😂

                                        Das ist einfach nur Dumm was Du hier scheibst!!

                              2. problematische Seite

                                Tach!

                                Von Trennzeichen bis Trennzeichen ist auch eine Möglichkeit, die Daten zu finden. Ebenso sind nullterminierte Strings in einigen Systemen üblich. Eine Längenangabe ist also kein Erfordernis.

                                Doch ist es. Wenn eine Datei die utf-8-kodierte Zeichen enthält geparst werden soll, mus jedes einzelne Byte untersucht werden. Und je nachdem welche Wertigkeit das hat, ergibt sich die Länger der im Folgenden zu lesenden Bytes. Also die Anzahl wieviele Bytes für das Zeichen selbst zu lesen sind.

                                Hier der Algorithmus in PHP leicht verständlich.

                                MfG

                                1. problematische Seite

                                  Tach!

                                  Von Trennzeichen bis Trennzeichen ist auch eine Möglichkeit, die Daten zu finden. Ebenso sind nullterminierte Strings in einigen Systemen üblich. Eine Längenangabe ist also kein Erfordernis.

                                  Doch ist es. Wenn eine Datei die utf-8-kodierte Zeichen enthält geparst werden soll, mus jedes einzelne Byte untersucht werden. Und je nachdem welche Wertigkeit das hat, ergibt sich die Länger der im Folgenden zu lesenden Bytes. Also die Anzahl wieviele Bytes für das Zeichen selbst zu lesen sind.

                                  Wir drehen uns im Kreis. Das ist für das Dekodieren notwendig, nicht für das Parsen der Daten an sich. Das Kodieren und Dekodieren kann als eigener Vorgang stattfinden, genauso wie das Kodieren und Dekodieren in elektrische oder anderweitige Signale für noch weiter unten liegende Mechanismen der Datenspeicherung oder des Transports.

                                  dedlfix.

                                  1. problematische Seite

                                    Wichtig ist, das Wesentlche zu erkennen. Also den Unterschied zwischen Sequenzen und wahlfreiem Zugriff. Eine Datei mit UTF-8-kodierten Zeichen ist ist aus der Sicht eines Texteditors eine Aneinandrreihung von Offsetangaben -- diese muss er nämlich als Erste ermitteln, damit der weiß wieviele Bytes im folgenden zu lesen sind -- damit er das jeweilige Zeichen in der angeforderten Kodierung lesbar darstellen kann.

                                    Und: Die Offsetangabe hat stets eine Länge von genau 1 Byte, Datentyp Uint8.

                                    Genau das ist der Grund für eine Typisierung!

                                    MfG

                              3. problematische Seite

                                Darüber habe ich vor einiger Zeit mal einen Artikel geschrieben : So wie c seine Datentypen im RAM ablegt, werden sie auch in Dateien geschrieben bzw. da auch wieder rausgelesen. Das Auslesen dieser Dateien kann auch mit PHP erfolgen, da muss man nur eine passende Schablone für unpack() einsetzen.

                                Wie schon so oft gesagt, Datentypen sind portierbar aber sowas von 😉

                                MfG

                  2. problematische Seite

                    So ist es. In mit UTF-32 Kodierten Dateien bilden 4 Byte die kleinste logische Speichereinheit. D.h., solche Dateien sind zum Parsen nicht byteweise sondern in Schritten von 4 Byte zu lesen. Mehr dazu im Artikel.

                    MfG

  2. problematische Seite

    Hi,

    da mir nun, auch nach umfänglichen Recherchen keine Antwort zuteil wurde warum XML/RPC und SOAP soviel Wert auf eine, wenn auch rudimentäre, Typisierte Datenübertragung legen habe ich unterdessen die Antwort bei Niklaus Wirth gefunden:

    Die Typisierung ist eine Grundvoraussetzung dafür, daß Daten transportiert werden können! Daß heißt andersherum ausgedrückt, daß Daten portierbar sind weil sie typisiert sind.

    Schönes Wochenende.

  3. problematische Seite

    hi und siehe Thema,

    kurzum: in welchen Fällen würde denn eine Typisierung von Parametern sinvoll sein? Mir fällt jetzt nur das Beispiel Alter ein was da ein unsigned integer (char) sein könnte, aber da gibt bestimmt noch mehr Fälle.

    Ja, hier ist auch noch ein schönes Beispiel: Datum und Uhrzeit als 32-Bit-Integer

    telnet ptbtime2.ptb.de 37 zeigt zeigt diesen 32-Bit-Integer Datentyp (Big Endian) welcher die seit 1900 abgelaufenen Sekunden beeinhaltet 😉

    MfG

    1. problematische Seite

      Interessant auch, daß DataView.setFloat32() aus einer 10 mit 37 Nullen eine 9.99999968028569e+37 macht, aber für diese Zahl nur 4 Byte in den ArryBuffer setzt.

      D.h., daß man bei einer angewandten Typisierung einen numerischen Wert nicht in der Stringlänge begrenzt sondern im Wert selbst. D.h. für eine 10 mit 37 Nullen werden letztendlich auch stets nur 4 Byte übertragen und das bedeutet wiederum, daß nach einer Übertragung serverseitig nicht die Stringlänge zu prüfen ist sondern der Wert.

      MfG

      1. problematische Seite

        Interessant auch, daß DataView.setFloat32() aus einer 10 mit 37 Nullen eine 9.99999968028569e+37 macht, aber für diese Zahl nur 4 Byte in den ArryBuffer setzt.

        Dann machst du was falsch. 10e37 lässt sich nicht als single precisision floating point Zahl darstellen:

        const buffer = new ArrayBuffer(4);
        const view = new DataView(buffer);
        view.setFloat32(10e37);
        //Uncaught RangeError: Offset is outside the bounds of the DataView
        //    at DataView.setFloat32 (<anonymous>)
        

        Selbst wenn man den Overflow ignoriert, kommt bei der Konvertierung nocht etwas anderes raus als du behauptst.

        D.h., daß man bei einer angewandten Typisierung einen numerischen Wert nicht in der Stringlänge begrenzt sondern im Wert selbst.

        Die Aussage ergibt so überhaupt keinen Sinn.

        1. problematische Seite

          view.setFloat32(10e37);

          So wirds ja auch nicht gesetzt. Wie es richtig gemacht wird zeigt die Demo

          MfG

          1. problematische Seite

            view.setFloat32(10e37);

            So wirds ja auch nicht gesetzt.

            Da hast du recht, ich revidiere meine Aussage.

        2. problematische Seite

          Guten Morgen,

          D.h., daß man bei einer angewandten Typisierung einen numerischen Wert nicht in der Stringlänge begrenzt sondern im Wert selbst.

          Die Aussage ergibt so überhaupt keinen Sinn.

          D.h., daß ein String mit 4 Byte Länge auch Zahlen > 9999 beeinhalten kann resp. Vorzeichen. Und das heißt daß eine typegerechte Übertragung außerhalb des Hauptspeichers (Handle, Dateien, Sockets, HTTP..) auch eine typegerechte Prüfung ermöglicht.

          MfG

          1. problematische Seite

            Guten Morgen,

            D.h., daß man bei einer angewandten Typisierung einen numerischen Wert nicht in der Stringlänge begrenzt sondern im Wert selbst.

            Die Aussage ergibt so überhaupt keinen Sinn.

            D.h., daß ein String mit 4 Byte Länge auch Zahlen > 9999 beeinhalten kann resp. Vorzeichen.

            Aber nicht beim textbasierten XML-RPC. Ich habe dir ja das Beispiel mit UTF-8 und UTF-32LE gebracht, dass das Gegenteil beweist.

            Und das heißt daß eine typegerechte Übertragung außerhalb des Hauptspeichers (Handle, Dateien, Sockets, HTTP..) auch eine typegerechte Prüfung ermöglicht.

            • Was soll eine typgerechte Übertragung sein? Eine Kodierung, mit expliziten Typannotationen?
            • Was soll eine Übertragung außerhalb des Hauptspeichers sein?
            • Was soll eine typgerechte Prüfung sein? Ein Typechecking? Eine Daten-Validierung?

            Es wäre wirklich hilfreich, wenn du versuchst dich fachgerecht auszudrücken. Mir düngt es, dass du die ganze Zeit von Typen redest, aber eigentlich Kodierung meinst. Das macht es schwierig nachzuvollziehen, was du eigentlich sagen willst.

            1. problematische Seite

              • Was soll eine typgerechte Übertragung sein? Eine Kodierung, mit expliziten Typannotationen?

              Z.B. daß man den Maximalwert einer Zahl an der Zahl selbst festmacht und nicht an der Anzahl der Ziffern.

              Ich habe dir ja das Beispiel mit UTF-8 und UTF-32LE gebracht, dass das Gegenteil beweist.

              Ja, das wissen wir. Genau deswegen gibt es ja numerische Datentypen: Damit eine zehn mit 35 Nullen hintendran eben nicht genausoviele Bytes im Speicher braucht sondern nur 4. Und das gilt auch für den Transport.

              Es wäre wirklich hilfreich, wenn du versuchst dich fachgerecht auszudrücken.

              Da kann ich auch gleich meinen ganzen Artikel hier posten. Wenn Du dazu Fragen hast, darfst Du dich gerne per eMail bei mir melden.

              MfG

              1. problematische Seite

                • Was soll eine typgerechte Übertragung sein? Eine Kodierung, mit expliziten Typannotationen?

                Z.B. daß man den Maximalwert einer Zahl an der Zahl selbst festmacht und nicht an der Anzahl der Ziffern.

                Wie passen da unbeschränte Datentypen ins Bild? Haskells Integer-Datentyp, zum Beispiel, kann alle ganzen Zahlen aufnehmen. Eine ganze Zahl kann ich mit LEB kodieren, verschicken und wieder rekonstruieren. Alles typsicher, aber es gibt keine obere Schranke - weder für den Wertebreich, noch für die Länge der Bytestrings, die LEB braucht.

                1. problematische Seite

                  • Was soll eine typgerechte Übertragung sein? Eine Kodierung, mit expliziten Typannotationen?

                  Z.B. daß man den Maximalwert einer Zahl an der Zahl selbst festmacht und nicht an der Anzahl der Ziffern.

                  Wie passen da unbeschränte Datentypen ins Bild?

                  Gar nicht! Die Typsierung ist ja auch eine Beschränkung weil sie auf den Speicherbedarf ausgerichtet ist. So ist auf einer 32~Bit~machine der größtmögliche Wert für einen vorzeichenlosen Integer 0xFFFFffff, eben die 32 Bit bzw. 4 Byte.

                  Und genau diese 4 Byte braucht eine Zahl 4294967295 für den Transport. Genauso wie die Zahl -127 nur ein Byte für den Transport benötigt. Deklariere ich jedoch diese -127 als 32~Bit~Integer dann braucht die eben auch 4 Byte für den Transport.

                  Andererseits gibt es für den Transport keine Obergrenze weil dieser Layer ja unabhängig von der Rechnerarchitektur ist. So könnte ich einen int64 problemlos auch auf der Festplatte einer 32~Bit~Machine speichern wofür 8 Byte vollauf genügen, nur Rechnen kann diese Maschine mit diesem Datentyp nicht.

                  Also ich verstehe nicht welch Problem Du mit diesen paar einfachen Fachbegriffen hast. Selbst wenn die jetzt nicht immer 100%ig in Professorendeutsch sind, ist es doch recht einfach zu verstehen worum es überhaupt geht.

                  Ohne Verständnis des Wirth'schen Dateibegriffes gäbe es in JS keine typed Arrays, ArrayBuffer, StringView und DataView. Ohne Typisierung gäbe es ja noch nicht einmal UTF-8. Jede Textdatei transportiert ein Array mit Uint8 Integers. Jeder Router der classful arbeitet schnappt sich bei Ipv4 das erste Byte und guckt was da für eine Zahl drinsteht.

                  Schöne Grüße.

                  PS: Niklaus Wirth muß dann wohl ein Monster gewesen sein 😉

            2. problematische Seite

              hi,

              • Was soll eine typgerechte Übertragung sein? Eine Kodierung, mit expliziten Typannotationen?

              Ja, nämlich das, was es schon immer gibt: Das Byte als kleinste physikalische Speichereinheit und den entsprechenden Datentyp. Z.B. benötigt ein Float32 genau 4 Byte und letztere sind das was man auch übertragen kann.

              • Was soll eine Übertragung außerhalb des Hauptspeichers sein?

              Ebendiese Bytes. In Dateien, in Sockets, in Handles (Lochkarten, Disketten, Magnetbänder..).

              • Was soll eine typgerechte Prüfung sein? Ein Typechecking? Eine Daten-Validierung?

              Daß man den Wert eines Numerischen Datentypes prüft und nicht die Länge des Strings in dem er übertragen werden soll.

              PS: Ich habe auch eine Weile gebraucht um das alles zu verstehen. Genaugenommen mehrere Jahre. Aber keine Sorge, das geht irgendwann runter mit dem entsprechenden AHA Effekt.

              1. problematische Seite

                • Was soll eine typgerechte Prüfung sein? Ein Typechecking? Eine Daten-Validierung?

                Daß man den Wert eines Numerischen Datentypes prüft und nicht die Länge des Strings in dem er übertragen werden soll.

                PS: Ich habe auch eine Weile gebraucht um das alles zu verstehen. Genaugenommen mehrere Jahre. Aber keine Sorge, das geht irgendwann runter mit dem entsprechenden AHA Effekt.

                Ich kenne mich mit Typtheorie und Darstellungstheorie einigermaßen aus - ich kann dir trotzdem nicht folgen, weil du dich nicht auf die geläufige Fachsprache einlässt und viele Begriffe neu erfindest, durcheinander wirfst, oder in falschen Bedeutungszusammenhängen gebrauchst.

            3. problematische Seite

              Hallo 1unitedpower,

              Mir düngt es,

              Mich dünkt 😝 (mir ist auch möglich, aber weder g noch es gehören dahin.)

              Es wäre wirklich hilfreich, wenn du versuchst dich fachgerecht auszudrücken.

              Das allerdings.

              Bis demnächst
              Matthias

              --
              Rosen sind rot.
  4. problematische Seite

    Back'mas'wieda 😉

    kurzum: in welchen Fällen würde denn eine Typisierung von Parametern sinvoll sein? Mir fällt jetzt nur das Beispiel Alter ein was da ein unsigned integer (char) sein könnte, aber da gibt bestimmt noch mehr Fälle.

    Ein besseres Beispiel kann es gar nicht geben: Stellen Sie sich vor, sie erfassen die Altersangaben einer mittleren Kleinstadt mit 10T Einwohnern, schreiben diese Angaben in dezimaler Darstellung hintereinander weg in eine Datei und schicken diese Datei ans Einwohnermeldeamt damit die das Durchschnittsalter, das Jüngste und das Älteste daraus berechnen.

    Nun, der Informationsgehalt ist vorhanden, aber die Aufgabe ist nicht lösbar, weil es Altersangaben gibt mit 1, 2 oder 3 Ziffern: Eine Wiederherstellung der einzelnen Altersangaben ist nicht möglich!

    Wurden jedoch die Zahlen typisiert übertragen, kann jede einzelne Zahl wiederhergestellt werden. Eine Typisierung nämlich, legt den Wertebereich einer Zahl fest. Z.B. von 0..255. Und damit hat jede Zahl eine Länge von genau einem Byte.

    Das ist der eigentliche Sinn der Typisierung: Den Wertebereich einschränken.

    Schönen Tach auch 😉

    PS: Mehr dazu im Artikel

    1. problematische Seite

      Hallo pl,

      Ein besseres Beispiel kann es gar nicht geben: Stellen Sie sich vor, sie erfassen die Altersangaben einer mittleren Kleinstadt mit 10T Einwohnern, schreiben diese Angaben in dezimaler Darstellung hintereinander weg in eine Datei

      Das wäre ziemlich dumm. Schließlich gibt es genau zu diesem Zweck geeignete Formate, wie etwa CSV.

      Bis demnächst
      Matthias

      --
      Rosen sind rot.
      1. problematische Seite

        hi,

        Ein besseres Beispiel kann es gar nicht geben: Stellen Sie sich vor, sie erfassen die Altersangaben einer mittleren Kleinstadt mit 10T Einwohnern, schreiben diese Angaben in dezimaler Darstellung hintereinander weg in eine Datei

        Das wäre ziemlich dumm. Schließlich gibt es genau zu diesem Zweck geeignete Formate, wie etwa CSV.

        Dumm nur wenn es keine Typisierung geben würde: Da gäbe es nämlich auch keine CSV Dateien 😉

      2. problematische Seite

        Ahh, nochwas @Matthias Apsel

        Typisierung legt den Wertebereich einer Zahl fest. Aber auch bei Strings kann man eine Festlegung treffen: Nämlich betreff der Stinglänge. Programmiertechnisch wird sowas Padding genannt und zum Auffüllen eine Strings sind in c Nullbytes üblich. Das kommt daher weil einerseits Strings in c nämlich auch nur zusammengesetzte Datentypen sind, Strings in c mit null zu terminieren sind und andererseits c den Speicher nicht dynamisch verwaltet. Von daher muss man in c die Länge einer Zeichenkette deklarieren bevor man sie verwenden kann.

        Bis hier verständlich???

        Gut. Neuere Programmiersprachen kennen Padding was mit Leerzeichen auffüllt. Damit man damit umgehen kann, gibt es Trimfunktionen die das wieder rückgängig machen und: Solche Funktionen können auch mit vorangestellten Leerzeichen umgehen. Nun können wir auch bezüglich unserer Altersangaben eine Festlegung treffen um diese Zahlen in dezimaler Darstellung auf eine einheitliche Länge zu bringen: Führende Nullen!!! Wenn jede Zahl vierstellig ist können wir die auch ohne Trennmittel hintereinanderweg in eine Datei schreiben.

        Sozusagen eine proprietäre Typisierung: Die den Wertebereich einer Zahl dann auf 9999 und die Stringlänge auf 4 festlegt 😉

        Schöne Grüße.

      3. problematische Seite

        PS:

        Ein besseres Beispiel kann es gar nicht geben: Stellen Sie sich vor, sie erfassen die Altersangaben einer mittleren Kleinstadt mit 10T Einwohnern, schreiben diese Angaben in dezimaler Darstellung hintereinander weg in eine Datei

        Das wäre ziemlich dumm.

        Die Idee ist sogar ausgesprochen Klug. Sie ist nur unzweckmäßig umgesetzt. Hätte nämlich der Beamte die Altersangeben nicht dezimal sondern hexadezimal in die Datei geschrieben, wäre das maschinell bestens zu verarbeiten 😉

        MfG

        1. problematische Seite

          Hallo pl,

          hätte der Beamte die Daten binär in die Datei geschrieben, wäre es noch viel besser elektronisch verarbeitbar – am Besten gleich in der Endianess des verarbeitenden Rechners.

          Viele Grüße
          Robert

          1. problematische Seite

            Hi Robert,

            hätte der Beamte die Daten binär in die Datei geschrieben, wäre es noch viel besser elektronisch verarbeitbar – am Besten gleich in der Endianess des verarbeitenden Rechners.

            Jau!!! Er hats!!! Wird ja auch Zeit 😉

            Btw.: Bei einem Byte gibt es keine Endianness 😉

            Schöne Grüße.

          2. problematische Seite

            Hallo pl,

            hätte der Beamte die Daten binär in die Datei geschrieben, wäre es noch viel besser elektronisch verarbeitbar –

            Genau! Das Byte für mein Alter sieht übrigens so aus: =

            Und ist damit sogar human readable 😉

            Schöne Grüße.

            PS: In der nächsten Datei sollen die Namen gesendet werden…

            1. problematische Seite

              Hallo pl,

              hätte der Beamte die Daten binär in die Datei geschrieben, wäre es noch viel besser elektronisch verarbeitbar –

              Genau! Das Byte für mein Alter sieht übrigens so aus: =

              in welchem Encoding eigentlich? 😛

              Viele Grüße
              Robert

              1. problematische Seite

                Hi Robert

                hätte der Beamte die Daten binär in die Datei geschrieben, wäre es noch viel besser elektronisch verarbeitbar –

                Genau! Das Byte für mein Alter sieht übrigens so aus: =

                in welchem Encoding eigentlich? 😛

                Auf Byteebene gibt es kein Encoding. Guck Dir mal die PHP Funktionen ord() und chr() an.

                echo ord("=");
                

                Zeigt Dir wie alt ich bin 😉

                MfG

                1. problematische Seite

                  Hallo pl,

                  Auf Byteebene gibt es kein Encoding. Guck Dir mal die PHP Funktionen ord() und chr() an.

                  echo ord("=");
                  

                  Zeigt Dir wie alt ich bin 😉

                  ord — Gibt den ASCII-Wert eines Zeichens zurück. (http://php.net/manual/de/function.ord.php)

                  Bis demnächst
                  Matthias

                  --
                  Rosen sind rot.
                  1. problematische Seite

                    Hallo pl,

                    Auf Byteebene gibt es kein Encoding. Guck Dir mal die PHP Funktionen ord() und chr() an.

                    echo ord("=");
                    

                    Zeigt Dir wie alt ich bin 😉

                    ord — Gibt den ASCII-Wert eines Zeichens zurück.

                    Genau! Oder anders, kodierungsunabhängig, ausgedrückt: Die Oktettenwertigkeit. Statt ord() gehts ja auch so z.B.

                    $, = "\n";
                    print unpack "C*", "ABCD="; 
                    
                    Ergebnis:
                    65
                    66
                    67
                    68
                    61
                    

                    Und in PHP ist da nur der Syntax ein bischen anders.

                    MfG

                2. problematische Seite

                  Hallo pl,

                  je nachdem, worum es in der Gemeinde geht, kann es von Vor- oder Nachteil für dich sein, wenn die Datenbank auf einem IBM-Großrechner läuft. In EBCDIC ist = nämlich etwas mehr als in ASCII.

                  Viele Grüße
                  Robert

                  1. problematische Seite

                    hi

                    je nachdem, worum es in der Gemeinde geht, kann es von Vor- oder Nachteil für dich sein, wenn die Datenbank auf einem IBM-Großrechner läuft. In EBCDIC ist = nämlich etwas mehr als in ASCII.

                    Ja, das mag sein. Die Datei trasportiert jedoch kein EBCDIC sondern nur die Oktetten. Das ist von einer Rechnerarchitektur unabhängig denn zum Transport verlassen die Oktetten den Rechner, die Architektur jedoch bleibt 😉

                    Die meisten Oktetten ab einer Wertigkeit 30 sind als Textzeichen lesbar. Es handelt sich also um eine Textdatei.

                    MfG

                  2. problematische Seite

                    Ausgeschlafen;

                    je nachdem, worum es in der Gemeinde geht, kann es von Vor- oder Nachteil für dich sein, wenn die Datenbank auf einem IBM-Großrechner läuft. In EBCDIC ist = nämlich etwas mehr als in ASCII.

                    Die Absicht besteht ja darin, Zahlen zu übertragen und nicht Zeichen. Daß die Oktette mit der Wertigkeit 0x3D bzw 61 wie ein Gleichheitszeichen aussieht, zeigt schließlich auch nur daß Zeichen als primitive Datentypen transportiert werden.

                    Schönen Sonntag.

                    1. problematische Seite

                      Moin,

                      wenn du Zahlen – 61 – übertragen willst, überträgst du am Besten Zahlen – 61 – und keine Zeichen – =. 61 ist eindeutig, = ist es nicht.

                      Viele Grüße
                      Robert

                      1. problematische Seite

                        Moin,

                        wenn du Zahlen – 61 – übertragen willst, überträgst du am Besten Zahlen – 61 – und keine Zeichen – =. 61 ist eindeutig, = ist es nicht.

                        Eben. Und genau deswegen gibt es die Typisierung: Damit Zahlen ihrem Typ entsprechend übertragen werden können. 0x3D braucht genau ein Byte.

                        MfG

                        1. problematische Seite

                          Tach!

                          Und genau deswegen gibt es die Typisierung: Damit Zahlen ihrem Typ entsprechend übertragen werden können. 0x3D braucht genau ein Byte.

                          Nee, was du da machst ist Kodierung. Du kodierst die Zahl in einem Byte, und das überträgst du. Vielleicht ist zufälligerweise das interne Speicherformat gleich wie das Format für die Übertragung, dann Glück gehabt, kannst es 1:1 kopieren. Ansonsten ist der Typ ist für die Übertragung irrelevant. Der Dekodierer auf Empfängerseite muss nur wissen, wieviel Byte er lesen muss, und wie er sie zu interpretieren hat, um die Daten für die nächste Schicht im Programm wiederherstellen zu können.

                          Nimm mal als Datentyp einen für ein Unicode-Zeichen. Kannst du anhand des Typs wissen, wieviel Bytes du zum Speichern brauchst? Nein. Das weißt du erst, nachdem du es gemäß einer der Vorschriften (z.B: UTF-x) kodiert hast. Und dann hast du für denselben Datentyp unterschiedliche Darstellungsmöglichkeiten, je nachdem welche UTF-x du nimmst. Ändert sich dadurch der Typ von Zeichen zu UTF-8-Zeichen oder UTF-16-Zeichen? Für mich jedenfalls nicht, wenn sich nur die physische Darstellung ändert.

                          dedlfix.

                          1. problematische Seite

                            Tach!

                            Und genau deswegen gibt es die Typisierung: Damit Zahlen ihrem Typ entsprechend übertragen werden können. 0x3D braucht genau ein Byte.

                            Nee, was du da machst ist Kodierung.

                            Nein.

                            pack("C", 61);
                            

                            Erzeugt dieses Byte für den Transport. Das hat mit Zeichenkodierung überhaupt nichts zu tun sondern einzig und allein mit der Typisierung welche die Schablone C implementiert.

                            MfG

                            1. problematische Seite

                              Tach!

                              pack("C", 61);
                              

                              Erzeugt dieses Byte für den Transport. Das hat mit Zeichenkodierung überhaupt nichts zu tun sondern einzig und allein mit der Typisierung welche die Schablone C implementiert.

                              Das ist keine Typisierung, sondern eine Formatierung. Die Daten werden lediglich für ein bestimmtes Format gebracht, also auf eine konkrete Weise kodiert.

                              Ich sprach im ersten Teil der Antwort von Kodierung allgemein. Um Zeichenkodierung im speziellen ging es im Beispiel des zweiten Teils. Ich kann auch gern noch ein Beispiel abseits von Zeichen bringen.

                              L	unsigned long (always 32 bit, machine byte order)
                              N	unsigned long (always 32 bit, big endian byte order)
                              V	unsigned long (always 32 bit, little endian byte order)
                              

                              Du wirst mir hoffentlich nicht einzureden versuchen, dass das drei Typen sind. Das sind lediglich drei Formatierungen/Kodierungen für denselben Typ.

                              dedlfix.

                              1. problematische Seite

                                hi,

                                L	unsigned long (always 32 bit, machine byte order)
                                N	unsigned long (always 32 bit, big endian byte order)
                                V	unsigned long (always 32 bit, little endian byte order)
                                

                                Du wirst mir hoffentlich nicht einzureden versuchen, dass das drei Typen sind. Das sind lediglich drei Formatierungen/Kodierungen für denselben Typ.

                                Steht doch da was das für Typen sind.

                                Die Schablonen implementieren diese Datentypen damit sie transportiert werden können. Und selbstverständlich haben mit N oder V erzeugte Binaries jeweils eine dem Datentyp entsprechende Länge, nämlich 32 Bit (4 Bytes).

                                Über die Schablone kann man die einzelnen Oktettenwertigkeiten bestimmen:

                                print unpack "CCCC", pack "N", 0xFFFFffff; 
                                # 255 255 255 255
                                

                                Und genauso werden IPv4 Adressen umgerechnet, das N steht für Networkorder. Hinsichtlich Byteorter muss man beachten, daß die ggf. von der Architektur vorgegeben ist. Auf jeden Fall jedoch kann man zwischen High/Low Order umrechnen.

                                Was Zeichenkodierung betrifft: Die Binary eines ASCII Zeichen ist ein primitiver Datentyp, ein vorzeichenloser 8 Bit Integer mit einer Länge von einem Byte.

                                UTF-8-Zeichen sind aus diesem Datentyp zusammengesetzte (abstrakte) Datentypen, wobei das erste Byte bstimmt, wieviele Bytes insgesamt zum jeweiligen Zeichen gehören.

                                Wenn die Oktettenwertigkeit des 1. Byte zB. zwischen 239 und 248 liegt sind für dieses Zeichen genau 4 Bytes zu lesen. Das muss z.B. jeder Texteditor machen damit er das Zeichen darstellen kann.

                                Man kann feststellen, daß jede Architektur die mit Zeichen arbeitet, mindestens den Datentyp eines vorzeichenlosen 8 Bit Integer kennen muss.

                                Und noch was praktisches, was den Zusammenhang zwischen Typisierung und Transport anschaulich macht:

                                Zeitserver nach RFC 868 liefern die genaue Uhrzeit als Anzahl der seit 1900 verstrichenen Sekunden. Die an einen Zeitserver gerichtete Anfrage liefert einen 32 Bit numerischen Datentyp in Network-Order (Big Endian), zu lesen sind also genau 4 Bytes. Untenstehender Code nimmt diese Zahl als Anzahl der Sekunden und rechnet diese auf Lokalzeit um:

                                my $socket = IO::Socket::INET->new("ptbtime2.ptb.de:37") or die $@;
                                read($socket, my $buffer, 4);
                                
                                # 2208988800 Differenz in Sekunden 1.1.1900 1.1.1970
                                print scalar localtime unpack("N", $buffer) - 2208988800;
                                # Sun Mar 25 16:38:36 2018
                                

                                MfG

                                1. problematische Seite

                                  Tach!

                                  UTF-8-Zeichen sind aus diesem Datentyp zusammengesetzte (abstrakte) Datentypen, wobei das erste Byte bstimmt, wieviele Bytes insgesamt zum jeweiligen Zeichen gehören.

                                  Abstrakt ist weder ein Synonym noch hat es die Bedeutung von zusammengesetzt. Etwas zusammengesetztes ist auch nicht abstrakt.

                                  Man kann feststellen, daß jede Architektur die mit Zeichen arbeitet, mindestens den Datentyp eines vorzeichenlosen 8 Bit Integer kennen muss.

                                  Also Javascript arbeitet mit Zeichenketten/Strings, aber kennt weder Zeichen als Datentyp noch vorzeichenlose 8 Bit Integer. Der einzige Zahlentyp ist Number. Trotzdem kann Javascript sehr gut mit Texten umgehen. Man braucht die Physik nicht für das Verständnis von Datentypen. Dass es andere Sprachen gibt, bei denen die Typen sich deutlicher an den Gegebenheiten der Hardware orientieren ist eine andere Geschichte, die dem Verwendungszweck dieser Sprachen geschuldet ist.

                                  dedlfix.

                                  1. problematische Seite

                                    hi,

                                    Also Javascript arbeitet mit Zeichenketten/Strings, aber kennt weder Zeichen als Datentyp noch vorzeichenlose 8 Bit Integer.

                                    Da bist Du falsch informiert. JS kennt ArrayBuffer und DataView. Und damit kann man aus einem 32 Bit Datentyp auch die vier Oktettenwerte wiederherstellen. Oder Mit StringView vier Zeichen oder ein UTF-8-Zeichen.

                                    Der einzige Zahlentyp ist Number. Trotzdem kann Javascript sehr gut mit Texten umgehen. Man braucht die Physik nicht für das Verständnis von Datentypen.

                                    Doch braucht man: nämlich für Transport, Speicherung und Darstellung!

                                    MfG

                                    1. problematische Seite

                                      Tach!

                                      Also Javascript arbeitet mit Zeichenketten/Strings, aber kennt weder Zeichen als Datentyp noch vorzeichenlose 8 Bit Integer.

                                      Da bist Du falsch informiert. JS kennt ArrayBuffer und DataView. Und damit kann man aus einem 32 Bit Datentyp auch die vier Oktettenwerte wiederherstellen. Oder Mit StringView vier Zeichen oder ein UTF-8-Zeichen.

                                      Das täuscht. Man arbeitet auch damit nach wie vor mit dem Typ Number. Auch bei den TypedArrays. StringView gibt es nicht (mehr). Mit der Binärdarstellung dieser Werte kommt Javascript nicht in Berührung. Die Kommunikation nach außen hin (inklusive Dateisystem) erledigt der Browser. Man kann lediglich mit Javascript den Browser fernsteuern, dass er aus deinen Number-Werten eine bestimmte Darstellung erzeugt (und andersherum), indem du das passende TypedArray nimmst oder die passende DataView-Methode. Eine Notwendigkeit, dass Javascript einen anderen Typ als Number (für Zahlenwerte) benötigt, ergibt sich daraus nicht.

                                      Der einzige Zahlentyp ist Number. Trotzdem kann Javascript sehr gut mit Texten umgehen. Man braucht die Physik nicht für das Verständnis von Datentypen.

                                      Doch braucht man: nämlich für Transport, Speicherung und Darstellung!

                                      Diese drei Dinge sind nicht Bestandteil von Javascript. Das erledigt der Browser in Zusammenarbeit mit anderen Teilen des Betriebssystems. Javascript beauftragt lediglich den Browser.

                                      dedlfix.

                                      1. problematische Seite

                                        hi,

                                        Doch braucht man: nämlich für Transport, Speicherung und Darstellung!

                                        Diese drei Dinge sind nicht Bestandteil von Javascript.

                                        JS kann zwischen Bytesemantic und Charactersemantic unterscheiden. Wenn mit XMLHttpRequest ein String 'äöü' zum server gesendet wird, generiert das xhr Objekt einen Header Content-Length für den Request. Und da steht in diesem Fall eine 6 drin, was die Anzahl der gesendeten Bytes ist. Ansonsten ist das für JS ein String mit 3 Zeichen.

                                        Und noch ein Beispiel betreff Numbers, mal angenommen es läge eine Datei oder ein HTTP message Body vor mit einer Länge von genau 4 Bytes.

                                        Da gibt es bezüglich Zahlen genau diese 3 Möglichkeiten:

                                        1. es ist eine Zahl vom Typ 32 Bit
                                        2. es sind zwei Zahlen vom Typ 16 Bit
                                        3. es sind 4 Zahlen vom Typ 8 Bit
                                        

                                        Wobei es bei 1. und 2. wegen der Endiannes auch noch a und b gibt.

                                        Und selbstverständlich kann JS auch damit umgehen. FileAPI, FetchAPIXMLHtpRequest, Blob, File, ArrayBuffer, DataView, StringView…

                                        MfG

                                      2. problematische Seite

                                        Tach!

                                        Doch braucht man: nämlich für Transport, Speicherung und Darstellung!

                                        Diese drei Dinge sind nicht Bestandteil von Javascript. Das erledigt der Browser in Zusammenarbeit mit anderen Teilen des Betriebssystems. Javascript beauftragt lediglich den Browser.

                                        Das ist nur zum Teil richtig. Der Browser bekommt nämlich nicht äöü als 3 Zeichen sondern als 6 Bytes und kriegt über den Content-Type mitgeteilt was der damit machen soll, im Default ist Charset="UTF-8". Und: Auch JavaScript schickt 6 Bytes an den Browser wenn äöü ausgegeben werden sollen (es sei denn, mit escape/unescape wurde eine 1-byte-Kodierung veranlasst, was jedoch als deprecated gilt).

                                        Allgemein kann man das so formulieren: Wenn Daten ein System verlassen, verlassen sie es als eine Folge primitiver Datentypen. Nur der dazu mitgelieferte Content-Type entscheidet beim Empfänger darüber was der damit machen soll.

                                        MfG

                                2. problematische Seite

                                  Hallo pl,

                                  UTF-8-Zeichen …

                                  gibt’s gar nicht.

                                  Bis demnächst
                                  Matthias

                                  --
                                  Rosen sind rot.
                                  1. problematische Seite

                                    Euch fehlt wichtiges Grundwissen. Dieser Fakt macht euer Bewertungssystem ziemlich fagwürdig!

                                    MfG

                                    1. problematische Seite

                                      Hallo,

                                      Euch fehlt …

                                      Letztens hörte ich eine Verkehrsmeldung über einen Falschfahrer auf der Autobahn. Es waren aber Hunderte!

                                      Gruß
                                      Kalk

                              2. problematische Seite

                                Tach!

                                L	unsigned long (always 32 bit, machine byte order)
                                N	unsigned long (always 32 bit, big endian byte order)
                                V	unsigned long (always 32 bit, little endian byte order)
                                

                                Das Wichtigste: Man muss dem Empfänger mitteilen was in der Datei drin ist!!!

                                Zum Beispiel::

                                 Content-Type: zahlen/32BitLE
                                 Content-Type: zahlen/32BitBE
                                 Content-Type: text/plain; Charset=UTF32LE
                                 Content-Type: text/html; Charset=UTF32LE
                                

                                Denn nur dann weiß der Empfänger was die übermittelten Datentypen darstellen sollen.

                                MfG

    2. problematische Seite

      Tach!

      Ich erkenne immer noch nicht die Motivation dahinter. Du scheinst irgendwelche Grundlagenforschung zu betreiben, für ein Problem, für das es längst diverse Lösungen gibt. Neben der Möglichkeit, Daten in einem proprietären Format zusammenzustellen und das als Datei zu übertragen, wenn Sender und Empfänger sich kennen und wissen, was sie da austauschen, gibt es eine Menge standardisierte Formate und Protokolle. Auch solche, die agnostisch gegenüber dem konkreten Speicherformat auf den Systemen sind. Bei denen es also nicht darauf ankommt, ob die Beteiligten für Integer das Zweiterkomplement und für Floats IEEE 754 verwenden oder irgendeine ganz andere interne Darstellung.

      PS: Mehr dazu im Artikel

      Den ich nicht vorhabe zu lesen. Schon die Einleitung ist sehr fragwürdig.

      HTTP kennt keine Datentypen. Es ist jedoch möglich sowohl primitive als auch abstrakte Datentypen typegerecht per HTTP zu transportieren.

      HTTP ist ein Übertragungsprotokoll. Seine urpsrüngliche Aufgabe war es, Daten in Textform zu transportieren, deswegen auch sein Name: Hyper Text Transfer Protocol. Konkret war es damals das damalige HTML. Im Laufe der Zeit kamen die Notwendigkeiten und die Erweiterungen hinzu, beispielsweise andere Formate übertragen zu können und dem Empfänger die dazu notwendige Information in Form eines Content-Type mitzuteilen. Das war es aber auch schon, was HTTP anbelangt. Alles andere zum zu übertragenden Inhalt ist Aufgabe der darüberliegenden Schichten. Es ist deshalb möglich, alles mögliche über HTTP zu transportieren. Das beinhaltet also auch das, was du im zweiten Satz als Besonderheit herausstellst. Ein "typgerecht" im Sinne der Anwendung hat nichts mit HTTP zu tun, denn die Verpackung, das heißt die Definition des Formats, ist nicht Aufgabe des Transportmediums, der Transportschicht. Diese Trennung der Schichten wird nicht umsonst weitgehend praktiziert. Man will sich damit auch die Möglichkeiten offenhalten, andere Transportmedien verwenden zu können.

      Das Gegenteil von primitiv ist nicht abstrakt. Abstrakt ist auch keine Ergänzung zu primitiv. "Abstrakt" hat die Bedeutung von "vom Besonderen oder Gegenständlichen losgelöst; verallgemeinert"[1]. Neben "primitiv" wird mit "komplex" oder "zusammengesetzt" eine erweiterte Form der Datentypen benannt. Den Begriff "abstrakt" gibt es im Zusammenhang mit Datentypen auch, nur ist das nichts, was man übertragen könnte. Abstrakt ist ein Datentyp, wenn nach außen hin lediglich Schreib- oder Leseoperationen definiert sind. Wie soll man etwas transportieren, von dem nicht definiert ist, wie es im Inneren aufgebaut ist? Abstrakte Datentypen transportieren zu wollen ist nach der mir bekannten Definition ein Ding der Unmöglichkeit. Dazu braucht es eine konkrete Form, und das kann sowohl ein primitiver oder auch ein zusammengesetzter Wert sein. Es reicht nicht nur, Datentypen typgerecht zu transportieren, man sollte auch Fachbegriffe fachgerecht verwenden.

      dedlfix.


      1. https://de.wiktionary.org/wiki/abstrakt ↩︎

      1. problematische Seite

        Tach!

        Ich erkenne immer noch nicht die Motivation dahinter. Du scheinst irgendwelche Grundlagenforschung zu betreiben, für ein Problem, für das es längst diverse Lösungen gibt.

        Nein. Mir gehts eher um fachliche Begrifflichkeiten und um die Grundlagen. Ich publiziere die ja nur.

        Neben der Möglichkeit, Daten in einem proprietären Format zusammenzustellen und das als Datei zu übertragen, wenn Sender und Empfänger sich kennen und wissen, was sie da austauschen, gibt es eine Menge standardisierte Formate und Protokolle.

        Eben. Die selbstverständlich allesamt auch nur auf bereits vorhandene Standards aufsetzen. Und daß Typisierung dazu dient, den Wertebereich einer Variable festzulegen bzw, einzuschränken steht sogar in Wikipedia 😉

        HTTP ist ein Übertragungsprotokoll.

        Richtig. Und: Darunter liegt ein Socket, ein Handle, der TransportLayer. Genau hier haben wir wieder den Schluß zur Typisierung.

        MfG

        PS: Wahrscheinlich bist Du kein Programmierer.

        1. problematische Seite

          Tach!

          Nein. Mir gehts eher um fachliche Begrifflichkeiten und um die Grundlagen. Ich publiziere die ja nur.

          Aber um welches Fach gehts es dir dabei? Viele Begrifflichkeiten passen nicht zu dem Fach, das ich mit diesen Themen verbinde und die ich auch anderenorts mit einigermaßen gleichbleibender Bedeutung finde.

          Neben der Möglichkeit, Daten in einem proprietären Format zusammenzustellen und das als Datei zu übertragen, wenn Sender und Empfänger sich kennen und wissen, was sie da austauschen, gibt es eine Menge standardisierte Formate und Protokolle.

          Eben. Die selbstverständlich allesamt auch nur auf bereits vorhandene Standards aufsetzen. Und daß Typisierung dazu dient, den Wertebereich einer Variable festzulegen bzw, einzuschränken steht sogar in Wikipedia 😉

          Mag sein, hat aber mit dem Transport nichts zu tun. Da ist kein Format für die Nutzlast festgelegt, geschweige denn, dass da Typen relevant sind.

          HTTP ist ein Übertragungsprotokoll.

          Richtig. Und: Darunter liegt ein Socket, ein Handle, der TransportLayer. Genau hier haben wir wieder den Schluß zur Typisierung.

          Nee, das liegt da nicht, weil es unterschiedliche Ebenen sind, die sich um das eine oder andere kümmern. Ich finde da keinen Zusammenhang, den du da sehen möchtest. Die Schichten bauen aufeinander auf, aber sie sind nicht notwendig für die jeweils andere. Man kann auch ohne die darunter- und darüberliegenden Schichten arbeiten, solange man deren Aufgabenbereich nicht benötigt.

          PS: Wahrscheinlich bist Du kein Programmierer.

          Möglicherweise, aber vielleicht ist das wieder nur eine vom Üblichen abweichende Verwendung des Begriffs.

          dedlfix.

          1. problematische Seite

            Moin,

            was einen Programmierer unter anderem auszeichnet ist eine abstrakte Denkweise:

            Auch das Percentencoding ist ein Beispiel dafür daß es ohne eine Festlegung der Länge nicht möglich ist, aus einem prozentkodierten String wie %E2%82%AC die Oktetten des dazugehörigen Zeichen (im Beispiel das Eurozeichen) wiederherzustellen: Hexadezimal dargestellt ist jede Oktettenwertigkeit immer genau zweistellig.

            Natürlich steck auch hier, wo es um den Transport geht, wieder die Typisierung dahinter: Eine Festlegung des Wertebereiches! Wobei auf den Transport der Wirth'sche Dateibegriff selbstverständlich auch anzuwenden ist: Dateien sind Sequenzen, sie transportieren Bytes. Das heißt daß Transport und Speicherung im Grunde genommen dasselbe ist.

            Das Byte als kleinste physikalische Speichereinheit in einer Datei transportiert einen primitiven Datentyp: Einen 8 Bit Integer den es auf jedem System gibt.

            Und schau mal, was ich mir wieder für eine Mühe gegeben habe Dir zu antworten. Für diese paar Grundlagen braucht es nicht unendlich viele Fachbegriffe.

            Shöne Grüße!

            1. problematische Seite

              Tach!

              Das Byte als kleinste physikalische Speichereinheit in einer Datei transportiert einen primitiven Datentyp: Einen 8 Bit Integer den es auf jedem System gibt.

              Das nordamerikanische ISDN konnte nur 7 Bit in einem Stück übertragen. Hierzulande waren auch die dort erfundenen 56kbit/s-Modems im Einsatz, die ebenfalls auf den 7 Bit basierten, denn das ISDN bei uns war eigentlich auf 8 Bit ausgelegt und hätte 64kbit/s ergeben. Auch das E-Mail-System hängt immer noch auf seiner 7-Bit-Grundlage fest.

              Und schau mal, was ich mir wieder für eine Mühe gegeben habe Dir zu antworten. Für diese paar Grundlagen braucht es nicht unendlich viele Fachbegriffe.

              Nicht die Zahl der Fachbegriffe ist der Faktor, sondern dass ihre Verwendung zur Vemittlung der Information angemessen ist. Deine arrogante Großzügigkeit im ersten Satz kannst du aber gern weglassen. Der restliche Inhalt hat mir aber noch nicht die Frage beantwortet, warum die Datentypen der Anwendung für das Transport- oder Speichermedium relevant sein sollen. Ich sehe da nach wie vor keine Voraussetzung oder einen Zusammenhang. Bei verschlüsselten Daten zum Beispiel darf das Transportmedium keine Informationen zum eigentlichen Inhalt haben, muss es aber trotzdem fehlerfrei transportieren. Der Datenstrom muss lediglich in einer transportgerechten Form übergeben werden, die Regeln zur Konvertierung oder Interpretation muss nur der Empfänger kennen, nicht aber das Transportmedium.

              dedlfix.

              1. problematische Seite

                Hallo dedlfix,

                Das Byte als kleinste physikalische Speichereinheit in einer Datei transportiert einen primitiven Datentyp: Einen 8 Bit Integer den es auf jedem System gibt.

                Das nordamerikanische ISDN konnte nur 7 Bit in einem Stück übertragen. Hierzulande waren auch die dort erfundenen 56kbit/s-Modems im Einsatz, die ebenfalls auf den 7 Bit basierten, denn das ISDN bei uns war eigentlich auf 8 Bit ausgelegt und hätte 64kbit/s ergeben. Auch das E-Mail-System hängt immer noch auf seiner 7-Bit-Grundlage fest.

                Abgesehen davon ist die kleinste physikalische Speichereinheit sehr stark abhängig vom Medium. Auf Festplatten z.B. sind es häufig 512 Byte, auf SSDs schon 4kb. Im RAM kann, soweit ich mich erinnere, sogar nur eine ganze Row ausgelesen oder geschrieben werden.

                Ich vermute, pl meinte die kleinste adressierbare Speichereinheit. Das ist ein Byte. Wie gross das Byte ist, ist wieder abhängig von der Prozessor-Architektur. Heutzutage idR 8 Bit.

                LG,
                CK

                1. problematische Seite

                  hi

                  Abgesehen davon ist die kleinste physikalische Speichereinheit sehr stark abhängig vom Medium.

                  Das Byte gab es schon auf Lochkarten.

                  Ich vermute, pl meinte die kleinste adressierbare Speichereinheit. Das ist ein Byte. Wie gross das Byte ist, ist wieder abhängig von der Prozessor-Architektur. Heutzutage idR 8 Bit.

                  Ein Byte hatte schon immer genau 8 Bit -- Unabhängig von der Architektur!

                  MfG

                  1. problematische Seite

                    Hallo pl,

                    Abgesehen davon ist die kleinste physikalische Speichereinheit sehr stark abhängig vom Medium.

                    Das Byte gab es schon auf Lochkarten.

                    Ja.

                    Ich vermute, pl meinte die kleinste adressierbare Speichereinheit. Das ist ein Byte. Wie gross das Byte ist, ist wieder abhängig von der Prozessor-Architektur. Heutzutage idR 8 Bit.

                    Ein Byte hatte schon immer genau 8 Bit.

                    Blödsinn. Auf dem IBM 1401 hatte 1 Byte 6 Bit. Auf dem Nixdorf 820 hatte 1 Byte 12 Bit. Auf der PDP-10-Familie ist 1 Byte 1 bis 36 Bit (die Zeichenlänge konnte eingestellt werden). Auf den UNIVACs waren 9 bit gleich 1 Byte.

                    Edit: in „The Art Of Computer Programming“ hat Donald E. Knuth einen fiktiven Prozessor verwendet, bei dem 1 Byte = 6 Bit sind. Man munkelt, er wollte seine Studenten ärgern.

                    Du meinst Oktett, nicht Byte.

                    LG,
                    CK

                    1. problematische Seite

                      hi

                      Du meinst Oktett, nicht Byte.

                      Ja natürlich. Danke für den Hinweis. Was aber auch nichts an der Tatsache ändert, daß man für den Transport die Typisierung braucht, das ist das Wesentliche.

                      MfG

                    2. problematische Seite

                      hi

                      Blödsinn. Auf dem IBM 1401 hatte 1 Byte 6 Bit.

                      Nachgelesen: Die IBM 1401 gab es mit unterschiedlichen Speicherkonfigurationen (1,4K, 2K, 4K, 8K, 12K oder 16K). Ein Byte war sechs Bit lang und hatte noch ein Parity-Bit, ein zusätzliches Bit im sog. „Wortmarkenkanal“ diente zur Wortbegrenzung (Variable Wortlänge).

                      Das macht zusammen aber auch wieder 8 Bit. Was mich stark zu der Annahme bewegt, daß außerhalb des Hauptspeichers eben auch diese 8 Bit zusammengehörig transportiert wurden.

                      MfG

                      1. problematische Seite

                        Hallo pl,

                        Das macht zusammen aber auch wieder 8 Bit. Was mich stark zu der Annahme bewegt, daß außerhalb des Hauptspeichers eben auch diese 8 Bit zusammengehörig transportiert wurden.

                        Doesn't matter. Das Byte wird nicht von den Steuer-Daten definiert. Fakt ist und bleibt, dass die Grösse eines Bytes abhängig von der Rechnerarchitektur ist.

                        LG,
                        CK

                        1. problematische Seite

                          hi

                          Das macht zusammen aber auch wieder 8 Bit. Was mich stark zu der Annahme bewegt, daß außerhalb des Hauptspeichers eben auch diese 8 Bit zusammengehörig transportiert wurden.

                          Doesn't matter. Das Byte wird nicht von den Steuer-Daten definiert. Fakt ist und bleibt, dass die Grösse eines Bytes abhängig von der Rechnerarchitektur ist.

                          Und: Transport und Speicherung findet außerhalb der Rechnerarchitektur statt.

                          MfG

              2. problematische Seite

                hi

                Bei verschlüsselten Daten zum Beispiel darf das Transportmedium keine Informationen zum eigentlichen Inhalt haben, muss es aber trotzdem fehlerfrei transportieren.

                Auch Verschlüsselung ist ein Beispiel dafür daß Typisierung unumgänglich ist. Das Byte als kleinste physikalische Speichereinheit transportiert einen primitiven Datentyp! (danke übrigens Niklaus Wirth)

                D.h., verschlüsselte Daten sind nur ein Aneinanderreihung von Bytes, also Bytesequenzen. Bytes kennen keine Verschlüsselung.

                Der Datenstrom muss lediglich in einer transportgerechten Form übergeben werden, die Regeln zur Konvertierung oder Interpretation muss nur der Empfänger kennen, nicht aber das Transportmedium.

                Genau so isses! Wobei die transportgerechte Form darin besteht, Bytes aneinanderzureihen 😉

                PS: Diese Grundlagen muss sich jeder selbst erarbeiten und erst Recht den Umgang damit.

                1. problematische Seite

                  PS: Diese Grundlagen muss sich jeder selbst erarbeiten und erst Recht den Umgang damit.

                  Ganz ehrlich: muss mann das m.E. heutzutage überhaupt nicht mehr. Das letzte Mal musste ich mich damit im Informatik-Unterricht rumärgern, hat mich noch nie sonderlich interessiert.

                  Für den gewöhnlichen Webworker ist das 2018 faktisch irrelevant. Die Fragen, die Du aufwirfst, sind schon hinreichend beantwortet.

                  Zu meiner Schulzeit hätte man gesagt: Der Rolf ist irgendwie "hängen geblieben".

                  1. problematische Seite

                    hi,

                    Für den gewöhnlichen Webworker ist das 2018 faktisch irrelevant. Die Fragen, die Du aufwirfst, sind schon hinreichend beantwortet.

                    Ja: In meinem Artikel. Da geht es zwar nur um den Transport von Daten, aber gerade hieraus ergibt sich ja die Frage warum Daten überhaupt typisiert sein müssen.

                    Und ja, das Programmieren ist ein Handwerk, weil: Es muss jeder selbst erlernen. Auch mein Artikel kann nur die Grundlagen vermitteln.

                    MfG

                    1. problematische Seite

                      Hallo pl,

                      Für den gewöhnlichen Webworker ist das 2018 faktisch irrelevant. Die Fragen, die Du aufwirfst, sind schon hinreichend beantwortet.

                      Ja: In meinem Artikel.

                      weder hinreichend noch beantwortet. Wirklich nicht.

                      Bis demnächst
                      Matthias

                      --
                      Rosen sind rot.
                      1. problematische Seite

                        hi

                        Für den gewöhnlichen Webworker ist das 2018 faktisch irrelevant. Die Fragen, die Du aufwirfst, sind schon hinreichend beantwortet.

                        Ja: In meinem Artikel.

                        weder hinreichend noch beantwortet. Wirklich nicht.

                        Hier im Forum: nicht einmal ansatzweise. Das war die Frage:

                        kurzum: in welchen Fällen würde denn eine Typisierung von Parametern sinvoll sein? Mir fällt jetzt nur das Beispiel Alter ein was da ein unsigned integer (char) sein könnte, aber da gibt bestimmt noch mehr Fälle.

                        Nicht einer ist darauf eingegangen. Und jetzt guck mal, wie lang dieser Thread geworden ist! Die Frage ob das hier überhaupt noch ein Fachforum ist, kann man damit klar beantworten.

                        Darüber sollte SELFeV mal nachdenken!

                        Schönes Wochenende.

                        1. problematische Seite

                          Tach!

                          Für den gewöhnlichen Webworker ist das 2018 faktisch irrelevant. Die Fragen, die Du aufwirfst, sind schon hinreichend beantwortet.

                          Ja: In meinem Artikel.

                          weder hinreichend noch beantwortet. Wirklich nicht.

                          Hier im Forum: nicht einmal ansatzweise. Das war die Frage:

                          Das kann passieren, wenn die Frage nicht verstanden wurde und/oder keiner darauf eine Antwort hat.

                          Nicht einer ist darauf eingegangen. Und jetzt guck mal, wie lang dieser Thread geworden ist! Die Frage ob das hier überhaupt noch ein Fachforum ist, kann man damit klar beantworten.

                          Der Thread ist ja auch so lang geworden, weil wir uns übers Brötchenbacken unterhalten haben. Und natürlich geht es auch in den Antworten der anderen Threads nur um Brötchen, so dass man die Fachlichkeit des Forums klar zu beantworten ist. Alles klar.

                          Darüber sollte SELFeV mal nachdenken!

                          Was hat der Verein damit zu tun? Der Verein steuert nicht die Teilnehmer dieses Forums. Aufgabe des Vereins ist auch nicht dafür zu sorgen, dass jede Frage eine Antwort bekommt. In welche Richtung soll deiner Meinung nach eigentlich die Überlegung gehen?

                          dedlfix.