Sunteți pe pagina 1din 184

CUPRINS

Cuprins

3

BIBLIOGRAFIE

6

CUVÎNT ÎNAINTE

7

CAPITOLUL 1. INTERNET ŞI WORLD WIDE WEB

9

1.1. INTRODUCERE

9

Ce este Internetul? Ce este World Wide Web (WWW, W3)

9

10

1.2. RESURSELE WORLD WIDE WEB

11

1.3. ADRESAREA UNEI RESURSE ÎN WEB

11

1.4. ELEMENTELE CONEXIUNILOR ÎN SPAŢIUL WWW

12

1.5. PROTOCOLUL HTTP

13

1.5.1. INTRODUCERE GENERALĂ

13

1.5.2. MESAJELE PROTOCOLULUI HHTP

14

1.5.3. METODELE PROTOCOLULUI HHTP

15

CAPITOLUL 2. DESCRIERE GENERALĂ A HTML

19

2.1. INTRODUCERE, ISTORIE, VERSIUNI

19

Ce este HTML?

19

Caracteristicile limbajului HTML.

19

De ce HTML?

20

Istoria HTML.

21

Ce trebuie să facă un autor de pagini HTML?

24

Revoluţia HTML 4.0.

24

Validarea documentelor HTML.

25

2.2.

REPREZENTAREA DOCUMENTELOR HTML

26

2.3. STRUCTURA ŞI LOGICA LIMBAJULUI HTML

27

I. Tag-urile HTML

27

II. Caractere entităţi

28

CAPITOLUL 3. STRUCTURA DOCUMENTELOR HTML

31

3.1. STRUCTURA GENERALĂ A UNUI DOCUMENT HTML

31

1. Elementul DOCTYPE

32

2. Elementul HTML

33

3. Elementul HEAD

33

4. Elementul BODY

34

5. Elementul FRAMESET

37

3.2. STRUCTURA HEADER-ULUI UNUI DOCUMENT (ELEMENTUL HEAD)

40

1. Elementul TITLE

40

2. Elementul BASE

41

3. Elementul STYLE

41

4. Elementul LINK

43

5. Elementul META

45

6. Elementul SCRIPT

46

7. Elementul ISINDEX

49

8. Elementul OBJECT

49

3.3. STRUCTURA CORPULUI UNUI DOCUMENT HTML (ELEMENTUL BODY)

52

I. Elementele de tip bloc (block level elements)

53

II. Elementele de tip inline (inline level elements)

54

III. Elementele de tip nedefinit (pot fi atît inline cît şi block)

56

CAPITOLUL 4. ELEMENTE DE BAZĂ HTML

57

4.1. ELEMENTE UTILIZATE LA FORMATAREA TEXTULUI UNUI DOCUMENT

57

1. Terminarea rîndului (elementul BR)

57

2. Titluri (elementul Hi)

58

3. Containere de text (stiluri ale unui bloc)

59

A. Paragrafe (elementul P)

59

B. Containerul logic de tip bloc (elementul DIV)

60

C. Containerul logic de tip text/inline (elementul SPAN)

60

D. Textul centrat (elementul CENTER)

62

E. Textul preformatat (elementul PRE)

62

F. Adrese (elementul ADDRESS)

63

G. Citate lungi (elementul BLOCKQUOTE)

64

H. Citate scurte (elementul Q)

65

4.

Stilurile caracterelor

66

5.

Elemente de modificare a fontului caracterelor

67

A. Dimensiunea fontului

67

B. Stabilirea fontului de bază

69

4.2. DEFINIREA ŞI UTILIZAREA LISTELOR

70

4.3. TAG-URI (ELEMENTE) PENTRU LEGĂTURI HYPERTEXT

77

4.4. IMAGINI ÎN DOCUMENTELE HTML

83

4.5. IMAGINI SENZITIVE

90

4.6. ALTE ELEMENTE LEGATE DE TEXT ŞI IMAGINI

98

1. Comentariile în documentele HTML

98

2. Linii orizontale de demarcare (elementul HR)

98

3. Fundalul unui document

99

4. Culoarea textului şi a legăturilor

100

CAPITOLUL 5. UTILIZAREA TABELELOR ÎN HTML

101

CAPITOLUL 6. UTILIZAREA FRAME-URILOR ÎN HTML

131

CAPITOLUL 7. UTILIZAREA FORMULALELOR (FORMS)

145

CAPITOLUL 8. ALTE ELEMENTE ALE LIMBAJULUI HTML 181

8.1. FORMULE MATEMATICE

181

8.2. DOCUMENTE DINAMICE

182

8.3. UTILIZAREA MEDIILOR EXTERNE: IMAGINI, SUNETE ŞI VIDEO

183

Bibliografie

[1] WWW Consortium, HTML 4.0 Specification,

www.w3.org/TR/REC-html40

[2] Strebe, Mathew, Perkins, Charles, MCSE Internet Information

server - Study Guide,

SYBEX Corporation, 1998

[3] Tittel, Ed, Gaither, Mark, Hassinger, Sebastian, Erwin,

Mike, Foundations of World Wide Programming,

IDG Books Worldwide Inc., 1997

[4] Honeycutt, Jerry, Special Edition Using HTML 4.0,

Maximillan Computer Publishing, 1998

[5] Mat Publishing Limited, Developer Network Journal, 1998, 1999 collection

[6] Miller Freeman, Inc., Microsoft Corp., Microsoft Internet

Developer Journal,

1998, 1999 collection

Cuvînt înainte

Aplicaţiile distribuite sînt de o bună perioadă de timp o prezenţă uzuală în peisajul IT chiar şi din ţara noastră. Ultimii ani au însemnat, de asemenea, şi paşi semnificativi şi concreţi în impunerea Inter- netului în întreaga economie şi societate. Odată cu acesta, aplicaţiile distribuite – care au ca suport Internetul şi tehnologiile dezvoltate pentru acesta şi împreună cu el, au trecut de la stadiul de noutăţi tehnologice la cel de prezenţă reală în comunitatea IT. Procesul de educaţie a tinerilor specialişti IT simte nevoia plonjării în această realitate. Tehnolo- gia Java, DHTML, tehnologia de scripting (Java Script, VB Script), bazele de date distribuite în Inter- net şi accesul la ele, interfeţele utilizator flexibile, bazate pe browsere capabile de performanţe din ce mai apropiate de necesităţi, tehnologia componentelor, toate acestea sînt necesităţi stringente ale tehno- logiei IT şi, implicit, ale procesului educaţional din acest domeniu. În acest spirit am încercat să aduc în faţa studenţilor problematica fascinantă a lumii distribuite, dar cooperante, dezvoltată de aceste tehnologii. Suportul acestei fascinaţii stă, fară îndoială, în geniul şi viziunea celor care au făcut din Internet o comunitate. Fundamentul acestei realităţi este, nu încape

îndoială, limbajul HTML, cel care a făcut posibilă explozia de comunicare actuală, cel care a adus aproape oameni, altfel atît de diferiţi: de la cercetători la studenţi, de la oameni de ştiinţă la copiii care abia descoperă computerul, dar care descoperă odată cu el Internetul. Aceasta este prima parte a unui suport de curs la disciplina „Dezvoltarea aplicaţiilor distribuite în Internet“, introdusă în acest an, la anul IV, în semestrul al doilea, la secţia de calculatoare a Facultă- ţii de Automatică, Calculatoare şi Electronică din Craiova. Studenţilor acestei facultăţi li se adresează, în primul rînd. Dimensiunea lucrării a fost determinată de dorinţa de a pune la dispoziţia celor care au preocupări în acest domeniu a unui material cît mai complet în limba română referitor la limbajul HTML. Versiunea descrisă aici este HTML 4.0 şi este impusă de realitatea Web-ului începutului de an

1999.

