Traducem site-ul în xml, xslt și utf8

De ce XML și XSLT?

A fost un site. Site-ul obișnuit descris de sine. În timp ce era mic, puțin actualizat și slab participat, atunci nu exista nicio nevoie specială de a schimba nimic. Site-ul a lucrat pe cp1251, nu a contactat pe nimeni. Dar, la un moment dat, informațiile care se acumulează, precum praful din spatele monitorului, au început brusc să aibă nevoie de structurare și de o prezentare mai competentă. A fost necesar să se schimbe drastic motorul depășit și, mai precis, apoi strângeți șabloanele.







După ce am intrat în coșurile de memorie și am studiat inet, mi-am subliniat două tipuri de șabloane - PHP-dependent și XSLT.

Șabloanele dependente de PHP sunt programe pentru manipularea șabloanelor de format arbitrar, rezultând un script PHP care funcționează cu funcționalitatea necesară. Cel mai strălucit reprezentant al unei astfel de template-uri este, desigur, Smarty. Astfel de mașini templante se disting printr-o viteză foarte mare de lucru, sintaxă flexibilă și dependență deplină de npp.

Șabloanele XSLT sunt fișiere XML care conțin reguli pentru procesarea fișierului XML original. Ca urmare a procesării, puteți obține un document text de orice format, chiar dacă HTML, cel puțin același php. Prelucrarea acestor șabloane este tratată de un modul separat, cu o mulțime de resurse fiind irosite.

Cu toate acestea, în ciuda costurilor relativ mari ale resurselor, utilizarea XSLT vă permite să scăpați de dependența de PHP și să separați clar șablonul de date. În plus, XML și XSLT sunt standardizate, iar suportul acestora este implementat cu mult peste limitele PPP. Adică, după formarea șablonului, îl puteți folosi oriunde și oriunde.

Un alt avantaj important al XSLT îl reprezintă intoleranța sa completă la erorile de tipar și de structură. Adică dacă șablonul funcționează, atunci acesta va funcționa, indiferent de datele de intrare. Dacă șablonul conține o eroare, veți afla imediat despre aceasta.

După ce am cântărit toate avantajele și argumentele, am argumentat - XSLT, este un limbaj șablon convenabil și bine documentat, care este susținut de majoritatea browserelor moderne și vă permite să aduceți procesarea datelor la un nivel complet nou.

După o serie de experimente pe mașina locală, decizia de a utiliza XSLT a fost luată definitiv și irevocabil.







De ce UTF-8?

Inițial, site-ul a funcționat bine pe Windows-1251 și nu am vrut să schimb această codificare. Și de ce să schimb ceva, dacă așa funcționează?

În testele locale cu XML, nu s-au observat probleme cu windows-1251. Dar cârjele nu au durat mult. La portarea XML la PPP, au fost evidențiate unele probleme.

În timp ce codul a fost astfel, nu au existat probleme:

Pentru a înțelege ce nu te rog 0xC7 0xE0 0xE3 0xEE. a trebuit să efectueze o serie de experimente. Ca urmare, sa dovedit un lucru simplu, dar foarte important. Codificarea specificată la crearea obiectului documentului nu este originală, așa cum am crezut naiv, ci rezultatul. Adică, în timp ce liniile "Titlu" și "Conținut" erau în ferestrele-1251 (cu falsul DOMDocument), nu era nimic bun. Dar de îndată ce au fost transferați la UTF-8, totul a durat cu un bang.

După ce sa confruntat cu codificarea la creație, a scos toate documentele referitoare la DOMDocument. în speranța că într-un fel puteți seta codarea originală. Ca rezultat, nimic nou nu a putut fi găsit.

Concluzia care trebuia făcută a fost dezamăgitoare - vrei să lucrezi cu DOMDOcument. lucrează în UTF-8. Apropo, SimpleXML nu este, de asemenea, o excepție, dieta sa de date de intrare ar trebui să fie exclusiv de la UTF-8.

Prin urmare, problema codării site-ului a fost rezolvată în mod unic - doar UTF-8.

Traducem toate fișierele site-ului în UTF-8

Mulți vor spune: "50 de dosare ?! ... - berbecul strănut", spun ei, site-urile mari constau în mii de fișiere. Într-adevăr, 50 de dosare sunt douăzeci de minute de muncă. Dar. Am intrat în gândul că această acțiune, probabil, cineva mi-a automatizat deja.

Googling pe Internet, am constatat că programele care m-au interesat, există doar două - unul sub consolă, al doilea sub. NET. Și primul nu a susținut UTF-8, iar cel de-al doilea pur și simplu nu a început - cadrele malware nu au fost instalate.

De la disperare și de la lipsa de a face față salvării prin metoda mai multor atacuri, a trebuit să recuperez Visual Basic și să scriu singur programul necesar. Rezultatul este un utilitar numit recoder.

Înarmare cu un recoder. Am tradus toate fișierele necesare de la Windows-1251 la UTF-8 în câteva secunde. Se părea că obiectivul a fost atins. Totuși, a mai existat încă una. - Recorderul a lucrat exact la 100% iar la salvarea fișierelor sa adăugat semnătura UTF-8, așa-numita. BOM.

Semnătura BOM este de trei octeți speciali care merg la începutul fișierului și trebuie să semnaleze că fișierul în sine conține UTF-8. Dar problema este că BOM este opțională și poate fi sau nu poate fi. În același timp, PHP nu știe ce fel de animal este sau cum să lucreze cu el. Prin urmare, proiectul meu a fost într-o stare de teamă - atunci când ați conectat orice fișier, ați urcat o semnătură UTF-8 care nu a fost necesară de nimeni.

Pentru a rezolva problema cu BOM, a trebuit să mă rostogolească din nou mânecile și să scriu o altă utilitate. Deci, sa născut programul Bom-remover. Poate că există mai multe astfel de programe decât recrindere, dar, cum se spune, este o plimbare pe jos!

Și acum, după ce lustruiți bomura. site-ul a fost transferat formal la UTF-8. În final, să-ți spui la revedere ferestrele-1251, trebuie doar să schimbi localizarea și să expui codificările.

Setările pentru UTF-8 au fost după cum urmează:







Articole similare

Pagina anterioară

Pagina următoare

Trimiteți-le prietenilor: