KODOWANIE ZNAKÓW I PROTOKOŁÓW

Transkrypt

1 KODOWANIE ZNAKÓW I PROTOKOŁÓW - 1 -

2 Wprowadzenie do kodowania Jerzy Pejaś: Standardy i Systemy Otwarte Dlaczego kodowanie jest ważne? Protokoły sieciowe, np. protokół TCP/IP warstwy transportowej, bazują na przesyłaniu sekwencji bajtów pomiędzy portem nadającym, a portem odbierającym. Protokoły te nie będą poprawnie pracowały dotąd dopóki oba porty nie uzgodnią, jak interpretować przesyłane sekwencje oktetów. Procedura przekształcania informacji w przesyłaną sekwencję oktetów nazywana jest kodowaniem. Z kolei procedura przekształcania sekwencji oktetów do postaci struktur danych, łatwo interpretowalnych przez odbierającą aplikację, nazywana jest procesem dekodowania. Problem: Dlaczego struktura danych zdefiniowana poniżej w języku C, nie może być bezpośrednio przesłana za pośrednictwem sieci z jednego komputera na drugi? Takie przesyłanie działa przecież poprawnie w przypadku przekazywania np. struktury passanger jako parametru do dowolnej funkcji. typedef char String[80]; typedef struct flight { String airline[2]; int flightnumber; flight *nextflight; } *FLIGHTPOINTER; struct passenger { String personalname[2]; int age; - 2 -

3 }; double weight; char gender; FLIGHTPOINTER usertexts[5]; Istnieje ku temu co najmniej kilka powodów: 1. Zmienne typu String mogą być przechowywane w różny sposób w komputerze nadającym i odbierającym. Np. na niektórych komputerach bajty grupowane są w czwórki i zapisywane w 32 bitowym słowie maszynowym, i co więcej mogą przy okazji zmieniać ich kolejność (tak jest to robione w IBM PC). Oznacza to, ze przesyłając ciąg znaków, który w komputerze nadającym pamiętany jest tak: A B C D E F G H w komputerze odbierającym może zostać umieszczony w pamięci w sposób całkiem inny: D C B A H G F E 2. Różne komputery mogą przechowywać ten sam znak w inny sposób, tzn. mogą one używać różnych wzorców bitowych do reprezentacji bitowej tego samego znaku (patrz Tab.1). Tabela 1: Kodowanie znaku Ä Zbiór znaków Reprezentacja heksadecymalna znaku Ä ISO Latin One C4 Unicode (ISO 10646), UCS C4 Unicode, UTF-8 coding E2C4 CP850 (old MS-DOS) 8E ISO 6937/1 C861 Mac OS

4 3. Liczby całkowite reprezentowane są w różny sposób na różnych komputerach. Wynika to z tego, że liczby całkowite mogą być pamiętane na 16-, 32- lub 64 bitach. Dodatkowo, liczby ujemne kodowane są albo jako dopełnienie do jedynki lub dopełnienie do dwójki. 4. W odmienny sposób mogą być reprezentowane liczby zmiennoprzecinkowe: mogą mieć różną długość w bitach, różnie może wyglądać podział (w bitach) na cechę (eksponentę) i mantysę, przy czym cecha może mieć podstawę 2, 10 lub Różne komputery pamiętają w odmienny sposób zmienne typu Boolean (występuje np. w języku Pascal). W komputerach typ Boolean pamiętany jest na jednym bajcie, przy czym w niektórych przypadkach wartość TRUE reprezentuje dowolna niezerowa wartość bajtu, w innych wartość 1, to TRUE, zaś 0, to wartość FALSE. Komputer odbierający będzie miał problemy ze zmiennymi wskaźnikowymi, np. typu FLIGHTPOINTER, ponieważ nie jest w stanie bezpośrednio odwołać się do danych wskazywanych przez ten typ. Wniosek: Jeśli jeden z komputerów przesyłana dane w swojej wewnętrznej reprezentacji, to komputer odbierający, wierząc, iż odbierane dane są w jego wewnętrznej reprezentacji, może źle je zinterpretować. Pomiędzy dwoma komputerami muszą wystąpić więc procedury kodowania i dekodowania. Są one zbędne tylko w przypadku, gdy komputery te mają taką samą architekturę sprzętowo-programową. Zbiory znaków Znaki widoczne na papierze lub ekranie monitora zwykło określać się znakami widocznymi (w slangu informatyków anglojęzycznych glyph). Na przykład znakiem widocznym litery O jest pionowa elipsa, cyfry 0 bardziej wyszczuplona elipsa. Te same znaki widoczne mogą wyglądać różnie, np. A, A, A. Literze A można nadać nawet inną postać (poprzez tzw. rendering), ale nadal jest to ten sam znak - 4 -

5 widoczny. Różne postacie tego samego znaku nazywa się krojem czcionki, np. w czcionce Milano LET litera ma postać: A. Zbiorem znaków jest zbiór znaków widocznych wraz informacja mówiącą o tym jak znak jest kodowany na jednym lub więcej bajtach. Zbiór znaków pamiętany jest w postaci tworzy tzw. strony kodowej. Większość zbiorów znaków są wariantami zbioru znaków Latin, zawierającym litery od A do Z. Występują jednak całkiem odmienne zbiory znaków, np. cyrylica, znaki chińskie, japonskie, itp. Ten sam zbiór znaków może mieć więcej niż jeden sposób kodowania, zależny od określonego zbioru znaków. Występuje także dodatkowe kodowanie stosowane przez niektóre protokoły do sekwencji przesyłanych bajtów. Tabela 2: Najbardziej znane zbiory znaków - 5 -

6 - 6 - Jerzy Pejaś: Standardy i Systemy Otwarte

7 Tabela 2: Najbardziej znane zbiory znaków (c.d.) Kodowanie UTF-8 zdefiniowanie w normie ISO Norma ISO definiuje tzw. Universal Character Set (w skrócie Unicode lub UCS). Bazuje on na zbiorze 31-bitowych znaków, którego liczność może teoretycznie wynosić 2 31 znaków

8 Do chwili zdefiniowano tylko znaki (pozycje od 0x0000 do 0xFFFD). Ten 16-sto bitowy podzbiór nazywany jest Basic Multilingual Plane (BMP). Heksadecymalne numery, które reprezentują kody UCS poprzedzane są umownie zawsze znakami U+. Sąd np. znaki US-ASCII oznaczane są w UCS jako znaki z przedziału od U+0000 do U+007F. UCS jest przede wszystkim tabelą kodów, które przypisują liczby całkowite znakom. Istnieje kilka alternatywnych sposobów reprezentowania tego typu przyporządkowania. Dwa najbardziej rozpowszechnione sposoby kodowania przechowują teksty UCS jako sekwencje 2 lub 4 bajtów. Oficjalne okreśłenia tych spsobów kodowania to UCS-2 i UCS-4. Stosowanie kodowania UCS-2 i UCS-4 stwarza wiele problemom zwłaszcza programistom C. W kodach tych występują często bajty o wartości \0, które w C maja specjalne znaczenie jest to koniec napisu tekstowego (stringu). Tego typu problemów nie ma z kodowaniem UTF-8 (UCS Transformation Format), opisanym w dodatku R normy ISO oraz RFC Kodowanie UTF-8 ma następujące własności: 1. znaki UCS od U+0000 do U+007F kodowane sa na jednym bajcie jako wartości od 0x00 do 0x7F, 2. wszystkie znaki UCS wieksze od U+007F są kodowane jako sekwencja kilku bajtów, z których każdy ma ustawiony najbardziej znaczący bit, 3. pierwszy bajt sekwencji wielobajtowej, który reprezentuje znak nie należący do ASCII, ma zawsze wartość z zakresu od 0xC0 do 0xFD, i wskazuje ile bajtów tworzy ten znak. Wszystkie pozostałe znaki należą do zakresu 0x80 0xBF. 4. Teoretycznie UTF-8 umożliwia kodowanie znaku na maksymalnie 6 bajtach, znaki należące do zbioru BMP kodowane są jednak tylko na maksymalnie 3 bajtach