Structurat în 8 capitole, prezentul suport de curs, prezintă gradual şi cît mai compet cu putinţă limbajul HTML. Capitolul 1 face o scurtă prezentare a noţiunilor esenţiale legate de Internet şi Web, iar Capitolul 2 o descriere generală şi o scurtă incursiune în istoria limbajului HTML. Este partea intro- ductivă care este urmată apoi de capitolele ce descriu structura unui document scris în HTML – Capi- tolul 3) şi elementele de bază utilizate în documentele HTML – texte, legături, imagini (Capitolul 4). Capitolele 5, 6 şi 7 detaliază modalităţile de utilizare a tabelelor, frame-urilor şi a formularelor inter- active, adică partea mai avansată a limbajului HTML. Capitolul 8 prezintă, pe scurt, elemente mai deosebite ale limbajului. Reprezentînd doar fundamentul, prezentul suport de curs nu face decît să incite şi să promită adevăratele performanţe ale tehnologiei Internetului. Va urma partea a doua a acestui suport de curs care va acoperi (cel puţin) o parte dintre ele: Cascading Style Sheet, Dynamic HTML, tehnologiile de scripting şi, bineînţeles, limbajul Java . Acest suport reprezintă încununarea unei perioade de mare efort, dar extrem de rodnice, perioadă petrecută de autor în Germania, la Fachhochschule Regensburg, iar apariţia lui, în această formă, se sprijină pe sprijinul material oferit de Uniunea Europeană prin programele Tempus. Un gînd plin de recunoştiinţă, profesorului Oleg Cernian, coordonatorul Programelor Tempus din Facultatea de Automatică, Calculatoare şi Electronică, al cărui merit în dezvoltarea Catedrei de Calculatoare devine, odată cu trecerea timpului, tot mai clar şi mai evident.

Craiova, martie 1999

Autorul

Capitolul 1.

INTERNET şi World Wide Web

1.1. Introducere

Ce este Internetul?

Internetul a fost descris ca „o colecţie largă de reţele“ sau ca o „reţea de reţele“. Deşi ambele definiţii sînt corecte, nici una nu surprinde Internetul în totalitatea sa. Pe lîngă instrumentul care este această imensă conexiune, Internetul înseamnă şi mulţimea comunităţilor celor ce îl folosesc, fiecare în scopuri diferite:

comunitatea academică utilizează Internetul ca pe cel mai mare, complet şi totodată complex instrument de învăţare (educaţional);

comunitatea ştiinţifică utilizează Internetul ca pe un instrument de cercetare şi colaborare;

comunitatea economică utilizează Internetul ca pe un mediu de derulare al afacerilor.

Internetul nu este o organizaţie monolitică, avînd o conducere şi un grup de control unice; Internetul este o societate de reţele de calculatoare interconectate, independente dar care (din anumite motive) se supun unor protocoale globale.

re ţ ele de calculatoare interconectate, independente dar care (din anumite motive) se supun unor protocoale

Ce este World Wide Web (WWW, W3)

World Wide Web (WWW sau W3) este o reţea de resurse informaţionale de o extraordinar de mare diversitate în ceea ce priveşte conţinutul. Este un sistem interactiv hipermedia (adică un sistem ce conţine şi suportă patru categorii importante de tipuri de informaţie: texte, imagini, sunete/audio şi imagini video în mişcare) construit peste Internet.

Pentru a face aceste resurse disponibile (utilizabile) unei audienţe cît mai largi, Web-ul se sprijină pe 3 mecanisme fundamentale:

1. O schemă uniformă de denumire (de stabilire a numelor, naming scheme) pentru a localiza resursele în Web (de exemplu URI).

2. Protocoale pentru accesarea resurselor astfel denumite în Web (de exemplu HTTP)

3. Hypertextul pentru navigarea comodă de la o resursă la alta (între resurse).

Elementele fundamentale ale WWW sînt prezentate în figura următoare:

ale WWW sînt prezentate în figura urm ă toare: World Wide Web este cel mai vizibil

World Wide Web este cel mai vizibil instrument Internet, transformîndu-l (prin capacităţile sale de a prezenta informaţiile) în cel mai important instrument al zilelor noastre şi într-o sursă de informaţii fără egal. Web-ul poate fi utilizat pentru căutarea de informaţii despre produse, transferul de software şi versiuni noi ale acestuia, păstrarea unor colecţii de informaţii de orice fel de tip (de exemplu de ziare), în general pentru aflarea unor informaţii despre orice tip de informaţie imaginabilă.

1.2.

Resursele World Wide Web

Unul din conceptele de bază - preluat şi acceptat şi în alte protocoale utilizate în Internet - este cel de resursă. O resursă poate fi un program, un calculator, un document, o bază de date, un serviciu - nu prea are importanţă, atît timp cît poate fi referită în mod corect şi fără echivoc. Pentru referirea la o resursă din Internet, se foloseşte termenul generic URI (Universal Resource Identifier) care poate specifica fie o locaţie, caz în care se vorbeşte de un URL (Universal Resource Locator) fie un nume, caz în care se vorbeşte de un URN (Universal Resource Name).

Unei resurse i se aplică o metodă - iar pentru a specifica ce metodă se doreşte, ce date sau parametrii suplimentari o completează pe aceasta, se face uz de mesaje.

Paradigma pe care se bazează protocolul este cea de cerere/răspuns. Cererea este emisă de un client; acesta stabileşte o conexiune cu un server şi îi trimite acestuia o cerere, sub forma unei metode. Metoda se referă la o anumită resursă, identificată via URI; mai trebuie adăugate versiunea de protocol utilizată şi un mesaj de tip MIME care să conţină parametrii metodei, informaţii relative la client şi un eventual “conţinut” suplimentar. Serverul vă răspunde cu o linie de stare, incluzînd versiunea de protocol utilizată şi un cod de succes sau eroare, la care se adaugă un mesaj de tip MIME conţinînd informaţii relative la server şi eventual un “conţinut” suplimentar.

Acest posibil conţinut suplimentar este de regulă o entitate - o reprezentare particulară a unor date necesare în cerere sau în răspuns, şi este structurat într-un antet (header) conţinînd metainformaţii relative la date (o descriere a felului în care trebuie citite datele) şi datele propriu-zise, care formează corpul entităţii.

1.3. Adresarea unei resurse în Web

Adresarea unei resurse via http se face prin construcţii (şiruri de caractere) de forma

http://adresa_host_in_retea[:port]/cale/subcale l /

/subcale

n /nume_document

http: specifică tipul protocolului; el trebuie precizat dat fiind faptul că http nu este singurul protocol prin care poate fi accesată o anumită resursă din Internet.

adresa_host_in_retea (de exemplu www.xxx.ro sau www.stpt.com) identifică un server sau un gateway din reţea, folosind adresarea uzuală de tip DNS (Domain Name Service) din Internet:

numehost.subdomeniu l .subdomeniu 2

subdomeniu

n .domeniu_de_bază

Deci www.xxx.ro s-ar citi “serverul www din subdomeniul xxx din domeniul de bază ro.

:port poate lipsi, ceea ce înseamnă că se presupune implicit că se face referinţă la portul standard, 80. Dacă se specifică un alt port, se va adresa acesta.

Cale/subcale l /

de nume_document de pe serverul respectiv. Nu întotdeauna însă resursa referită este un document! Poate fi o fracţiune dintr-un document, caz în care se face referire la fragmentul

respectiv:

/subcale

n /nume_document identifică calea absolută pînă la documentul identificat

Cale/subcale l /

/subcale

n /nume_document#capitolul2paragraful3

Sau, mai general, poate fi un program căruia trebuie să i se paseze cîţiva parametri şi o anumită cerere:

Cale/subcale l /

/subcale

n /nume_program;param l ;param 2 ;

;param

n ?cerere

Exemplu:

Următoarea referinţă

http://guaraldi.cs.colostate.edu:2000/cgi-bin/savvyfrontend?KW=cuvînt_cheie & classic=on & tl=x & Boolean=AND & Hits=10 & Mode=MakePlan & df=normal & AutoStep=on.

