Ich brauche ein Beispiel, um zu verstehen, Implizite Markierung in ASN.1

In ASN.1-tagging, in der Tat, dient zwei Zwecken: Typisierung und Namensgebung. Typisierung bedeutet, dass es sagt, ein en-/decoder, welche Art von Datentyp ist (ist es eine Zeichenkette, Ganzzahl, boolean, set, etc.), Benennung bedeutet, dass, wenn es mehrere Felder des gleichen Typs und einige (oder alle) sind optional, es erzählt die en-/decoder für das Feld Wert ist.

Wenn Sie vergleichen ASN.1 bis, sagen wir mal, JSON, und schauen Sie sich die folgende JSON-Daten:

"Image": {
    "Width":  800,
    "Height": 600,
    "Title":  "View from 15th Floor"
}

Werden Sie feststellen, dass im JSON-jedes Feld ist immer explizit benannt wird ("Bild", "Breite", "Höhe", "Titel") und entweder explizit oder implizit typisierte ("Titel" ist eine Zeichenfolge, weil sein Wert ist in Anführungszeichen, "Breite" ist eine ganze Zahl, weil es keine Anführungszeichen, werden nur die Ziffern, es ist nicht "null", "true" oder "false", und es hat kein dezimal-Punkt).

In ASN.1 dieses Stück von Daten wäre:

Image ::= SEQUENCE { 
    Width  INTEGER,
    Height INTEGER,
    Title  UTF8String
 }

Diese arbeiten ohne Besondere Kennzeichnung, hier nur die universal-tags erforderlich sind. Universal-tags nicht Namen, Daten, Sie geben Sie einfach die Daten, so en-/decoder weiß, dass die ersten zwei Werte sind die ganzen zahlen und die Letzte ist ein string. Dass die erste Ganzzahl ist die Breite und die zweite ist in der Höhe nicht sein müssen, codiert in einem byte-stream, es ist definiert durch Ihre Bestellung (Sequenzen haben eine Feste Reihenfolge, sets nicht. Auf der Seite, die Sie genannt-sets verwendet werden).

Nun ändern Sie das schema wie folgt:

Image ::= SEQUENCE { 
    Width  INTEGER OPTIONAL,
    Height INTEGER OPTIONAL,
    Title  UTF8String
 }

Okay, jetzt haben wir ein problem. Davon ausgehen, dass die folgenden Daten erhalten:

INTEGER(750), UTF8String("A funny kitten")

Was ist 750? Breite oder Höhe? Könnte sein, die Breite (und Höhe vorhanden ist) oder könnte die Höhe (und Breite vorhanden ist), würden beide gleich Aussehen als binären Datenstrom. In der JSON, das wäre klar, wie jedes Stück der Daten, die benannt ist, die in ASN.1 ist es nicht. Jetzt ein Typ allein ist nicht genug, jetzt haben wir auch einen Namen brauchen. Das ist, wo der nicht-universellen tags geben Sie das Spiel. Ändern Sie es zu:

Image ::= SEQUENCE { 
    Width  [0] INTEGER OPTIONAL,
    Height [1] INTEGER OPTIONAL,
    Title  UTF8String
 }

Und wenn Sie erhalten die folgenden Daten:

[1]INTEGER(750), UTF8String("A funny kitten")

Sie wissen, dass die 750 ist die Höhe und nicht die Breite (es gibt einfach keine Breite). Hier deklarieren Sie einen neuen tag (in diesem Fall wird ein Kontext-spezifisch) dient zwei Zwecken: Es erzählt die en-/decoder, dass dies ist ein integer-Wert (Eingabe) und er erzählt, welche integer-Wert, der (Namensgebung).

Aber was ist der Unterschied zwischen impliziten und expliziten tagging? Der Unterschied ist, dass implizites tagging nur die Namen der Daten, die die en-/decoder muss kennen den Typ implizit für diesen Namen, beim expliziten tagging-Namen und ausdrücklich Arten der Daten.

Wenn Kategorien explizit, die Daten werden gesendet als:

[1]INTEGER(xxx), UTF8String(yyy)

also selbst wenn ein decoder hat keine Ahnung, dass [1] heißt Höhe, weiß er, dass die bytes "xxx" werden analysiert/interpretiert werden als integer-Wert. Ein weiterer wichtiger Vorteil von expliziten tagging ist, dass die Art kann in Zukunft geändert werden, ohne änderung des tag. E. g.

Length ::= [0] INTEGER

kann geändert werden, um

Length ::= [0] CHOICE { 
    integer INTEGER,
    real    REAL 
}

Tag [0] bedeutet immer noch lang, aber jetzt Länge kann entweder eine Ganzzahl oder eine Gleitkommazahl. Da ist der Typ codiert ist explizit, Decoder immer wissen, wie Sie korrekt Dekodieren des Wert, und diese änderung ist somit vorwärts und rückwärts kompatibel (zumindest auf decoder-Ebene, nicht unbedingt abwärtskompatibel auf Anwendungsebene).

Wenn Kategorien implizit ist, werden die Daten gesendet als:

[1](xxx), UTF8String(yyy)

Einen decoder, der nicht weiß, was [1] ist, wird nicht wissen, die Art von "xxx" und kann daher nicht analysieren/interpretieren, dass die Daten korrekt. Im Gegensatz zu JSON-Werte in ASN.1 sind nur bytes. Also "xxx" kann eine, zwei, drei oder vielleicht vier bytes und wie Sie zu entschlüsseln, diese bytes hängt von Ihrem Datentyp, die nicht im Datenstrom selbst. Auch die änderung der Art von [1] wird der vorhandene Decoder für sicher.

Okay, aber warum würde jemand verwenden impliziten tagging? Ist es nicht besser, verwenden Sie immer explizite-tagging? Mit expliziten tagging, der Typ muss auch codiert werden, in den Daten-stream und dies erfordert zwei zusätzliche bytes pro tag. Für Daten-übertragungen mit mehreren tausend (vielleicht sogar Millionen) tags und wo vielleicht jedes einzelne byte zählt (sehr langsame Verbindung, kleine, hohe packet loss, sehr schwache Verarbeitung Geräte) und wo beide Seiten wissen, alle benutzerdefinierten tags sowieso, warum die Verschwendung von Bandbreite, Speicher, Speicherplatz und/oder Rechenzeit zur Kodierung, übertragung und Dekodierung von unnötigen Informationen geben?

Beachten Sie, dass ASN.1 ist ein eher Alter standard und es war beabsichtigt, um zu erreichen eine sehr kompakte Darstellung der Daten, zu einer Zeit, wo die Netzwerk-Bandbreite war sehr teuer und Prozessoren, die mehrere hundert mal langsamer als heute. Wenn man sich alle XML-und JSON-Daten überträgt von heute, so scheint es lächerlich, auch nur einen Gedanken über die Einsparung von zwei bytes pro tag.

Über die akzeptierten Antworten, als ein Beispiel der Kodierung:

Image ::= SEQUENCE { 
    Width  INTEGER,
    Height INTEGER,
    Title  UTF8String
}

Ein Beispiel für die Codierung wäre:

Den internen Sequenz zerfällt in:

Explizite Optional

Wenn man dann EXPLICIT OPTIONAL Werte:

Image ::= SEQUENCE { 
    Width  [0] EXPLICIT INTEGER OPTIONAL,
    Height [1] EXPLICIT INTEGER OPTIONAL,
    Title  UTF8String
}

Die codierte Sequenz könnte sein:

• SEQUENZ 30 15 A1 02 02 02 EE 0C 0E 41 20 66 75 6E 6E 79 20 6B 69 74 74 65 6E (21-Byte)

Und die interne Sequenz zerfällt in:

• KONTEXT[1] INTEGER: A1 02 02 02 EE 750 (2-bytes)
• UTF8STRING: 0C 0E 41 20 66 75 6E 6E 79 20 6B 69 74 74 65 6E "EIN lustiges Kätzchen" (14-Byte)