9 5. Do zbioru kodów UTF-8 nie należą nigdy dwa bajty: 0xFE i 0xFF. Pierwszy z bajtów 0xFE jest używany jako oznaczenie (kod) UTF-8, zaś 0xFF oznacza kodowanie UCS. Kody te umieszcza się zwykle np. na początku pliku, w którym umieszcza się następnie znaki tekstu, zapisane w kodzie UTF-8 lub UCS. W Tab.3 przedstawiono sekwencje bajtów, które reprezentują kody UCS zapisane w UTF-8. Tabela 3: Translacja kodów UCS-4 na UTF-8 Przykład: Znak Copyright należący do BMP kodowany jest jako U+00A9 = Korzystając z Tab.3 znak ten w UTF-8 można zakodować następująco: = 0xC2 0xA9 Kodowanie tekstowe i binarne Wyróżnia się dwie główne metody kodowania: metoda tekstowa wszystkie informacje przed przesłaniem do komputera odbierającego przekształcane są do formatu tekstowego. Np. liczba rzeczywista przekształcana jest do postaci napisu tekstowego " " i następnie kodawana przy zastosowaniu załóżmy ISO Latin

10 metoda binarna informacja przekształcana jest do zestandaryzowanego formatu binarnego, niezależnego od architektury komputera. Np. w przypadku liczby binarnej można podstawę systemu obliczeń, mantysę oraz cechę oddzielnie przekształcić do postaci napisu binarnego (ang. binary string), zawierającego znaki 1 i 0 i przesłać poprzez łącza. Także każdy dowolny napis tekstowy można przesłać jako napis binarny. Przykładami protokołów, które korzystają z metody tekstowej jest SMTP (Simple Mail Transfer Protocol), HTTP (Hypertext Transfer Protocol). Z metody binarnej korzystają z kolei protokoły: LDAP (Lightweight Directory Access Protocol), DNS (Domain Naming System). Kodowanie struktur informacyjnych W sieci przesyłane są nie tylko proste typy danych takie jak liczby lub napisy tekstowe, ale także struktury informacyjne. Struktura informacyjna wskazuje: gdzie jeden element danych kończy się, a zaczyna następny, jaki rodzaj informacji zawarty jest w elemencie danych, np. czy liczba oznacza temperaturę, prędkość lub kierunek, które z elementów danych należą do tej samej struktury informacyjnej, np. która temperatura, prędkość oraz kierunek tworzą strukturę oznaczająca pomiar parametrów wiatru w określonej chwili czasu

11 Kodowanie początkowego i końcowego elementu danych W Tab.4 przedstawiono niektóre metody kodowania elementu początkowego i końcowego. Każda z tych metod posiada swoje zalety oraz wady. Tabela 4: Kodowanie elementu początkowego i końcowego