se va citi http://guaraldi.cs.colostate.edu:2000 ne spune că se va face o conexiune via http cu serverul guaraldi.cs.colostate.edu, utilizînd portul 2000 al acestuia. Pe acest server se va adresa programul savvy-frontend din directorul cgi-bin/, căruia nu i se pasează alţi parametri decît cei incluşi în felul în care a fost formulată cererea: KW=cuvînt_cheie & classic=on & tl=x & Boolean=AND & Hits=10 & Mode=MakePlan & df=normal &A utoStep=on.

Specificarea unei resurse nu trebuie să fie totdeauna absolută, ca în exemplul dat. Dacă ne-am plasat

deja într-un subdirector oarecare al unui server, se pot folosi adrese relative, care omit calea pînă în

acel director: “subcale l /subcale 2 /

dacă resursa se află în acelaşi director.

În HTML adresarea URI se foloseşte pentru:

/subcale

m /nume_resursa” sau chiar pur şi simplu “nume resursă”,

crearea unei legături spre un alt document sau spre o altă resursă (a se vedea elementele A şi LINK)

crearea unei legături spre un stil de pagină (style-sheet) extern sau spre un script aflat într-un fişier sursă extern (a se vedea elementele LINK şi SCRIPT)

Includerea într-o pagină a unei imagini, a unui obiect sau a unui applet (a se vedea elementele IMG, OBJECT, APPLET şi INPUT).

crearea unei imagini senzitive (a se vedea elementele MAP şi AREA).

transmiterea unui formular interactiv (a se vedea elementul FORM).

crearea unui document cu frame-uri (a se vedea elementele FRAME şi IFRAME).

citarea unei referinţe externe (a se vedea elementele Q, BLOCKQUOTE, INS şi DEL).

referirea unor conveţii de metadate care descriu un document (a se vedea elementul HEAD).

1.4. Elementele conexiunilor în spaţiul WWW

În cazul cel mai simplu, legătura dintre client şi server se realizează prin intermediul unei singure conexiuni. De foarte multe ori însă, este posibil să existe mai mulţi intermediari în conexiune. Aceştia pot fi de trei feluri: proxy, gateway sau tunnel.

Un proxy este un intermediar sofisticat: el primeşte cererile adresate unei resurse identificate printr- un URI, rescrie anumite părţi ale mesajului sau chiar tot mesajul, după care va transmite mesajul modificat către serverul adresat iniţial. Cu această ocazie el se şi substituie clientului iniţial:

răspunsul îi va veni tot lui, iar proxy-ul va face probabil o rescriere a mesajului de răspuns către client. Dinspre server, nu se mai “vede” cine este clientul adevărat: toţi clienţii ce trec prin proxy sînt “ascunşi”, serverul primind numai cereri de la proxy. Acesta poate face în plus, într-un singur loc, o serie de verificări, relative la autentificare, securizare etc., care ar fi greu de implementat pe multe şi diverse maşini - toate calculatoarele client care trec prin acel proxy. Un proxy reprezintă înspre restul lumii un grup de clienţi, putîndu-i trata pe aceştia diferenţiat.

Un gateway este similar unui proxy, dar pe partea de server. Este un receptor, un fel de “cameră de

primire” pusă în faţa unui server sau a unui grup de servere. Serverele “de după gateway nu se văd

în restul lumii - ele sînt, toate, reprezentate de gateway. Cererile sosite la gateway sînt dirijate către

serverele corespunzătoare cererii (sau către serverul cel mai liber, de exemplu, dacă faptul că există mai multe servere vine din dorinţa de a disponibiliza mai multă putere de calcul). De regulă are loc

şi o conversie de protocol, înspre protocolul pe care îl cunoaşte sau îl foloseşte un anumit server, care nu mai este obligat în felul acesta să “cunoască” http.

Un tunel este un intermediar neinteligent: el transportă date pe care nu le înţelege sau interpretează

în nici un fel între două conexiuni. Nu are loc nici un fel de schimbare a mesajelor, decît temporar,

trecînd printr-o formă intermediară, între intrarea în şi ieşirea din tunel; conţinutul mesajelor nu se

schimbă.

În cazul unei conexiuni mai complexe, o situaţie comună ar putea fi cea din figura
În
cazul unei conexiuni mai complexe, o situaţie comună ar putea fi cea din figura următoare:
O
cerere sau un răspuns care parcurge drumul din figură va traversa patru conexiuni. Acest lucru

trebuie avut în vedere; există unele opţiuni relative la comunicaţie care se referă numai la primul vecin, dacă acesta nu se află în spatele unui tunel, altele care se referă numai la punctele finale ale conexiunii iar altele care se pot referi la toate conexiunile de pe traseu.

Iar dacă diagrama simplificată de mai sus este lineară, nu trebuie uitat faptul că fiecare participant poate fi angajat simultan în comunicaţii multiple. Proxy-ul din figură poate lucra deodată cu mulţi clienţi, care se adresează la mai multe servere şi care pot fi găsiţi prin conexiuni diferite.

Oricare dintre participanţii la conexiune cu excepţia tunelului poate face uz de un cache intern care

să scurteze drumul unui ciclu cerere/răspuns. Exemplul anterior ilustrează şi drumul unei cereri care

s-a mai făcut o dată de către client, dar se află încă în cache-ul proxy-ului:

Desigur, nu toate răspunsurile se pretează la a fi păstrate un timp în cache (pe ideea că “poate mai cere cineva acelaşi lucru”); pe de altă parte, cererile de la clienţi pot formula anumite opţiuni specifice relative la cache (“nu accept decît răspunsuri de la server direct”, “nu accept răspunsuri memorate mai mult de x minute”, etc.)

1.5. Protocolul HTTP

1.5.1. Introducere generală

Este un protocol la nivel aplicaţie destinat sistemelor de informare distribuite, “colaborative“, de genul hypermedia. Apărut ca protocol de bază pentru WWW încă din 1990, a cunoscut o serie de

transformări, o versiune “finală” neexistînd nici în prezent. Versiunea cea mai folosită este încă 1.0, iar versiunea 1.1 - compatibilă “în jos” cu 1.0, dar aducînd îmbunătăţiri în special în direcţia folosirii mai eficiente a resurselor - este pe cale să se impună ca nou standard. De aceea, o parte din aspectele care urmează nu trebuie privite ca referinţe “bătute în cuie”, ci ca instantanee ale unei specificaţii pe cale să se nască, extrase dintr-o schiţă, un “draft” care poate se va mai schimba mult.

Numele este acronimul pentru HyperText Transfer Protocol, deşi la origine “hypertext” a fost definitoriu, practica curentă l-a dus destul de repede înspre “hypermedia” - documentele vehiculate cuprinzînd nu numai text, ci şi sunet, imagine sau informaţii structurate.

Aplicaţiile care folosesc protocolul - cei doi parteneri în discuţie, cele două capete ale unei conexiuni - sînt entităţi abstracte din punct de vedere al protocolului. Ele trebuie “doar” să poată comunica între ele ceea ce înseamnă, în principiu, posibilitatea de a primi sau formula cereri şi de a formula sau recepţiona răspunsuri, ca în celebrul exemplu al filozofilor ce vorbesc două limbi diferite, folosind pentru comunicare translatorii care trimit mesajele filozofilor (traduse) prin intermediul poştaşilor. Nici un nivel nu se preocupă de celălalt.

ta ş ilor. Nici un nivel nu se preocup ă de cel ă lalt. FILOZOFII TRANSLATORII

FILOZOFII

TRANSLATORII

POŞTAŞII

Cererile formulate în protocolul HTTP se referă la informaţii care se pot afla stocate în diverse baze de date, în diverse formate, pe diverse calculatoare. Cum anume se traduc în cereri “concrete” date diferite, este o problemă care depăşeşte protocolul: sarcina lui este doar să fixeze regulile care trebuie respectate de cele două aplicaţii participante la un moment dat în comunicare pentru ca să se poată înţelege fără nici un fel de risc de interpretare eronată a unei cereri sau a unui răspuns.

interpretare eronat ă a unei cereri sau a unui r ă spuns. 1.5.2. Mesajele protocolului HHTP

1.5.2. Mesajele protocolului HHTP

Atunci cînd se transferă „ceva“ utilizînd WWW se specifică o resursă: serverul căruia am vrea să-i adresăm cererea, ce conţine aceasta, cu ce protocol lucrăm. Pentru ca această cerere să ajungă la server trebuie să trimitem un mesaj care să conţină şi resursa specificată mai sus. Mesajul va conţine un şi r de caractere de forma:

GET

specificare_resursă

HTTP/1.1

CRLF

Forma generală a unui mesaj de cerere este conformă schemei de mai sus:

Metodă

resursă

versiune_protocol

CRLF

Versiunea de protocol trebuie specificată deoarece nu toate serverele au implementat ultima versiune sau nu toţi clienţii o cunosc. Deci, pentru ca totuşi un server “deştept” să se poată înţelege şi cu un client mai puţin dotat, sau invers, şi fără a renunţa la posibilităţile introduse de versiunile (mereu mai) noi ale protocolului, trebuie să se realizeze mai întîi o negociere între server şi client, relativ la ce ştie fiecare şi abia apoi să se desfăşoare transferul propriu-zis de date.

1.5.3. Metodele protocolului HHTP

Metodele sînt de fapt operaţiile care pot fi aplicate obiectelor constituite de resursele din reţea, în accepţiunea protocolului HTTP. Metoda va trebui să fie totdeauna primul element dintr-o linie de cerere. Metodele prevăzute în versiunea 1.1 sînt următoarele: OPTIONS, GET, HEAO, POST, PUT, PATCH, COPY, MOVE, DELETE, LINK, UNLINK, TRACE, WRAPPED.

OPTIONS semnifică o cerere relativă la informaţiile ce definesc opţiunile de comunicare disponibile pe conexiunea către URI-ul specificat în cerere. Metoda permite determinarea opţiunilor şi/sau posibilităţilor unui server, fără să determine o acţiune din partea resursei adresate.

Şi metoda are nevoie de parametri, nu numai resursa, iar în HTTP termenul consacrat pentru parametrii metodelor este “header field” sau “antet de cîmp”. Definite în cadrul protocolului pentru fiecare metodă, antetele de cîmp pot avea valori care la rîndul lor sînt definite (dar nu limitate, extensiile fiind în principiu totdeauna posibile).

Exemplu:

O cerere de tipul