12 Kodowanie o stałej długości polega na zarezerwowaniu ściśle określonego rozmiaru każdego elementu danych. Np. rok można kodować tylko jako ostatnie dwie cyfry (i zarezerwować na to tylko 7 bitów), ale wynik takiego założenia jest znany - Y2K (problem roku 2000). Kodowanie długości każdy wysyłany element danych poprzedzany jest liczbą przesyłanych oktetów. Kodowanie to może stwarzać problem w przypadku przesyłania dużej, z góry nieznanej liczby oktetów. Przykład: przesyłanie głosu lub obrazu wideo. Ogranicznik kodowania każdy przesyłany element kończony jest z góry określonym znakiem ograniczającym, np. średnikiem. Problem: nie można umieszczać znaku ogranicznika w treści przesyłanego elementu. Aby obejść to ograniczenie stosuje się różne metody, np.: wprowadza się specjalny znak poprzedzający (tzw. escape), np. jeśli jako ogranicznika użyto znaku ; i aby można było użyć go w napisie o postaci abc;def, to należy poprzedzić go np. znakiem \, abc\;def. A co zrobić w przypadku napisu a\bc\;def? Zakodować należy także znak \, co prowadzi do następującego ciągu: a\\bc;def. Wymaga się powtórzenia znaku poprzedzającego, np. jeśli znakiem poprzedzającym jest ", to napis ab"bc" "de jest kodowany następująco: ab""bc"" ""de. Objęcie danych znakiem cudzysłowia i powtarzanie duplikowanie dowolnego znaku cudzysłowia w tekście. Np. napis ab"bc""de jest kodowany następująco: "ab""bc""""de". Przykład: protokół SMTP. Kodowanie danych przy pomocy ograniczonego zbioru znaków i używanie w roli ogranicznika dowolnego znaku spoza tego zbioru. Przykłądami tego typu jest kodowanie BASE64 oraz UUENCODE

13 Kodowanie znaków specjalnych przy pomocy sekwencji znaków, które zawierają numeryczną wartość kodu znaku. Przykłady: (a) (b) (c) (d) metoda kodowania oparta na cytowaniu znaku drukowalnego (ang. quoted-printable encoding method), np. w protokole MIME znak Ä kodowany jest jako =C4, ponieważ C4 jest heksadecymalna wartością tego znaku, metoda kodowania jednostki znaku HTML (ang. HTML Character Entity encoding method) - znak Ä kodowany jest jako Ä, gdzie 196 jest dziesiętną wartością tego znaku, metoda kodowania nagłówka MIME (ang. MIME header encoding method) - znak Ä kodowany jest jako =?iso ?q?=c4?=, gdzie iso oznacza zbiór znaków ISO Latin 1, q mówi, że zastosowano metodę kodowania opartą na cytowaniu znaku drukowalnego, zaś =C4 zawiera wartość, która wynika z przyjętej metody kodowania, metoda kodowania URL - znak Ä kodowany jest jako %C4, gdzie C4 jest heksadecymalna wartością znaku Ä należącego do zbioru ISO Latin 1. Kodowanie znaków specjalnych jako sekwencji pewnych znaków, które opisują słownie znaczenie znaku. Przykładem może być znak Ä, który w HTML kodowany jest jako Ä, gdzie Auml oznacza A with umlaut. W pewnych przypadkach należy zastosować metodę, która jest kombinacją innych. Komputer nadający koduje przy pomocy jednej metody, wynik przekazuje drugiej metodzie, itp., by w końcu ostateczny wynika przesłać komputerowi odbierającemu. Komputer odbierający dekoduje otrzymana informacje w

14 kolejności odwrotnej do tej, którą stosował komputer nadający. Rys.1 ilustruje ten proces na przykładzie przesyłania poczty. Rys.1 Metody kodowani w różnych warstwach

15 Kodowanie danych binarnych przy pomocy kodowania tekstowego Problem: jak przesyłać dane binarne, np. kod programu wykonywalnego, przy wykorzystaniu kodowania tekstowego? Istnieją dwie metody: Jeśli do dyspozycji mamy ośmiobitowy kanał transportowy, to możemy po prostu podzielić dane binarne na części po osiem bitów (oktety) i przesłać je w takiej postaci jakiej się znajdują. Przesyłanie tego typu łączy się zwykle z metodą kodowania długości w celu oznaczenia końca binarnego elementu danych. Dane binarne koduje się jako tekst. Stosuje się przy tym dwa podejścia: UUENCODE i BASE64. Kodowanie BASE64 jest bardziej niezawodne i przebiega następująco: Weź trzy kolejne oktety (24 bity), podziel je na cztery 6 bitowe części, a następnie zakoduj każde 6 bitów jako jeden znak (bajt). Ponieważ na 6 bitach można zapisać 64 różnych wartości, stąd w procesie kodowania niezbędnych jest tylko 64 różnych znaków. Znaki te zostały wybrane spośród tych znaków ASCII, które znane są jako znaki niezaburzające procesu przesyłania po łączach

16 Kodowanie struktur informacyjnych Często zachodzi konieczność przesyłania złożonych zbiorów wzajemnie powiązanych elementów informacyjnych, np.: typedef char String[80]; typedef struct { String givenname; String surname; } Name; struct PersonalRecord { int age; double weight; Name name; } Do kodowania tego typu złożonych struktur najczęściej stosowane są dwie metody: (a) kodowanie znacznika-długości-wartości, kodowanie TLV (ang. tag-length-value encoding, TLV encoding) oraz (b) kodowanie tekstowe. Kodowanie TLV Każdy element struktury danych dzielony jest na trzy części: (1) znacznik (ang. tag), który umożliwia określenie, czy to jest np. wiek, waga, nazwa, nazwisko i imię, (2) długość (ang. length), określająca liczbę oktetów niezbędną do zapisania wartości elementu danych, (3) wartość (ang. value)

17 Kodowanie TLV może umożliwia realizację kodowania zagnieżdżonego, tzn. TLV może zawierać inne TLV (patrz rys.2). Przykład kodowania rozważanej przykładowej struktury informacyjnej PersonalRecord przedstawiony jest w Tab.5. Rys.2 Przykład zagnieżdżonego kodowania TLV

18 Kodowanie tekstowe Przy zastosowaniu kodowania tekstowego wiadomości zawarte w strukturze PersonalRecord można zakodować jako następujący napis tekstowy (<CR/LF> oznacza znak powrotu karetki i nowej linii). lub Age: 58; Weight: 45.6; Name: Jan, Kowalski <CR/LF> Age: 58 <CR/LF> Weight: 45.6 <CR/LF> Name: <CR/LF> Given name: Jan <CR/LF> Surname: Kowalski <CR/LF> Przykładem kodowania tekstowego nagłówek standardowej poczty elektronicznej. Received: from mail.ietf.net <CR/LF> by info.dsv.su.se (8.8.8/8.8.8) with ESMTP <CR/LF> id HAA06480 for <jpalme@dsv.su.se>; <CR/LF> Wed, 22 Jul :51: <CR/LF> Message-ID: <AF4C1AD5F2ED305D823AF@ietf.net> <CR/LF> From: Erik Nielsen <erikn@ietf.net> <CR/LF> To: Jacob Palme <jpalme@dsv.su.se> <CR/LF> Subject: Example of an header <CR/LF> Date: Tue, 24 Jul :25: <CR/LF> W kodowaniu tekstowym używa się zwykle znaków ogranicznika kodowania. W powyższym przykładzie w tej roli użyto: ":", ";", "<", ">", "from", "by", "id", " ". Słowa: Message-ID, Received, From, To, Subject i Date są znacznikami, zaś w polu Received występują podznaczniki from, by i id

19 Tabela 5: Przykład kodowania TLV

20 Tabela 5: Przykład kodowania TLV (c.d.)

21 Zaawansowane metody kodowania Jerzy Pejaś: Standardy i Systemy Otwarte W przypadku definiowania specyfikacji protokołów korzysta się zwykle ze specjalnych języków (notacji). W praktyce używane są trzy tego rodzaju języki: ABNF, ASN.1 i XML. Rozszerzona notacja Backus-Naura ABNF (ang. Augmented Backus-Naur Form) Notacja ABNF została po raz pierwszy znormalizowana w RFC 822, a następnie zmodyfikowana w RFC ABNF (jak również ASN.1) bazują na notacji BNF, użytej w 1958 podczas specyfikacji języka Algol 60. Rozpatrzmy analizowany już poprzednio rekord: Age: 58; Weight: 45.6; Name: Jan, Kowalski <CR/LF> i zapiszmy go w notacji ABNF personal-record = age "; " weight "; " name CR LF age = "Age: " integer weight = "Weight: " decimal-value name = given-name "," surname given-name = 1*LETTER ; one or more letters surname = 1*LETTER integer = 1*D ; one or more digits decimal-value = 1*D "." 0*D ; zero or more decimals

22 Podstawowe konstrukcje składniowe notacji ABNF Konstrukcja albo-albo definiowana jest przy użyciu znaku "/" i oznacza wybór jednej z dwóch możliwości answer = "Answer: " ("Yes" / "No") określa następujące dwie alternatywne wartości Answer: Yes i Answer : No Sekwencje elementów tego samego typu (powtórzenia) umożliwiają definiowanie liczbę powtórzeń danego elementu. Pełnia postać składni jest następująca: <a>*<b>element gdzie <a> i <b> są opcjonalnymi liczbami całkowitymi, określającymi ile co najmniej i ile co najwyżej razy powtórzony zostanie element. Domyślnymi wartościami a i b są odpowiednio 0 i nieskończoność. Stąd zapis *(element) oznacza dowolna lczbe powtórzeń elementu. Przykłady: yes-no-series = *("yes" / "no") five-yes-no-series = 5*5("yes" / "no") one-to-five-yes-no-series = 1*5("yes" / "no") Komentarz w ABNF zaczyna się od znaku średnika i kończy się za ostatnim znakiem w wierszu. Reguła w notacji ABNF definiowana jest jako następująca sekwencja: name = elements crlf gdzie <name> jest nazwą reguły, <elements> - jedną lub wieloma nazwami reguł lub specyfikacja końcowa, zaś <crlf> oznacza koniec linii

23 Elementy <elements> ujęte we wspólną pare nawiasów traktowane sa jako pojedynczy element. Stąd np.: "(elem (foo / bar) elem)" oznacza ciąg: lub "elem foo elem" "elem bar elem" Przykład z RFC 822: authentic = "From" ":" mailbox ; single author / ("Sender" ":" mailbox; actual submittor "From" ":" 1*("," LWSP mailbox)) Wartości końcowe - reguły rozwijane są (zapisywane) do postaci ciągów wartości końcowych, nazywanych czasami znakami. W notacji ABNF znak jest po prostu nieujemna liczba całkowitą. Wartości końcowe oznaczane są przez jeden lub więcej znaków numerycznych (cyfr), poprzedzone znakiem bazowym, interpretującym ten ciąg znaków. Dostępne są następujące znaki bazowe: b = binarny d = decymalny x = heksadecymalny Stąd np. CR = %d13 CR = %x0d

24 oznacza dziesiętną i heksadecymalną reprezentację kodu ASCII znaku powrotu karetki. Wartości końcowe można łączyć, używając w tym celu znaku kropki. Na przykład: CRLF = %d13.10 Notacja ABNF dopuszcza bezpośrednie definiowanie literałów tekstowych, zawartych pomiędzy znakami cudzysłowów: command = "Ala Ma kota" Liniowe białe znaki (LWSP) umożliwiają określenie zero, jednego lub więcej białych znaków, które mogą następnie wyświetlenie na ekranie. LWSP = *(WSP / CRLF WSP) ; linear white space (past newline) CR = %x0d ; carriage return CRLF = CR LF ; Internet standard newline LF = %x0a ; linefeed WSP = SP / HTAB ; white space SP = %x20 HTAB = %x09 ; horizontal tab Przy zastosowaniu LWSP można np. napisać: yes-no-series = *(("yes" / "no") LWSP) co umożliwia utworzenie m.in. takich napisów: "yes " "yes no " "no" "yes yes yes " "" "yes yes no "

25 Konkatenacja jest regułą, która definiuje uporządkowany ciąg wartości, np. znaków, poprzez pokazanie sekwencji nazw reguł, np. foo = %x61 ; a bar = %x62 ; b mumble = foo bar foo Alternatywa elementy rozdzielone znakiem "/". Stąd np. foo / bar oznacza akceptację foo lub bar. Zakres wartości definiowany jest przy użyciu znaku "-". Na przykład DIGIT = %x30-39 jest równoważny alternatywie znaków DIGIT = "0"/"1"/"2"/"3"/"4"/"5"/"6"/ "7"/"8"/"9" Podsumowanie notacji ABNF Oznaczenie / n*m(element) n*n(element) n*(element) *n(element) n#m(element) Znaczenie either or Repetition of between n and m elements Repetition exactly n times Repetition n or more times Repetition not more than n times Same as n*m but comma-separated

26 [ element ] Optional element,same as *1(element) Oznaczenie Znaczenie Yes /No Either Yes or No 1*2(DIGIT) One or two digits 2*2(DIGIT) Exactly two digits 1*(DIGIT) A series of at least one digit *4(DIGIT) Zero,one,two,three or four digits 2#3("A") A,A or A,A,A [ "";"para ] The parameter string can be included or omitted ; Text from a semicolon (;)to the end of a line is a comment Przykłady zastosowania ABNF Przykład 1 z RFC 822: LWSP-char = SPACE / HTAB ; Przykład 2 z RFC 822: mailbox = addr-spec ; simple address / phrase route-addr ; name & addr-spec addr-spec = local-part "@" domain ; global address phrase = 1*word ; Sequence of words word = atom / quoted-string

27 Zapis ten spełniają następujące sekwencje znaków: Jerzy Pejas Przykład 3 z RFC 822: optional-field = / "Message-ID" ":" msg-id / "Resent-Message-ID" ":" msg-id / "In-Reply-To" ":" *(phrase / msg-id) / "References" ":" *(phrase / msg-id) / "Keywords" ":" #phrase / "Subject" ":" *text / "Comments" ":" *text / "Encrypted" ":" 1#2word / extension-field ; To be defined / user-defined-field ; May be pre-empted Zapis ten spełniają następujące sekwencje znaków: In-Reply-To: <12345*jerzy.pejas@wi.ps.pl> In-Reply-To: <12345*jerzy.pejas@wi.ps.pl> <5678*jerzy.pejas@wi.ps.pl> In-Reply-To: Your message of July 26 <12345*jerzy.pejas@wi.ps.pl> Keywords: flowers, tropics, evolution Przykład 4 z RFC 822 (ilustruje użycie nawiasów [ ] - opcji): received = "Received" ":" ; one per relay

28 ["from" domain] ; sending host ["by" domain] ; receiving host ["via" atom] ; physical path *("with" atom) ; link/mail protocol ["id" msg-id] ; receiver msg id ["for" addr-spec] ; initial form Zapis ten spełniają następujące sekwencje znaków: Received: from mars.su.se (root@mars.su.se ) by zaphod.sisu.se (8.6.10/8.6.9) with ESMTP id MAA29032 for cecilia@sisu.se Skaner leksykalny notacji ABNF Pod pojęciem skanera leksykalnego rozumie się najniższy poziom składni, reguły rozpoznawania znaków i składania je w słowa. Poniżej przedstawiono skaner leksykalny zaczerpnięty z RFC 822 ilustrujący jak taki skaner może zostać użyty do zdefiniowania ABNF. CHAR = <any ASCII character> ; ( 0-177, ) ALPHA = <any ASCII alphabetic character> ; ( , ) ; ( , ) DIGIT = <any ASCII decimal digit> ; ( 60-71, ) CTL = <any ASCII control ; ( 0-37, ) character and DEL> ; ( 177, 127.) CR = <ASCII CR, carriage return> ; ( 15, 13.) LF = <ASCII LF, linefeed> ; ( 12, 10.)

29 SPACE = <ASCII SP, space> ; ( 40, 32.) HTAB = <ASCII HT, horizontal-tab> ; ( 11, 9.) <"> = <ASCII quote mark> ; ( 42, 34.) CRLF = CR LF LWSP = SPACE / HTAB ; semantics = SPACE Przedstawiony powyżej zapis używa raczej tekstu otwartego aniżeli notacji ABNF. Wersja ABNF z 1997 roku zawiera konstrukcje, które umożliwiają zapisanie skanera tylko przy zastosowaniu: ALPHA = %x41-5a / %x61-7a ; A-Z / a-z BIT = "0" / "1" CHAR = %x01-7f ; 7-bit US-ASCII character, excl. NUL CR = %x0d ; carriage return CRLF = CR LF ; Internet standard newline CTL = %x00-1f / %x7f ; controls DIGIT = %x30-39 ; 0-9 DQUOTE = %x22 ; " (Double Quote) HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" HTAB = %x09 ; horizontal tab LF = %x0a ; linefeed LWSP = *(WSP / CRLF WSP) ; linear white space (past ; newline) OCTET = %x00-ff ; 8 bits of data SP = %x20 Notacja ASN.1 (ang. Abstract Syntax Notation One) Abstract Syntax Notation One (ASN.1) jest notacją wykorzystywaną do opisu wiadomości wymienianych pomiędzy komunikującymi się aplikacjami

30 Dostarcza mechanizmy opisu danych na wysokim poziomie, które zwalniają projektanta od konieczności operowania na poziomie bitów i bajtów. Notacja ASN.1 opracowana została przez ITU-T w roku 1988 i przyjęta jako rekomendacja X.208 (odpowiednik ISO/IEC : 1993). W roku 1997 opracowano obiektową wersję ASN.1, która przyjęła w postać rekomendacji X.680 (ISO/IEC :1998). Zasady kodowania ASN.1 są zbiorem reguł, umożliwiających przekształcenie danych z notacji ASN.1 do standardowego formatu, który może być zdekodowany przez dowolny system, posiadający dekoder pracujący w oparciu o ten sam zbiór reguł. Zasady kodowania/dekodowania są unormowane i przedstawione w normie ISO/IEC 8825 (X.690 i X.691). Aktualnie w użyciu są następujące formaty kodowania: Basic Encoding Rules (BER), Distinguished Encoding Rules (DER), Canonical Encoding Rules (CER), Packed Encoding Rules (PER), Light Weight Encoding Rules (LWER) Ogólne informacje na temat ASN.1 Notacja ASN.1 jest alternatywą do notacji ABNF, stosowana przy opisie złożonych struktur. O ile jednak ABNF używana jest najczęściej do kodowania tekstowego, to ASN.1 znajduje zastosowanie głównie przy kodowaniu binarnym

31 Określony zapis struktury w notacji ASN.1 można w różny sposób przekształcić do postaci binarnej (BER, DER, itp.). Najszerzej stosowane jest kodowanie BER. Główna zasada notacji ASN.1 mówi, że nowe typy danych mogą być definiowane przy użyciu typów prostszych. Dalej zobaczymy, jak jest to robione. Przykład: Załóżmy, że chcemy przesyłać temperaturę mierzoną przez nasze urządzenie w stopniach Kelvina. Temperatura jest wielkością rzeczywistą i może być kodowana na wiele sposobów. W standardzie ASN.1 można zapisać to następująco: Temperature ::= REAL -- w stopniach Kelvina Zapis ten mówi jednak tylko tyle, że temperatura jest typu REAL (zmienna rzeczywista) i powinna zostać zakodowana tak samo jak każda inna liczba zmiennoprzecinkowa. Typ REAL, podobnie jak inne typy: INTEGER, BOOLEAN, STRING, etc. Jest typem wbudowanym w ASN.1 Informację, której nie jesteśmy w stanie formalnie zakodować, możemy podawać w formie komentarza poprzedzonego znakami "--" (patrz przykład powyżej). Skąd więc odbiorca po otrzymaniu przesłanej wartości będzie wiedział, że wartość ta należy interpretować jako temperaturę (i to jeszcze jako temperaturę w stopniach Kelvina), a nie jako np. prędkość wiatru lub wilgotność powietrza? Jednym ze sposobów jest wprowadzenie tzw. znaczników (ang. tag). Znacznik jest etykieta, która jest przesyłaną przed wartościami danych i oznacza jaki typ danych jest przesyłany. W naszym przypadku definicja z użyciem znacznika może mieć postać: Temperature ::= [APPLICATION 0] REAL -- w stopniach Kelvina

32 Zapis ten oznacza, że w aplikacji przesyłającej dane o temperaturze użyliśmy znacznika [APPLICATION 0] na oznaczenie, że występujące po nim dane oznaczają temperaturę w stopniach Kelvina. Innych znaczników możemy użyć na oznaczenie prędkości wiatru i wilgotności powietrza: Temperature ::= [APPLICATION 0] REAL WindVelocity ::= [APPLICATION 1] REAL Humidity ::= [APPLICATION 2] REAL Powyższe zapisy definiują trzy nowe typy Temperature, WindVelocity i Humidity. Definicja Temperature ::= [APPLICATION 0] REAL określa nowy typ danych, zbudowany na bazie typu wbudowanego REAL. Przy zastosowaniu bezpośrednich znaczników oba znaczniki przesyłane są w postaci: Czasami wymaga się, aby nowy typ danych był kombinacją kilku innych typów. Na przykład liczba zespolona może być kodowana jako kombinacja dwóch wartości rzeczywistych: ComplexNumber ::= [APPLICATION 3] SEQUENCE { imaginarypart REAL, realpart REAL }

33 Zdefiniowane nowe typy danych mogą być podstawą budowania kolejnych typów danych. Np.: WeatherReading ::=[APPLICATION 4 ] SEQUENCE { temperaturereading Temperature, velocityreading WindVelocity, humidityreading Humidity } Ten ostatni typ możemy wykorzystać do przesłania serii odczytów parametrów pogody, dokonanych na różnych wysokościach nad poziomem morza. Można w tym celu zbudować nowy typ SeriesOfReadings: SeriesOfReadings ::=[APPLICATION 5 ] SEQUENCE OF AltituteReading AltitudeReading ::=[APPLICATION 6 ] SEQUENCE { altitude Altitude, weatherreading WeatherReading } Altitude ::=[APPLICATION 7 ] REAL -- Meters above sea levelc Powyższa definicja składa się z trzech produktów (typów) ASN, z których każdy odwołuje się do produktów zdefiniowanych później (podejście od ogółu do szczegółu, ang. top-down). Tego typu uporządkowanie nie jest konieczne, ale z pewnością ułatwia odczyt definiowanych typów. Rozważane definicje umożliwiają przesłanie danych w postaci ciągu bitów (ciągu oktetów), który wygląda następująco:

34 Jerzy Pejaś: Standardy i Systemy Otwarte

35 Oznaczenia stałych w ASN.1 Chociaż informacja przesyłana pomiędzy dwoma komputerami nie składa się zwykle z wartości stałych, to jest oczywiste, że notacja ASN.1 musi pozwalać na zapis wielkości zarówno stałych, jak i zmiennych. Definicje stałych wykorzystywane są najczęściej podczas definiowania innych typów ASN.1. Np. zamiast pisać: Windowline ::= GeneralString (SIZE (80)) możemy zdefiniować stałą i następnie użyć jej: Windowline ::= GeneralString (SIZE (linelength)) linelength ::= 80 Terminologia ASN.1 Typem lub typem danych jest zbiór dozwolonych wartości. Typ może zostać zdefiniowany poprzez wyliczenie wszystkich dozwolonych wartości lub zdefiniowany tak, że może przybierać nieskończoną liczbę wartości (podobnie jak typ INTEGER lub REAL) Nowy typ zdefiniowany na bazie elementów zdefiniowanych poprzednio nazywany jest typem strukturalizowanym. Przykład definicji typu strukturalizowanego: ComplexNumber::= [APPLICATION 3] SEQUENCE { imaginarypart REAL, realpart REAL }

36 Specyfikacja składni notacji ASN.a nazywana jest składnią abstrakcji. Z kolei składnia stosowana w aktualnie realizowanej wymianie danych pomiędzy dwoma stronami określana jest mianem składni przesyłu. Specyfikacja określająca w jaki sposób składnia abstrakcji przekładana jest na składnię tworzy zasady kodowania. Przykładem takich zasad jest kodowanie BER. Produkt (typ) ASN.1 jest reguła (zasadą) definiowania jednego typu na bazie typów już zdefiniowanych. Składnia budowania produktu ASN.1 ma postać: nazwa nowego typu (musi zaczynać się z dużej litery, A-Z), operator ::=, definicja nowego typu. Komentarz Komentarz w ASN.1 rozpoczyna się dwoma kolejnymi znakami myślnika "--", zaś kończy także dwoma znakami "--" lub znakiem nowej linii. Typy predefiniowane, wbudowane w ASN.1 Typy proste Typy znakowe, napisy Typy strukturalizow ane Typy pomocnicze BOOLEAN NumericString SET GeneralizedTime INTEGER PrintableString SET OF UTCTime ENUMERATED TeletexString SEQUENCE EXTERNAL REAL VideotexString SEQUENCE OF BIT STRING VisibleString CHOICE

37 OCTET IA5String ANY STRING NULL GraphicString [Tagged ] OBJECT IDENTIFIER GeneralString UniversalString BMPString UTF8String CharacterString <Różne warianty ISO 10646, <nie występujące w wersji z <roku 1998 Uwaga: W przypadku typów Graphic, General,Universal, BMP i UTF8 rekomendowane jest stosowanie ograniczeń Format identyfikatorów Nazwy pól oraz nazwy stałych muszą rozpoczynać się z małej litery (a-z). Nazwy typów z kolei rozpoczynają się z dużej litery (A-Z). W notacji ASN.1 rozróżniane są więc duże i małe litery. Nazwa może składać się jedynie z małych liter (a-z), dużych liter (A-Z) i znaku myślnika "-". Typy proste Typ INTEGER określa zbiór liczb całkowitych (ujemnych, zero i dodatnich). W przeciwieństwie do języków programowania, w których reprezentacja liczb typu całkowitego ograniczona jest do 32 lub 64 bitów, w notacji ASN.1 nie nakłada się żadnych ograniczeń na liczbę bitowej reprezentacji typu

38 INTEGER (liczba ta nie posiada predefiniowanych wartości minimalnej i maksymalnej). Przykład definicji: Number-of-years ::=INTEGER Weekday ::=INTEGER {monday(1), tuesday(2), wednesday(3), thursday(4), friday(5), saturday(6), sunday(7)} Ostatni z zapisów nie ogranicza wartości Weekday jedynie do wartości 1-7; zmienna tego typu może przyjmować dowolną wartość całkowitą. Podtypy. W ASN.1 można ograniczać zakres wartości zmiennych. Dotyczy to zwłaszcza typu INTEGER. Przykład: Weekday ::=INTEGER {monday(1), tuesday(2), wednesday(3), thursday(4), friday(5), saturday(6), sunday(7)} (1..7) Podtypy określane są w nawiasach okrągłych, umieszczanych po definicji typu. W przypadku typu INTEGER dostępne są następując polecenia, określające podtypy: Przykład +0%.7&'59GGMFC[ ^ Opis 9U\[UVMKGYCTVQśEKRQOK EKRQOKęF\[YCTVQ F\[YCTVQśEK EKąFQNP FQNPą CIóTP TPą 2QLGF[PE\CYCTVQść 9U\[UVMKGYCTVQśEKQMTG EKQMTGśNQPGRT\G\V[R 9GGMFC[.KUVCYCTVQśEKQFF\KGNQP[EJQFUKGDKG \PCMKGO^

39 Inne konstrukcje, które umożliwiają definiowane podtypów typów różnych INTEGER zostaną podane dalej. Przykłady definicji podtypów (MAX lub MIN oznacza brak ograniczeń nałożonych na dany typ): OddSingleDigitPrimes ::= INTEGER (3 5 7 ) SingleDigitPrimes ::= INTEGER (2 INCLUDES OddSingleDigitPrimes ) PositiveNumber ::= INTEGER (1..MAX ) Month ::= (1..12) Month ::= (1..<13 ) Typ BOOLEAN. Typ BOOLEAN może przyjmować tylko dwie wartości TRUE i FALSE. Przykład: ShopOpen ::= BOOLEAN Definicja typu BOOLEAN nie może przybierać np. postaci: Gender ::= BOOLEAN {male (TRUE),female (FALSE)} Stałe male i female można jednak zainicjować tak: Gender ::= BOOLEAN male Gender ::= TRUE female Gender ::= FALSE Typ wyliczeniowy ENUMERATED. Typ wyliczeniowy może przybierać jedynie wartości, które zostały określone w trakcie jego definicji. Składania typu ENUMERATED jest podobna do typu INTEGER. Przykład:

40 DayOfTheWeek ::=ENUMERATED { monday (1), tuesday (2), wednesday (3), thursday (4), friday (5), saturday (6), sunday (7) } Różnica pomiędzy typem ENUMERATED, a INTEGER sprowadza się do tego, że wartości typu ENUMERATED nie są uporządkowane. Z tego powodu poniższej konstrukcji (definiowania podtypu) nie da się powtórzyć z użyciem ENUMERATED: WeekDayNumber ::=INTEGER { monday (1), tuesday (2), wednesday (3), thursday (4), friday (5),saturday (6), sunday (7) } WorkingDayNumber ::=WeekDayNumber (1..5 ) Należy w tym celu użyc innego sposobu określenia podtypu: WorkingDay ::=DayOfTheWeek (monday tuesday wednesday thursday friday saturday sunday ) Porównajmy trzy przedstawione poniżej definicje typu DayOfTheWeek: (1) DayOfTheWeek ::= INTEGER { monday(1),tuesday(2),wednesday(3),

41 } thursday(4),friday(5),saturday(6), sunday(7) (2) DayOfTheWeek ::= INTEGER { monday(1),tuesday(2),wednesday(3), thursday(4),friday(5),saturday(6), sunday(7) }(1..7) (3) DayOfTheWeek ::=ENUMERATED { monday(1),tuesday(2),wednesday(3), thursday(4),friday(5),saturday(6), sunday(7) } Przypadek (1) umożliwia przypisanie definiowanemu typowi dowolnej wartości całkowitej, w przypadku (2) zakres wartości został przycięty do zakresu od 1 do 7, przypadek (3) uniemożliwia określenie kolejności w obrębie typu DayOfTheWeek. Typ REAL umożliwia posługiwanie się następującymi poprawnymi wartościami: +,-- oraz wartościami postaci, zapisywanymi w postaci M B *E, gdzie M i E mogą być dowolnymi wartościami typu INTEGER, zaś B może przyjmować jedynie wartości 2 lub 10. Przykład 1 (wg notacji z 1994):

42 pi REAL ::= { mantissa , base 10, exponent -5 } e REAL ::= { mantissa , base 10, exponent -23 } zero REAL ::= 0 topvalue REAL ::- PLUS-INFINITY buttomvalue REAL ::= MINIU-INFINITY Przykład 2 (wg notacji z 1990): pi REAL ::= { , 10, -5 } e REAL ::= { , 10, -23 } zero REAL ::= 0 topvalue REAL ::- PLUS-INFINITY buttomvalue REAL ::= MINIU-INFINITY Typ BIT STRING może przyjmować jako wartości uporządkowany ciąg 0 lub większej liczby bitów. Jego wartość ujęta jest w apostrofach i zakończona literą B, jeśli jest to ciąg 0 i 1 lub H, jeśli jest to ciąg zawierający cyfry od 0 do 9 i od A do F. Przykład 1: pi-decimals BIT STRING ::= ' 'B pi-decimals BIT STRING ::= '243F6A8885A308D313198A2E0370'H

43 Przy rozpatrywaniu kolejności uporzadkowania bitów należy trzymać się następującej konwencji: pierwszy bit jest najbardziej na lewo położonym bitem ciągu (bit numer 0), zaś ostatni bit jest najbardziej na prawo położonym bitem ciągu. Przykład 2: GenDer ::= BIT STRING StringOf32Bits ::= BIT STRING (SIZE (32)) Rights ::= BIT STRING { user-read(0), user-write(1), group-read(2), group-write(3), other-read(4), other-write(5) } group1 Rights ::= { group-read, group-write } Przykład 3: Characteristics ::= BIT STRING {gender(0),adult(1),blueeyed(2),caucasian(3)} (Zdefiniowano BIT STRING o dowolnej długości, ale nazwy przypisano tylko pierwszym czterem wartościom) Characteristics ::= BIT STRING {gender(0), adult(1),blueeyed(2),caucasian(3)} (SIZE (0..4)) (Jak wyżej, ale ciąg może mieć maksymalnie cztery bity). Characteristics ::= BIT STRING {gender(0),adult(1),blueeyed(2),caucasian(3)} (SIZE (4)) (Jak wyżej, ale ciąg musi mieć zawsze dokładnie cztery bity)

44 Podtypy (c.d.). Wspomniano już, że oprócz ograniczanai zakresu wartości typu INTEGER ten sam mechanizm można zastosować także do innych typów. Przykłady róznych podtypów przedstawiono w tabeli poniżej. Rodzaj podtypu Czego dotyczy Przykłądy Pojedyncza wartość Wszystkie typy RetirementAge ::=INTEGER (65) Zakres INTEGER i REAL AdultAge ::=INTEGER (15..MAX ) Child ::=INTEGER (1..14 ) Podtypy włączone Wszystkie typy Age ::=INTEGER (INCLUDES Child INCLUDES AdultAge ) Rozmiar zakresu SEQUENCE OF, SET OF i wszystkie typy ciągów Ograniczenie alfabetu Typy ciągów znakowych Wewnętrzne podtypy Lista kilku wartości podtypów SET, SET OF, SEQUENCE, SEQUENCE OF, CHOICE Line ::=General String (SIZE (1..80)) Couple ::=SET SIZE(2) OF Person OctalDigit ::=General String (FROM ("0" "1" "2" "3" "4" "5" "6" "7")) Person ::=CHOICE {Male,Female } Males ::=SET WITH Component (Male) OF Person Wszystkie typy Base ::=INTEGER ( )

45 Ograniczenia (aktualne ograniczenia podtypów wyspecyfikowane są jako komentarz Wszystkie typy ENCRYPTED {ToBeEnciphered } ::= BIT STRING (CONSTRAINED-BY { -- must be enciphermed using -- the DES encipherment -- standard }) Typ OCTET STRING. Ten typ definiuje ciąg o długości 0, 1 lub więcej oktetów. Stosuje się go często wtedy, gdy przesyłane są dane, określane zgodnie ze składnią odmienną od składni ASN.1, np. pliki GIF. Przykład: GifPicture :: = OCTET STRING Typ NULL jest type, którego jedyną dopuszczalną wartością może być null. Stosowany jest w celu wskazania miejsca dla typu, który zostanie zdefiniowany i dodany w przyszłości, lub używany jest razem z słowem OPTIONAL, oznaczającym występowanie lub niewystępowanie wartości, przy czym sam fakt wystąpienia lub nie wystąpienia niesie za sobą jakąś informację. Przykład: Prisoner ::=SEQUENCE { name GeneralString, dangerous NULL OPTIONAL } oznacza tyle samo, co zapis: Prisoner ::=SEQUENCE { name GeneralString, dangerous BOOLEAN }

46 Typy ciągów znakowych. W notacji ASN.1 zdefiniowano kilka typów ciągów znakowych, które opisują różne zbiory znaków. Typ ciągu znakowego Odpowiadający mu zbiór znaków NumericString " i spacja PrintableString a.. z, A.. Z, 0.. 9, spacja, ', (, ), +, -,,,., /, :, =,? TeletexString, T61String Zbiór znaków T.61 lub ISO 6937, wykorzystujący jeden lub dwa bajty do reprezentacji wiecej niż 256 różnych znaków, np. É jest zapisywany jako kombinacja dwóch znaków E VisibleString, Znaki drukowalne oraz spacja określone w ISO ISO646String 646, z wyłączeniem znaków kontrolnych, np. nowa linia i powrót karetki. IA5String GraphicString GeneralString UniversalString BMPString ISO 646, kody ASCII Może zawierać znaki z kilku różnych zbiorów znaków, korzystając z ISO 2022 do przełączania z jednego zbioru znaków w drugi. Może zawierać jedynie znaki drukowalne oraz spację, bez znaków formatujących. Tak samo jak GraphicString, ale dodatkowo może zawierać znaki formatujące Zbiór znaków wg ISO , zwany popularnie UNICODE (patrz wyżej) Podzbiór znaków wg ISO , tzw. Basic Multilingual Plane, pierwszych 2 16 znaków

47 UTF8String Podzbiór znaków wg ISO (patrz wyżej) Typy strukturalizowane. Typ strukturalizowany określa nowy typ jako kombinację jednego lub więcej typów już zdefiniowanych. Składnia Opis Przykłady SET Lista pól składowych, podobna do rekordu w bazie danych. Składowe mogą być dołączane w dowolnej kolejności oraz kolejność w jakiej przesyłane są te składowe nie niesie ze sobą żadnej wiadomości. Chairmen ::={ democratic-chairman General String, republican chairman General String } SEQUENCE SET OF Podobnie jak wprzypadku SET z tym, że składowe wysyłane są uporządkowane i przesyłane zgodnie z tym uporządkowaniem. Zero lub więcej składowych, wszystkie tego samego typu. Uporządkowanie składowych nie niesie żadnej informacji. SEQUENCE OF Podobnie jak SET OF, ale kolejność ma znaczenie CHOICE Przyjmuje wartość jednego spośród wylistowanych alternatywnych typów Ingredients ::={ peas REAL, eggs INTEGER } Ingredients ::=SET OF Ingredient Couple ::=SET SIZE (2) OF Person Chairmens ::= SET OF Chairmen Children ::=SET OF Person Vehicle ::=CHOICE { bus, Car, Bicycle }

48 W przypadku SET OF oraz SEQUENCE OF można wskazać, że jedna lub więcej składowych nie musi występować (są opcjonalne). Przykład: KnownParents ::=SEQUENCE OF { father Male OPTIONAL, mother Female OPTIONAL } Podtypy wewnętrzne. W przypadku typów strukturalizowanych można zdefiniować specjalne rodzaje podtypów, tzw. podtypy wewnętrzne. Pod tym pojęciem rozumiemy określenie jednego lub więcej podtypu składowej (składowych) typu strukturalizowanego. W przypadku konstrukcji SET OF lub SEQUENCE OF do określenia podtypu używa się sekwencji WITH COMPONENT. Przykład 1: Age ::= INTEGER People ::= SET OF Age Childen ::= AGE (WITH COMPONENT (1..14)) Przykład 2. Niech będzie dany typ: TextBlock ::= SEQUENCE OF VisibleString Chcemy użyć go do zdefiniowania adresu w paru liniach (wierszach), nie przekraczających 32 znaków (w wierszu). Możemy zrobić to tak: AddressBlock ::= TextBlock ( WITH COMPONENT (SIZE (1..32)) )

49 Jeśli typu TextBlock chcemy z kolei użyć do zdefiniowania bloku informacji, składających się jedynie z cyfr, to podtyp wewnętrzny ma postać: DigitBlock ::= TextBlock ( WITH COMPONENT (NumericString) ) Powyższe definicje równoważnie można zapisać tak: AddressBlock ::= SEQUENCE OF VisibleString (SIZE (1..32)) DigitBlock ::= SEQUENCE OF VisibleString (NumericString) Korzystając z typów SEQENCE i SET, które mogą zawierać składowe wielu różnych typów, potrzebujemy czasami ograniczenia typu każdego ze składowych. Czynimy to przy pomocy kwalifikatora WITH COMPONENTS (z S na końcu). Załóżmy, że jest dany typ: Quadruple ::= SEQUENCE { alpha ENUMERATED {state1, state2, state3}, beta IA5String OPTIONAL, gamma SEQUENCE OF INTEGER, delta BOOLEAN DEFAULT TRUE } Z tak zdefiniowanego typu podstawowego możemy wyprowadzić podtyp, którego składowa alpha równa jest state1, zaś składowa gamma posiada zawsze pięć elementów: Quadruple1 ::= Quadruple ( WITH COMPONENTS {..., alpha (state1),

50 ) gamma (SIZE (5))} Ten sam podtyp równoważnie można zdefiniować następująco: Quadruple1 ::= SEQUENCE { alpha ENUMERATED {state1, state2, state3} (state1), beta IA5String OPTIONAL, gamma SEQUENCE SIZE (5) OF INTEGER, delta BOOLEAN DEFAULT TRUE } Symbol trzech kropek "..." oznacza, że ograniczenie dotyczy tylko niektórych składowych i nie zmienia sensu definicji składowych, które nie pojawiły się na liście ograniczeń. Ograniczenie przy pomocy kwalifikatora WITH COMPONENTS można także ograniczać, posługując się słowami kluczowymi PRESENT i ABSENT, które mają wpływ odpowiednio na składowe oznaczone jako OPTIONAL lub DEAFULT. Przykład: Quadruple2 ::= Quadruple (WITH COMPONENTS { alpha (state1), beta (SIZE (5 12)) PRESENT, gamma (SIZE (5)), delta OPTIONAL } ) Typ CHOICE. Konstrukcja CHOICE stwarza możliwość wyboru pomiędzy kilkoma alternatywami. Przykłady: Afters ::= CHOICE {

51 } cheese [0] IA5String, dessert [1] IA5String Alternatywa oznaczona jest jako nazwa składowej, rozpoczynając asie z małej litery. Ponieważ nazwy pól nie są kodowane, to sytuacja ta mogłaby prowadzić niejednoznaczności (mamy dwa pola tego samego typu, otrzymaliśmy zakodowana wartość typu Afters, ale nie wiemy którą jego alternatywę cheese, czy też dessert). Aby ten problem rozwiązać, identyfikatory alternatyw typu CHOICE muszą być rozróżnialne: wystarczy poprzedzić typ alternatywy identyfikatorem pola liczbą całkowitą ujętą w nawiasy kwadratowe). Typ ANY stosowany jest do modelowania zmiennych, których typ nie jest zdefiniowany lub zdefiniowany gdzieś wcześniej, np. całkiem w innym module ASN.1. Dzięki ANY możemy w momencie definiowania typów pominąć szczegóły związane ze specyfikacją jakiegoś jego elementu, którego typ jest nieznany lub też element ten może być w zależności od kontekstu różnego typu. Definicje typów z użyciem ANY występują w dwóch postaciach: (1) Vehicle ::=ANY (2) SEQUENCE { type-of-vehicle INTEGER, vehicle ANY DEFINED BY type-of-vehicle }

52 Zapis postaci (1) wymaga, aby komputer odbierający wartość tego typu dokonał analizy, jaki format jest adekwatny do przesłanego typu ANY (zwykle musi z góry to założyć lub w informacje o tym umieścić w typie ANY). Przypadek (2), dzięki użyciu pola type-of-vehicle, dostarcza odbiorcy informacji o formacie typu ANY. Typem pola type-of-vehicle jest zwykle INTEGER lub OBJECT IDENTIFIER. Identyfikatory typu OBJECT IDENTIFIER (w skrócie OID) budowane są na bazie rejestracji w hierarchicznym drzewie nazw (określanego w skrócie drzewem nazw RH). Drzewo nazw RH jest drzewem, którego liście odpowiadają rejestrowanym obiektom, zaś nie-liście organom rejestracji, któremu poprzedzający go w hierarchii organ rejestracji przekazał uprawnienia w zakresie rejestracji w tej części poddrzewa nazw RH. Korzeń drzewa nazw RH jest zgodny z normą ISO/IEC [1]. Drzewo nazw RH musi być tak budowane, aby zarówno organy rejestracji, jak i rejestrowane przez nie obiekty posiadały unikalne identyfikatory. Przy takiej konstrukcji drzewa nazw RH identyfikator obiektu rejestrowanego przez organ rejestracji jest konkatenacją identyfikatora organu rejestracji i nazwy liścia wychodzącego z węzła, pod który podczepiony jest organ rejestracji. Identyfikatory OID nadawane są przez odpowiednie organy rejestracji. W Polsce rolę taką pełni Krajowy Rejestr Identyfikatorów Obiektów KRIO (

53 recommendation (0) pl (616) administration (1) other countries itu-t (0) question (2) networkoperator (3) us-public-datanetworks ( ) other countries' PDNs standard (0) pl (616) member-body (2) ISO/IEC (ITU-T X.600) iso (1) registrationauthority (1) other countries osinet (0004) identifiedorganisation (3) gosip (0005) us-dod (0006) joint iso-itu-t (2) country (16) other oiw (0014) other

54 Przykłady użycia słowa kluczowego SIZE MonthNumber ::= NumericString (SIZE (1..2)) MonthNumber ::= NumericString (SIZE (1 2)) Base ::=BIT STRING (SIZE ( )) Couple ::=SET SIZE(2)OF Human BridgeDeal ::=SET SIZE (13)OF PlayingCard BridgeHand ::=SET SIZE (0..13)OF PlayingCard linelength INTEGER ::= 80 Line ::= VisibleString (SIZE (0..lineLength) Znaczniki (ang. tags) Popatrzmy na następujące trzy przykłady: (1) Name ::=SEQUENCE { givenname [0] VisibleString OPTIONAL, surname [1] VisibleString OPTIONAL } (2) Name ::=SET { givenname [0] VisibleString, surname [1] VisibleString } (3)

55 Name ::=CHOICE { numericname NumericString, alphabeticname VisibleString } W przykładzie pierwszym (1) oba elementy są opcjonalne, Stąd konieczne są znaczniki [0] i [1], ponieważ odbiorca dostanie wiadomość, to na podstawie tych znaczników będzie w stanie rozróżnić, który z dwóch elementów otrzymał (w przypadku, gdy przyjdą oba elementy, to problemu tego nie ma). W przykładzie (2) znaczniki są niezbędne, ponieważ odbiorca będzie otrzymywał zawsze oba elementy typu SET, ale w dowolnej kolejności. Alternatywne składowe w typie CHOICE są różnego typu. Oznacza to, że w tym przypadku nie zachodzi konieczność umieszczenia znaczników składowych pól wystarcza znaczniki typów wbudowanych: NumericString i VisibleString. Znaczniki typów wbudowanych należą to grupy znaczników typu UNIVERSAL i przedstawione są w Tab.6. Znaczniki są etykietami stosowanymi w celu zróżnicowania typów. Znaczniki są konieczne w niektórych sytuacjach, chociaż mogą być używane wtedy, gdy takiej konieczności nie ma. Tabela 6. Znaczniki UNIVERSAL w ASN

56 Jerzy Pejaś: Standardy i Systemy Otwarte

57 Znaczniki posiadają dwie składowe: składową klasa oraz składową numer. W ASN.1 wyróżnia się cztery klasy znaczników, przedstawione w Tab.7. Tabela 7. Klasy znaczników w ASN.1 Klasa Przykład Opis univwersalna [UNIVERSAL 2] Opisuje typy, których znaczenie jest takie samo w dowolnym zastosowaniu (patrz Tab.6). zastosowania [APPLICATION 0] Opisuje typy, których znaczenie jest uzależnione od konkretnego zastosowania prywatna [PRIVATE 4] Umożliwia użytkownikowi definiowanie własnych rozszerzeń, których znaczenie nadawane jest przez użytkownika zorientowana kontekstowo [7] Ten znacznik ma znaczenie jedynie w bezpośrednim kontekście określonym przez konstrukcje SET, SEQUENCE i CHOICE. Jest to najlepszy w użyciu znacznik w przypadku, gdy UNIVERSAL jest niewystarczający. W wersji ASN.1 z 1994 roku wprowadzono piąty znacznik AUTOMATIC. Tak naprawdę nie jest to nowa klasa znaczników, ale jedynie określenie, że konkretna wartość znacznika powinna zostać automatycznie obliczona w momencie kompilacji kodu ASN.1. Przykłady: Name ::=SET { given name [0] VisibleString, surname [1] VisibleString }

58 PersonnelRecord ::=SET { name [0] Name, wage [1] INTEGER } Znaczniki jawne (ang. explicit) i niejawne (ang. implicit). Załóżmy, że zdefiniowano następujące typy: Name ::=SEQUENCE { givenname [0] VisibleString OPTIONAL, initials [1] VisibleString OPTIONAL, surname [2] VisibleString OPTIONAL } Jeśli typ ten zakodujemy w formacie BER, wówczas do odbiorcy będą wysyłane dwa znaczniki na każdy z elementów: najpierw znaczniki zorientowane kontekstowo [0], [1] i [2], a następnie znaczniki UNIVERSAL dla typu VisibleString. Aby tego uniknąć, przepiszmy powyższą definicję w postaci: Name ::=SEQUENCE { givenname [0] IMPLICIT VisibleString OPTIONAL, initials [1] IMPLICIT VisibleString OPTIONAL, surname [2] IMPLICIT VisibleString OPTIONAL } Słowo IMPLICIT określa, że wysyłane powinny być jedynie znaczniki [0], [1] i [2], zaś znaczniki UNIVERSAL pomijane

59 Modyfikator IMPLICIT można umieścić także w nagłówku modułu ASN.1. Oznacza to wówczas, że wszystkie znaczniki (tam gdzie jest to możliwe) są niejawne (IMPLICIT), nawet jeśli tego wyraźnie nie zaznaczono.. Nagłówek modułu ASN.1 może mieć postać: DEFINITIONS ::= --Implies Explicit tags DEFINITIONS IMPLICIT TAGS ::= DEFINITIONS EXPLICIT TAGS ::= DEFINITIONS AUTOMATIC TAGS ::= (wer. ASN.1 94) Jeśli moduł jest typ IMPLICIT TAGS, to jeśli konieczne są jawne znaczniki w tekście, wówczas należy z danym polem związać kwalifikator EXPLICIT. Moduł w ASN.1 jest nazwaną kolekcją (zbiorem) typów ASN.1 i definicji wartości. Struktura modułu jest następująca: <modulereference><obj-id >DEFINITIONS <tag-defaults>::= BEGIN EXPORTS <type and value references>; IMPORTS <type and value references> FROM <modulereference><obj-id>;... <type and value definitions>... END Kwalifikatory EXPORTS lub IMPORTS... FROM umożliwiają odpowiednio udostępnienie niektórych lub wszystkich typów zdefiniowanych w module lub odwołanie się do typó zdefiniowanych w innych modułach. Przykład 1:

60 WeatherReporting { } DEFINITIONS EXPLICIT TAGS ::= BEGIN WeatherReport ::= SEQUENCE { height [0] IMPLICIT REAL, weather [1] IMPLICIT Wrecord } Wrecord ::= [APPLICATION 3 ] SEQUENCE { temp Temperature, moist Moisture wspeed [0] Windspeed OPTIONAL } Temperature ::= [APPLICATION 0] IMPLICIT REAL Moisture ::= [APPLICATION 1 ] REAL Windspeed ::= [APPLICATION 2 ] REAL END --of module WeatherReporting Przykład 2: CargoHandling { } DEFINITIONS EXPLICIT TAGS ::= BEGIN EXPORTS Box, Container; Box ::=SEQUENCE { height INTEGER,--in centimeters width INTEGER,--in centimeters length INTEGER --in centimeters } Container ::=SEQUENCE { weight INTEGER,--in kilograms volume Box }

61 END --of CargoHandling Przykład 3: TrainCargo { }DEFINITIONS EXPLICIT TAGS ::= BEGIN IMPORTS Box,Container FROM CargoHandling { }; TrainContainer ::= Container (WITH COMPONENTS { weight ( ), volume } ) Carriage ::= SET SIZE (2..4)OF Container END --of TrainCargo Przykład 4 (z PKCS#10): PKCS-10 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-10(10) modules(1) pkcs-10(1)} DEFINITIONS IMPLICIT TAGS ::= BEGIN -- EXPORTS All: all types and values defined in this -- module are exported for use in other ASN.1 modules. IMPORTS informationframework, authenticationframework FROM UsefulDefinitions { usefuldefinitions } Attribute, Name FROM InformationFramework { informationframework}

62 pkcs-9 FROM CertificateExtensions {certificateextensions} id-extensionreq FROM EnrollmentMessageSyntax {enrollmentmessagesyntax} DirectoryString FROM SelectedAttributeTypes {selectedattributetypes} AlgorithmIdentifier, SubjectPublicKeyInfo, Extensions FROM AuthenticationFramework {authenticationframework}; -- Certificate requests CertificationRequestInfo ::= SEQUENCE { version INTEGER { v1(0) }, subject Name, subjectpkinfo SubjectPublicKeyInfo, attributes [0] Attributes } Attributes ::= SET OF Attribute CertificationRequest ::= SEQUENCE { certificationrequestinfo CertificationRequestInfo, signaturealgorithm AlgorithmIdentifier, signature BIT STRING } ExtensionRequest ::= Extensions -- Dodane z PKCS# r. -- pkcs-9-at-extensionrequest == id-extensionreq

63 pkcs-9-at-unstructedname OBJECT IDENTIFIER ::= { pkcs-9 2 } UnstructuredName ::= PKCS9String PKCS9String ::= CHOICE { ia5string IA5String, directorystring DirectoryString } END Reguły kodowania Podstawowe Reguły Kodowani (Basic Encoding Rules, BER) jest najszerzej stosowanym formatem kodowania opisów specyfikacji w ASN.1. BER bazuje na formacie TLV (tag-length-value), o którym była już mowa. Na rys.1 przedstawiono przykład kodowania BER. Rys.1 Kodowanie TLV w BER

64 Pole znacznika lub identyfikatora. Pierwsze dwa bity znacznika (bit 8 i 7, bity numerujemy od 1) określają klasę znacznika, przy czym 00 znacznik UNIVERSAL, 01 znacznik APPLICATION, 10 znacznik zorientowany kontekstowo, 11 znacznik PRIVATE (patrz rys.2). Trzeci bit równy jest 0 w przypadku kodowania typu prostego, zaś 1 w przypadku typu złożonego. Jeśli numer znacznika jest z przedziału od 0 do 30, to jest kodowany na pozostałych pięciu bitach (ang. one-octet-variant, patrz rys.3). Jeśli numer znacznika jest wiekszy niż 30, to wtedy pozostałe 5 bitów pierwszego oktetu ustawionych jest na 1, zaś numer znacznika kodowany jest na ostatnich 7 bitach jednego lub większej liczbie oktetów, występujących po oktecie czołowym (ang. multiple-octet-variant, patrz rys.3). Pierwszy bit (bit 8) każdego takiego następnego oktetu jest równy 1, chyba że jest ostatnim oktetem w sekwencji). Rys.2 Kodowanie klas w oktetach

65 Rys.3 Kodowanie znacznika w BER Kodowanie długości pola w BER. Zgodnie z rys.4, pole długości w BER ma także postać krótką (jedno bajtową, ang. short form) i postać (wielobajtowa, ang. long form). Postać krótka ma pierwszy bit (bit nr 8) ustawiony na 0, zaś pozostałe 7 bitów może zawierać wartość długości pola w bajtach (długość z przedziału od 0 do 127). W przypadku postaci długiej, bit pierwszy jest ustawiony na 1, zaś pozostałe 7 bitów pierwszego oktetu określa liczbę dodatkowych oktetów. Wartość długości pola w bajtach kodowana jest na wszystkich bitach dodatkowych oktetów

66 Rys.4 Kodowanie długości w BER Stosowana jest także tzw. postać nieograniczona (ang. unlimited form). Rozpoczyna się od oktetu z pierwszym bitem ustawionym na 1, a pozostałymi na 0 i kończy się oktetem z wszystkimi bitami ustawionymi na 0. Inaczej mówiąc, postać nieograniczona (ang. unlimited form) zaczyna się oktetem o wartości 80H, a kończy 00H (H oznacza liczbę szesnastkową). Postać nieograniczona jest zawsze postacią złożoną, tzn. jej wartość musi być zapisana w postaci TLV. Oktety wartości BER. W Tab.8 pokazane są przykłady kodów BER dla różnych typów danych. Warianty kodowania napisów z wykorzystaniem znaczników. Na rys.5 przedstawiono przykłady kodowania znaków z wykorzystaniem i bez wykorzystania poprzedzających je znaczników zorientowanych kontekstowo. Przykład kodowania SEQUENCE. Dany jest opis w ASN.1 typu o postaci:

67 HeadOfState ::=[APPLICATION 17 ] SEQUENCE { name IA5STRING, type ENUMERATED { president (0), emperor (1), king (2)}, birthyear INTEGER OPTIIONAL } Tabela 8. Oktety wartości BER

68 Jerzy Pejaś: Standardy i Systemy Otwarte