OPTIONS www.xxx.ro HTTP1/1 CRLF Accept: audio/*; q=0.2, audio/basic CRLF

reprezintă o cerere de definire a opţiunilor către serverul www.xxx.ro, în care clientul solicitant spune că preferă audio/basic, dar acceptă orice tip pentru date audio în cazul în care calitatea reprezentării nu scade sub 20%.

Exemplu:

Iar o cerere de genul

OPTIONS www.xxx.ro HTTP1/1 CRLF Accept: text/plain; q=0.5, text/html, text/x-dvi; q=0.8; mxb=100000, text/x-c CRLF

specifică următoarele preferinţe relative la modul de reprezentare al textului: x-c sau html, dacă sînt disponibile; dacă nu, x-dvi, dar numai dacă textul nu depăşeşte 100000 de octeţi, sau plain altfel.

Virgula separă opţiuni posibile, punct-virgulă separă determinările sau preferinţele suplimentare relative la o anumită opţiune.

GET este una dintre cele mai importante metode şi singura care era disponibilă în prima versiune a protocolului, HTTP/0.9. GET este metoda care “aduce” ceva de la resursă; mai concret, dacă resursa este un proces care produce date (o căutare de pildă), răspunsul la metoda GET va fi o entitate care să cuprindă acele date. Răspunsul este unul singur: aceasta este o caracteristică de bază a protocolului. Chiar dacă volumul de date care trebuie incluse în răspuns este mare, nu se face o fracţionare în bucăţele mai mici, care să permită transferul mai uşor al răspunsului. Din punct de vedere al protocolului HTTP, discuţia este totdeauna simplă: o întrebare are un răspuns. Nu se pot pune mai multe întrebări pentru a obţine un singur răspuns, nu se pot formula mai multe răspunsuri la o întrebare.

Există totuşi două posibilităţi de a micşora volumul de date care să circule pe reţea în urma

elaborării unui răspuns; o condiţionare de genul “dacă s-a schimbat ceva” şi posibilitatea de a prelua numai o parte din acesta. De exemplu, o cerere de genul:

GET www.xxx.ro/?cerere HTTP/1.1 If-Modified-Since: Wed, 24 Mar 1999 1:00:00 GMT

va aduce ceea ce s-a cerut numai dacă s-a modificat ceva după data şi ora specificate în parametrii metodei.

HEAD este o metodă similară cu GET, folosită în principiu pentru testarea validităţii şi/sau accesibilităţii unei resurse, sau pentru a afla dacă s-a schimbat ceva. Sintaxa este similară metodei GET; spre deosebire de GET însă, datele eventual produse de resursă în urma cererii nu sînt transmise; doar caracteristicile acestora, şi un cod de succes sau eroare. Ceva de genul “dacă ţi-aş cere să execuţi cererea mea, ce mi-ai răspunde?”.

POST este metoda prin care resursei specificate în cerere i se cere să îşi subordoneze datele incluse în entitatea care trebuie să însoţească cererea. Cu POST se poate adăuga un fişier unui anumit director, se poate trimite un mesaj prin poştă electronică, se poate adăuga un mesaj unui grup de ştiri, se pot adăuga date unei baze de date existente, etc. Metoda POST este generală; care sînt procesele pe care un anumit server le acceptă sau cunoaşte îi sînt strict specifice.

PUT este o metodă care cere serverului ceva mai mult decît POST: să stocheze/memoreze entitatea cuprinsă în cerere cu numele specificat în URI. Dacă resursa specificată există deja, entitatea nouă trebuie privită ca o versiune modificată care ar trebui să o înlocuiască pe cea existentă. Serverul, bineînţeles, va accepta sau nu această cerere, funcţie de drepturile de acces pe care i le-a acordat clientului, şi va răspunde cererii cu informaţii corespunzătoare (“s-a făcut”, “nu pot”, “nu ai voie să faci treaba asta” etc.). Pentru a evita situaţii care să ducă la încărcarea excesivă si nejustificată a reţelei - de exemplu, un client care vrea să “posteze” un text de 10 MB, fără să ţină seama de faptul că serverul nu mai are atît loc atît o cerere de tipul POST cît şi una de tipul PUT se desfăşoară în doi timpi: întîi, clientul trimite numai parametrii metodei, fără să trimită datele efective pe care le vrea postate. După care aşteaptă 5 secunde. În acest timp, dacă serverul răspunde, clientul ia în seamă şi analizează răspunsul serverului (iar dacă acesta este “nu mai am loc”, datele nu se mai transmit). Dacă nu soseşte nici un răspuns în timpul de aşteptare, se consideră implicit că serverul acceptă datele şi acestea sînt transmise de către client.

PATCH este o metodă similară lui PUT, dar nu conţine toate datele care să definească resursa, ci numai diferenţele faţă de versiunea existentă pe server. Cu toate informaţiile necesare care să îi permită serverului să reconstruiască o versiune la zi a resursei.

COPY, MOVE şi DELETE sînt metode prin care se cere ca resursa specificată în URI-ul din cerere să fie copiată în locaţiile specificate ca parametri pentru metodă, mutată acolo sau respectiv doar ştearsă.

LINK şi UNLINK sînt metode prin care resursa specificată în cerere este legată/dezlegată de alte resurse, stabilind una sau mai multe relaţii cu acestea din urmă, specificate ca parametrii pentru metodă. Ar putea fi de exemplu un index pentru o bază de date, un cuprins pentru un set de documente, etc.

TRACE este o metodă care îi permite clientului să vadă cum ajung cererile sale la server, pentru a verifica/diagnostica conexiunea, pentru a se verifica pe sine sau pentru a determina felul în care eventualele proxy-uri de pe parcurs au modificat cererea iniţială. Serverul, în răspuns la această cerere, va trimite în ecou cererile care îi vin de la client, fără să le mai trateze ca cereri “reale”.

WRAPPED este o metodă care “contrazice” principiul protocolului de a trimite totdeauna o singură cerere şi a aştepta un singur răspuns. Via WRAPPED, mai multe cereri, care în mod obişnuit ar fi succesive, sînt “împachetate” într-una singură. Iar o altă aplicare a metodei ţinteşte măsuri de securizare - o cerere poate fi cifrată şi transmisă prin metoda WRAPPED, ceea ce va determina serverul să acţioneze în doi paşi: întîi să descifreze cererea reală, iar apoi să îi dea curs acesteia.

Capitolul 2.

Descriere generală a limbajului HTML

2.1. Introducere, istorie, versiuni

Ce este HTML?

Limbajul a fost dezvoltat iniţial de oamenii de ştiinţă ca o unealtă utilizată la partajarea documentelor (rapoarte de cercetare, documentaţii, etc) în întreaga comunitate ştiinţifică internaţională care utiliza (şi utilizează) Internetul. Pentru a publica informaţii care să fie distribuite global în Internet este necesar un limbaj universal de descriere a acestora (o „mamă a tuturor limbajelor de publicare“), limbaj care să fie potenţial înţeles de toate computerele din Internet. Limbajul folosit de World Wide Web este HTML.

HTML se aseamănă cu modalităţile de formatare a textelor de la un procesor de texte uzual în sensul că adaugă textului ce se doreşte a fi publicat (afişat) informaţii de formatare şi permite înglo- barea şi altor tipuri de informaţii (imagini, sunete, etc). Toate acestea indică modul de afişare (prezentare) pentru programele capabile să înţeleagă aceste informaţii. Ceea ce îl deosebeşte de toate celelalte formate ale procesoarelor de texte este faptul că un document HTML este un document ce conţine informaţie în format „text-pur“ (numai caractere ASCII), în timp ce procesoarele de texte folosesc formate particulare (proprietare). Astfel, un document HTML poate fi afişat (prezentat) de un număr mare de programe (browsere Web) care rulează pe un mare număr de platforme.

Documentele HTML pot fi create cu un editor de texte (document salvat ca „text only with line breaks“) sau cu editoare HTML care permit crearea vizuală (WYSIWYG) a documentelor HTML, rezultînd însă tot documente în format text pur.

Limbajul HTML dă autorilor posibilitatea:

să publice documente cu headere, texte, tabele, liste, fotografii, etc

să regăsească on-line informaţii prin intermediul hiperlink-urilor accesate printr-un simplu click de mouse

să proiecteze formulare pentru realizarea tranzacţiilor cu servere aflate la distanţă, pentru căutari de informaţie sau pentru activităţi specifice comerţului

să includă foi de calcul tabelar, clipuri video, sunete şi alte aplicaţii direct în documente

Caracteristicile limbajului HTML.

HTML are patru caracteristici principale:

1. Foloseşte un „marcaj“ descriptiv pentru a indica diversele acţiuni („instrucţiuni“) ce trebuie executate. Aceasta înseamnă că părţi ale documentului descris de HTML sînt „marcate“ cu nume descriptive, ca de exemplu <CHAPTER> sau <TITLE> care sînt aplicabile oricărei porţiuni de date corespunzătoare din document.

2. Defineşte structuri de documente ierarhice şi (hyper)legături intra- şi inter-documente. O legătură (sau interconexiune) este o relaţie unară între două elemente ale unui document. Structura unui document este însoţită de astfel de legături între elementele sale.

3. Limbajul HTML este guvernat de o descriere formală. HTML are o descriere a tipului

documentului (Document Type Definition DTD) care stabileşte specificaţiile formale ale limbajului. DTD defineşte sintaxa limbajului, descrie fiecare element individual al unui document scris în limbajul HTML, defineşte atributele permise pentru fiecare element şi descrie modelul datelor conţinute în fiecare element (adică stabileşte care alt element, dacă este vreunul, poate să apară într-un element). În corelaţie cu informaţiile despre elemente, DTD oferă definiţii pentru entităţile externe ce pot fi referite în HTML (de exemplu, setul de caractere ISO-Latin-1 folosit pentru a reprezenta caracterele pe ecranul unui display).

4. Atît specificaţiile limbajului cît şi limbajul însuşi pot fi „citite“ (interpretate) şi de om dar şi de computer. Datorită faptului că elementele de marcare sînt separate de text prin şiruri de delimitare alcătuite din caractere tipăribile, textul şi marcajele pot coexista „în pace şi înţelegere“ atît pentru om, cît şi pentru computer.

De ce HTML?

HTML este un limbaj bazat pe SGML (Standard Generalized Markup Language), o aşa-numită aplicaţie a acestuia. SGML este un standard internaţional (ISO-8879) aprobat în 1986.

SGML oferă o modalitate de a reprezenta structura documentelor şi hyper-documentelor. Este totodată şi o cale de a codifica hyper-documentele astfel ca acesta să poată fi interschimbate asemănător procesului de interschimbare a unor documente în cazul mai multor autori care colaborează utilizînd platforme diferite aflate la distanţă.

SGML este un sistem complex de descriere a documentelor. Este utilizat pentru descrierea structurii generale a diferitelor tipuri de documente fără să fie un limbaj de descrierea a paginii (cum este PostScript). Principala preocupare a SGML (şi prin urmare şi a HTML care a fost preferat pentru publicaţiile pe Web fiind mai simplu) se răsfrînge asupra conţinutului documentului, nu asupra aspectului lui.

Deci, în virtutea trăsăturilor moştenite de la SGML, HTML este un limbaj pentru descrierea documentelor structurate. Teoria din spatele acestui limbaj se bazează pe faptul că majoritatea documentelor au elemente comune (de pildă: titluri, paragrafe sau liste) şi că dacă defineşti un set de elemente, poţi marca elementele documentului cu tag-urile corespunzătoare.

Majoritatea tag-urilor HTML arată de forma: <NumeTag> Textul afectat de tag </NumeTag> şi indică navigatorului elemente de structura documentului, formatare, hypertext sau alte elemente (imagini, fişiere sonore, etc). Documentele HTML conţin doar textul propriu-zis şi tag-urile HTML iar sursa lor poate fi uşor văzută din orice navigator.

Diferenţa majoră dintre procesoarele de texte şi procesoarele HTML este că acesta din urmă nu se preocupă de cum anume vor apărea pe ecran elementele (marcate ale) documentului. Cu foarte puţine excepţii, HTML nu descrie modul de prezentare al documentului ca un întreg (layout). HTML oferă (deocamdată) un suport redus în stabilirea plasamentului sau felului în care vor fi afişate elementele documentului. Proiectanţii HTML au ales intenţionat această variantă. Motivul este simplu. Deoarece nu cunoaştem posibilităţile platformei pe care va fi văzut documentul (dimensiunea ecranului, fonturile instalate, etc), prin separarea structurii documentului de felul în care este afişat se oferă o mai mare libertate programului care înţelege HTML şi afişează documentul. Acesta poate să ia hotărîri privind formatarea documentului pe baza posibilităţilor platformei respective. Este ceea ce fac navigatoarele Web, în afara funcţiilor de comunicare şi aducere a documentelor de pe Net.

Cînd navigatorul încarcă un document HTML, el „citeşte“ documentul în căutarea tag-urilor HTML, formatează textul şi imaginea şi le afişează pe ecran. Este motivul pentru care acelaşi document HTML apare uşor diferit cînd este privit cu navigatoare diferite. Deşi în această fază de dezvoltare posibilităţile de formatare oferite sînt încă destul de limitate, oferind un control destul de redus asupra formei documentului, avantajul faptului că documentele pot fi transferate şi văzute

oriunde pe Net, independent de platformă şi de navigator, a condus la răspîndirea sa foarte rapidă.

Orice versiune a HTML include elemente cum ar fi: text centrat sau aliniat dreapta, tabele, formule matematice, aliniere imagine şi text. Extensiile, care au apărut în număr mare în ultima vreme, sînt seturi de tag-uri HTML introduse de diverse companii (în general cele producătoare de navigatoare) care permit autorilor de documente HTML să evite o parte din constrîngerile standardului. Cele mai răspîndite sînt extensiile Netscape şi Internet Explorer.

Dar de ce a fost preferat HTML pentru publicaţii pe Web, cînd pentru realizarea publicaţiilor electronice există mai multe tehnologii? Primul motiv este simplitatea. Al doilea este că permite formatarea textului ASCII cu tag-uri în format ASCII. Rezultă de aici o compresie bună, suport pentru legături hypertext şi uşurinţă în a scrie navigatoare pentru vizualizarea documentelor.

Istoria HTML.

Născut în urmă cu aproximativ 30 de ani, într-o tentativă de a rezolva unele probleme ivite la transportul documentelor între diferite computere, limbajul hypertext a evoluat încet. HTML din prima generaţie este înţeles de primele navigatoare (modul text). Nivelul 1 este obligatoriu pentru toate navigatoarele şi înseamnă posibilitatea de a interpreta (hyper)text plus imagini. Nivelul 2 (HTML 2.0) a adus o contribuţie deosebită la realizarea unei interactivităţi reale prin intermediul formularelor (forms). HTML 3.0 (cunoscut anterior ca HTML+) aduce în plus tabelele, formatarea paragrafelor (alinieri stînga, centru şi dreapta), curgerea textului pe lîngă imagini, tabele, formule matematice, taburi, note şi o mulţime de alte trăsături în aparenţă de mai mică importanţă dar care fac munca cu HTML mult mai plăcută. Cele mai importante modificări şi îmbunătaţiri sînt aduse însă de HTML 4.0, versiune care îmbunătăţeşte totodată şi conceptele de accesibilitate şi structuralitate a limbajului de marcare. Informaţii despre dezvoltarea HTML se pot prelua de la adresa: http://www.w3.org

Limbajul HTML a fost dezvoltat iniţial de Tim Berners-Lee la Laboratorul European pentru Fizica Particulelor (CERN) şi popularizat de browser-ul Mosaic dezvoltat la NCSA şi a beneficiat de explozia Web-ului din anii 90. În această perioadă HTML-ul s-a dezvoltat în multiple direcţii, dar era dependent de autorii paginilor HTML şi producătorilor de echipamente care, deşi foloseau aceleaşi convenţii pentru limbaj, aveau implementări incompatibile. De aceea s-a impus ca o necesitate absolută standardizarea HTML-ului într-un efort global al întregii comunităţi a Internetului. Şi acum HTML este un limbaj marcat de un deosebit dinamism, standardizarea diverselor versiuni fiind însă deosebit de anevoioasă datorită lipsei consensului.

Organismul care „guverna“ protocolul TCP/IP („fundamentul“ Internetului), standardele arhitecturale ale Internetului, precum şi reţeaua Internet a Statelor Unite era în acea perioadă IAB – Internet Arhitecture Board, cunoscut la începuturile sale ca Internet Activities Board. Acesta delega responsabilităţile de dezvoltare, operare şi management a Internetului şi a protocoalelor şi serviciilor legate de acesta unor subcomitete, grupuri de lucru şi organizaţii de lucru pe care le controla. În plus avea contracte cu companii comerciale specializate în comunicaţii pentru gestionarea infrastructurii Internetului.

Subgrupul care se ocupa (şi se ocupă şi acum) cu dezvoltarea şi implementarea protocoalelor este IETF - Internet Engineering Task Force. Acesta este alcătuit dintr-un comitet director (care raportează la IAB) şi o serie de grupuri de lucru, fiecare dintre acestea responsabile cu un anumit protocol sau serviciu aflat în dezvoltare sau întreţinere. Grosul activtăţii de dezvoltare şi standardizare a protocoalelor este astfel realizat de aceste grupuri de lucru din cadrul IETF.

Documentele care specifică aceste protocoale şi servicii sînt numite Request for Comments, mai cunoscute sub numele de RFC. Acestea primesc coduri numerice prin intermediul cărora sînt referite ulterior. Chiar dacă numele sugerează o „solicitare de comentarii“ asupra unui subiect (ceea ce constituie, de altfel, şi modalitatea principală de dezvoltare a acestor documente – prin

intermediul comentariilor, propunerilor şi discuţiilor membrilor comunităţii Internetului), RFC-urile

standard (care se numesc

Internet (TCP/IP). Aceste documente (standardele) reprezintă doar o parte din întreaga colecţie de RFC-uri, dar practic dictează cum trebuie să se comporte un protocol şi ce funcţii trebuie să

realizeze. În timpul dezvoltării RFC-urile se numesc RFC Working Drafts.

Dacă un protocol (sau produs) nu se conformează unui RFC standard, atunci cel ce îl dezvoltă riscă să piardă contactul (şi contractele) cu organismele ce aparţin de Departamentul Apărării al SUA, precum şi cu toate celelalte organisme şi organizaţii care le adoptă şi le respectă (ceea ce este echivalent cu excluderea din competiţia economică). În orice dispută din cadrul Internetului RFC- urile şi IETF sînt autorităţile supreme.

RFC-urile se pot obţine de pe site-ul ds.internic.net (organizate după numărul ataşat fiecărui RFC) sau de pe alte site-uri care oferă posibilităţi extinse de căutare/prelucrare, cum ar fi, de exemplu, site-ul de la adresa http://www.cis.ohio-state.edu/hypertext/information/rfc.html.

Organismul care se ocupă (şi) cu standardizarea limbajului HTML (din noiembrie 1995) se numeşte „The World Wide Web Consortium (W3C)“ şi include CERN, universitatea MIT (Cambridge, Massachusetts), precum şi alte organizaţii. În afara HTML, W3C are „custodia“ şi a protocolului HTTP, precum şi a altor produse şi standarde ce se referă la Web.

Filozofia W3C se bazează pe promovarea interoperabilităţii în World Wide Web. Aceasta necesită standarde. Aprobarea şi în special acceptarea unui standard este însă un proces extrem de mare consumator de timp, cu atît mai mult cu cît ambiţiile sînt mai mari (ISO a abandonat modelul celor 7 nivele după ce mulţi ani a încercat să-l impună). Plecînd de la păţaniile predecesorilor, pionierii Webului au împămîntenit obiceiul de a-şi construi singuri standarde şi nu de a le importa. Esenţa filozofiei W3C este implementată în grupurile de lucru (Working Group), un comitet mic de specialişti care se întîlnesc sau discută în teleconferinţe pînă la atingerea unui consens. W3C are 18 astfel de grupuri, fiecare cu 18-25 membri provenind de la orice companie ce are interese în subiectul abordat de respectivul grup. Se ajunge astfel ca rivalii să stea alături şi să coopereze, conducînd în cele din urmă la o acceptare mult mai rapidă din partea pieţii. Durata de viaţă a unui astfel de standard (unei specificaţii stabilită în acest mod) dă de fapt măsura autorităţii organizaţiei

W3C.0

Recommendation) au putere de lege (decret) în cadrul comunităţii

Stadiile prin care trece un standard elaborat de W3C sînt:

orice standard îşi începe aventura ca W3C Note

de aici este preluat de către un grup particular de lucru (Working Group) şi este discutat pînă cînd se atinge consensul

în acest moment este publicat ca propunere (Working Draft) şi acum oricine poate face comentarii

în momentul în care se obţine o susţinere şi un consens suficient de larg, directorul W3C (acum este Time Berners-Lee) decide dacă specificaţia este gata să devină propunere de recomandare (Proposed Recommendation)

urmează o perioadă de 6 săptămîni în care toţi membrii W3C au şansa să voteze această propunere de recomandare; votul nu este obligatoriu şi se poate vota în 4 moduri diferite:

da

da, sub rezerva unor îmbunătăţiri

nu, pînă cînd anumite sarcini nu sînt îndeplinite

nu, specificaţia trebuie abandonată

charta W3C stipulează necesitatea obţinerii consensului complet, astfel că fiecare vot trebuie să fie un da fără rezerve

dacă toţi paşii anteriori au fost îndepliniţi, specificaţia trebuie aprobată în final de Director şi se publică sub forma unui standard (W3C Recommendation)

HTML 2.0 a fost publicat ca standard (versiune „oficială“) sub forma Request for Comments RFC 1866 în noiembrie 1995 şi reprezintă eforturile de codificare şi standardizare ale Internet Engineering Task Force. Poate fi preluat de la adresa ftp://ds.internic.net/rfc/rfc1866.txt

A urmat apoi propunerea (draft) HTML 3.0 (în septembrie 1995), în mare măsură bazat pe HTML+

(apărut în 1993) care, deşi nu a fost adoptată ca standard a dus la adoptarea a numeroase îmbunătăţiri. Unul dintre motivele care au condus la neacceptarea draftului a fost marimea considerată exagerată a acestuia. De aceea următoarele versiuni au fost şi vor fi introduse într-un mod modular. Această versiune se poate prelua de la adresa http://www.w3.org/MarkUp/html3/CoverPage. Ea a venit după ce Netscape începuse să introducă o

serie de noi taguri şi atribute care nu erau complet specificate (versiunea aceasta de HTML fiind cunoscută sub numele de cod Mozilla), conducînd în acest fel la o implementare neuniformă în alte browsere.

Eforturile grupului de lucru asupra HTML din cadrul World Wide Web Consortium din această perioadă îndreptate spre eliminarea inconsistenţelor între specificaţiile diverselor firme/browsere au avut ca rezultat apariţia standardului (cu numele de cod Wilbur) HTML 3.2, în 11 ianuarie 1997, acestea putînd fi accesate la adresa http://www.w3.org/TR/REC-html32. Împreună cu W3C au lucrat la aceste specificaţii IBM, Microsoft, Netscape Communications Corporation, Novell, SoftQuad, Spyglass şi Sun Microsystems. Această versiune este o aplicaţie SGML ce se conformează standardului internaţional ISO 8879 ale cărui specificaţii se află la adresa http://www.iso.ch/cate/d16387.html. Ca aplicaţie SGML, sintaxa documentelor este definită de combinaţia dintre o declaraţie SGML (SGML declaration) şi definirea tipului documentului (document type definition - DTD).

Versiunea HTML 4.0 a devenit o recomandare (standard) W3C la 18 decembrie 1997 (avînd numele de cod Cougar) şi poate fi accesată la adresa http://www.w3.org/TR/REC-html40. Şi această versiune este o aplicaţie SGML ce se conformează standardului internaţional ISO 8879 ale cărui specificaţii se află la adresa http://www.iso.ch/cate/d16387.html. Ca aplicaţie SGML, specificaţia HTML 4.0 include o declaraţie SGML (1 SGML declaration), trei definiţii ale tipului documentului (3 document type definition - DTD) şi o listă de referinţe la caractere. În momentul apariţiei acestui standard, W3C recomandă autorilor producerea de documente HTML 4.0, dar pentru motive evidente de compatibilitate cu versiunile anterioare, W3C recomandă uneltelor ce interpretează şi suportă 4.0 să continue să suporte şi HTML 3.2, precum şi HTML 2.0.

În ianuarie 1999 există şi propunerea (draftul) HTML 5.0.

Întreaga comunitate a Internetului este de acord că documentele dezvoltate cu HTML trebuie să fie identice în diversele browsere şi pe diversele platforme ale Internetului. Interoperabilitatea va

asigura astfel costuri reduse furnizorilor (autorilor) de pagini HTML (nu este nevoie decît de o singură versiune!), în caz contrar răspîndirea într-o multitudine de formate particulare (şi proprietare ale unor firme) incompatibile reducînd dramatic potenţialul (inclusiv comercial) al tuturor participanţilor. Fiecare nouă versiune a încercat să reflecte un consens din ce în ce mai mare între participanţi, astfel ca investiţiile făcute să nu fie irosite, iar documentele dezvoltate să devină imposibil de folosit după o perioadă foarte scurtă de timp. Limbajul HTML se dezvoltă cu dorinţa ca toate tipurile de computere şi diversele periferice ale acestora să poată folosi informaţia de pe Web: PC-urile cu display-uri de diverse rezoluţii şi capabilităţi de redare a culorii, periferice pentru cuplare prin intermediul vocii, telefoane celulare, etc

Ce trebuie să facă un autor de pagini HTML?

HTML 4.0 este în acest moment (ianuarie 1999) standardul acceptat de comunitatea Internet şi de către producătorii majori de browsere şi unelte de dezvoltare pentru Internet (Netscape – cu browserul Navigator 4.x şi – cu browserul Microsoft Internet Explorer 4.x), primind suport aproape universal. W3C recomandă chiar autorilor de documente şi unelte pentru HTML să producă documente HTML 4.0 în locul HTML 3.2, dar din motive de compatibilitate (uşor de înţeles) se recomandă ca uneltele ce interpreteză HTML 4.0 să suporte în continuare HTML 3.2 şi 2.0.

Bătăliile se dau în continuare pentru standardele legate de DHTML (CSS Level 2 şi DOM). Chiar dacă modul în care a fost creată versiunea 4.0 şi soliditatea organismului care a generat-o indică o mare stabilitate, Microsoft a făcut deja paşi importanţi pe cale 5.0 şi spre DHTML, urmată, aproape cu disperare, şi de către Netscape (la sfîrşitul anului 1998 cumpărată de AOL). Concluzia ce se poate desprinde este aceea că dinamismul procesului nu poate fi „combătut“ decît printr-o permanentă informare de la organismul care impune standardele (W3C) şi adaptare la cerinţele acestora.

Revoluţia HTML 4.0.

Elementul esenţial diferit adus de versiunea 4.0 faţă de versiunea 3.2 este posibilitatea separării structurii unui document de prezentarea lui prin introducerea „stilurilor de documente“ (style sheet). Utilizînd limbajul HTML pentru descrierea structurii unui document şi style sheet-urile pentru a sugera prezentarea acestuia, autorii obţin mult mai uşor independenţa de periferic/computer/platformă hard-soft care a făcut HTML-ul atît de popular. Un document cu o structură complexă poate fi prezentat în diferite moduri pe medii diferite, permiţînd documentului însuşi să se adapteze mai uşor noilor tehnologii (cum ar fi, de exemplu, browser-ele capabile să vorbească, cititoarelor braille, etc.).

În plus separarea conţinutului de prezentare permite modificarea înfăţişării eventual chiar a unui întreg site doar prin modificarea unui style-sheet (unui document care descrie stilul). Experienţa a demonstrat că o astfel de abordare reduce dramatic costurile de deservire a unui spectru larg de platforme, facilitînd şi o întreţinere şi modificare mult mai uşoare.

Alte îmbunătăţiri semnificative aduse de 4.0 pot fi considerate şi:

I. Tehnologia client-side scripting.

Prin intermediul scripturilor autorii pot realiza pagini HTML dinamice (care reacţionează la acţiunile utilizatorilor) sau se pot realiza aplicaţii distribuite. Mecanismul de includere a scripturilor în paginile HTML este independent de limbaj. Se poate specifica limbajul scriptului, se poate include un script extern sau se poate referi rezultatul execuţiei unui script. Aceste scripturi se execută pe computerul care rulează browserul Web (clientul).

II. Documentele compuse

HTML oferă acum un mecanism standard pentru a îngloba obiecte generice şi aplicaţii în documentele HTML. Elementul OBJECT permite includerea imaginilor, clipurilor video, sunetului, formulelor matematice, aplicaţii specializate şi alte obiecte într-un document.

III. Internaţionalizarea

Această versiune a fost proiectată cu ajutorul experţilor în internaţionalizare, astfel încit documentele pot fi scrise în orice limbă şi transportate uşor oriunde în lume. Elementul cheie îl constituie adoptarea standardului ISO/IEC 10646 ca set de caractere pentru HTML. Acest standard este cel mai complet standard ce permite reprezentarea oricăror caractere internaţionale, direcţie a textului, punctuaţie sau cerinţe specifice ale unei limbi.

IV. Accesibilitatea

Odată cu creşterea diversităţii lumii Webului, s-au diversificat şi capabilităţile utilizatorilor acestuia, astfel încît a devenit importantă suportarea diverselor tehnologii pentru a suplinii unele limitări fizice.

V. Tabele îmbunătăţite

În această versiune se implementează un model de tabel, bazat pe RFC 1942. Autorii au acum un control sporit asupra structurii şi paginaţiei. Sînt incluse posibilităţi de definire a grupurilor de rînduri şi/sau coloane, mai mare flexibilitate în definirea regulilor unui tabel. În plus afişarea tabelelor se face acum incremental, pe măsura încărcării paginii, nemaifiind necesară aşteptarea încărcării integrale a tabelelor.

VI. Model îmbunătăţit de împărţire a unui document în frame-uri

Includerea frame-urilor în HTML 4.0 oferă posibilitatea de a prezenta documente multiple într-o singură fereastră. Modelul este preluat din propunerea originală a firmei Netscape.

VII.Imprimare îmbunătăţită a paginilor Web

Operaţia de imprimare a unui număr mai mare de pagini legate între ele poate fi simplificată mult prin descrierea relaţiilor dintre ele utilizînd elementul LINK sau limbajul specializat RDF (Resource Description Language) dezvoltat de W3C.

Validarea documentelor HTML.

Fiecare document trebuie validat în vederea eliminării erorilor cum ar fi lipsa ghilimelelor, elemente sau atribute scrise greşit şi structuri invalide. Aceste erori nu sînt întotdeauna vizibile în browsere deoarece fiecare le recuperează într-un mod propriu. Validarea documentelor se poate face cu un serviciu special al W3C ce poate fi accesat la adresa http://validator.w3.org. Un validator verifică un document în ceea ce priveşte definiţia tipului documentului (DTD) şi nu siguranţa legăturilor din document.

2.2. Reprezentarea documentelor HTML

Ca aplicaţie (standard) SGML, limbajul HTML trebuie (pentru a se supune normelor de interoperabilitate) să specifice propriul set de caractere care se foloseşte în codificarea documentelor.

Un set de caractere al unui document constă din:

un repertoar:

un set de caractere abstracte, cum sînt litera alfabetului latin „A“, litera alfabetului chirilic „I“ sau semnul chinezesc care înseamnă apă

poziţiile codurilor: un set de întregi ce referă caracterele din repertoar

Fiecare document HTML este o secvenţă de caractere din repertoar. Computerele identifică aceste caractere prin poziţia acestora în repertoar. De exemplu în setul de caractere ASCII poziţiile 65, 66 şi 67 referă caracterele A, B şi C.

Caracterele utilizate pentru editarea textelor în documentele HTML ar trebui să aparţină setului standard ASCII (caractere pe 7 biţi) şi fără a include caractere din setul extins (pe 8 biţi) deoarece diversele platforme utilizează definiţii diferite pentru caracterele din setul superior ASCII. Dar, acest set de caractere este insuficient pentru un sistem informaţional global, aşa cum este Webul. De aceea limbajul HTML utilizează un set de caractere mult mai comple, numit Universal Character Set – UCS (Setul de caractere universal) definit de standardul ISO 10646, standard ce defineşte un repertoar de mii de caractere utilizate în întreaga lume. Acest set de caractere este echivalent caracter-cu-caracter cu setul Unicode 2.0 definit de W3C.

Acest set de caractere nu este însă suficient pentru agenţii utilizator ca să interpreteze corect un document HTML transmis ca o secvenţă de bytes într-un fişier sau în reţea. În afara setului de caractere, aceştia trebuie să cunoască şi codificarea caracterelor (character encoding) folosită la transformarea documentului într-un stream de bytes. Prin codificarea caracterelor (termenul utilizat fiind acela de „charset“) se poate înţelege metoda de conversie a unei secvenţe de bytes într-o secvenţă de caractere. Această conversie se potriveşte perfect cu schema activităţilor Webului:

serverele trimit documentele utilizatorilor (agenţilor utilizatori) ca un stream (şir) de bytes, iar aceştia îi interpretează ca şiruri de caractere. Metoda de conversie poate să mergă de la o corespondenţă simpla unu-la-unu pînă la scheme şi algoritmi complexe. O singură corespondenţă simplă unu-la-unu nu este însă suficientă pentru un repertoar aşa de complex ca cel definit de ISO 10646 (sau de Unicode). De aceea există diferite codificări ale unor părţi ale acestui repertoar pentru a-l acoperi în întregime. Cele mai uzuale codificări sînt: ISO-8859-1/ISO Latin 1 (utilizat pentru limbile Europei de vest), ISO-8859-2/ISO Latin 2 (care suportă alfabetul chirilic), SHIFT_JIS (codificare japoneză), ş.a.

Uneltele software care produc documente HTML le pot codifica oricum (nu se impune nimic) încercînd să „acopere“ cît mai multe dintre caracterele acestuia. Cele care nu se pot codifica cu schema folosită se pot totuşi referi prin intermediul caracterelor entităţi (acestea referindu-se la setul de caractere şi nu la schema de codificare). Cel care foloseşte aceste documente (agenţii utilizatori) poate modifica această codificare (proces numit transcodare) şi nu este obligat să proceseze documentul utilizînd aceeaşi codificare sau o codificare care să acopere întregul set de caractere. DAR, pentru a obţine aceleaşi rezultate cu cele dorite de autorul documentului, agenţii utilizatori trebuie să fie în primul rînd „conformi Unicode“ (adică să mapeze corect toate caracterele Unicode în toate codificările recunoscute) şi să cunoască schema de codificare folosită de autor.

Informaţia care specifică schema de codificare trebuie să fie oferită de server. Cea mai simplă şi directă modalitate de a o specifica este utilizarea unui parametru specific (charset) într-un cîmp (Content-type) al antetului protocolului HTTP utilizat la transmiterea documentelor.

De exemplu, următorul antet HTTP anunţă că pentru documentul solicitat s-a folosit schema de codificare EUC-JP:

Content-Type: text/html; charset=EUC-JP

Dar nu toate serverele ştiu să folosească acest parametru. Pentru a fixa această problemă, documentele HTML pot include informaţii explicite despre schema de codificare folosită. Pentru aceasta se foloseşte un element specific al limbajului (META). Pentru cazul de mai sus:

<META http-equiv="Content-Type" content="text/html; charset=EUC-JP">

Mai mult, dacă nu se foloseşte nici această metodă, limbajul HTML a prevăzut un atribut special (charset) ce se poate ataşa elementelor din cadrul documentului.

Implicit, dacă nu este folosită nici una dintre aceste 3 posibilităţi, se consideră documentul codificat ISO-8859-1. Fiecare agent utilizator trebuie să ofere o metodă