Защо XML и XSLT?
Имало едно време един сайт. Неутрално сайт samopisanny. Докато беше малка, малко дата и слабо посетен, специалните нужди не се променя нищо. Гордост, задвижвани от cp1251, никой не докосна. Но в един момент, информацията, която се натрупва като прах зад монитора, изведнъж започна да се нуждаят от повече структура и подходящо представяне. Беше необходимо да се промени остарели двигателя драстично, и по-точно, моделите равенството.
Рови в кофите за памет и poizuchat Inet, I, описана за двата вида шаблони - PHP-зависими и XSLT.
PHP-зависима шаблони - програма за манипулиране на модели на произволен размер, в резултат на което се получава работна PHP-скрипт с необходимата функционалност. Най-яркият представител на шаблони е, разбира се, Smarty. Такава темплейт се характеризира с много висока скорост, гъвкав синтаксис и пълна зависимост от PHP.
XSLT-шаблони - един XML-файлове, които съдържат правила за обработка на оригиналната XML-файл. В резултат на това лечение може да се превърне текстов документ във всякакъв формат, въпреки че HTML, въпреки че същото PHP. Обработването на такива модели е отделен модул в същото време прекарах много ресурси.
Все пак, въпреки сравнително голям разход на ресурси, използването на XSLT ви позволява да се отървете от PHP-базирани и ясно разграничено от базата данни на шаблон. В допълнение ,, XML, XSLT и и стандартизирана, и тяхната подкрепа се осъществява извън рамките на PHP. Това означава, че след формира шаблон може да се използва по всяко време и навсякъде.
Друго важно предимство на XSLT е неговата пълна нетърпимост към правописни грешки и структурни грешки. Това означава, че ако работи схемата, и тя ще работи, независимо от входните данни. Ако шаблонът съдържа грешка, тогава вие ще знаете за него веднага.
Vzesiv "за" и "против", разсъждавах така - XSLT, е удобно, добре документиран език модел, който се поддържа от повечето съвременни браузъри и ви позволява да показвате обработка на данни на съвсем ново ниво.
След поредица от експерименти върху локалната машина, бе решено да се използва XSLT веднъж завинаги.
Защо е UTF-8?
Първоначално сайтът работи добре на Windows-1251, както и за промяна на кодирането не исках. И защо се промени нещо, ако и защото тя работи.
В местните тестове с XML не се наблюдава никакъв проблем с прозорци-1251. Но костите не са дълги в следващите. Когато пренасянето XML PHP очертае някои неприятности.
Докато кода е такава, че не е имало проблем:
За да разбера какво не угоди 0xC7 0xE0 0xE3 0xEE. Аз трябваше да извърши серия от експерименти. Резултатите показват, един прост, но много важно нещо. Кодирането което е било указано, когато предметът на документа не е оригиналът, както аз наивно мислех, така и получените. Това означава, че докато линията "Заглавие" и "съдържание" бяха прозорци-1251 (когато loboy кодиране DOMDocument), не беше добро. Но това беше необходимо, за да ги преведете на UTF-8, тъй като е работил по ура.
След като приключва с кодирането да се създаде, аз се разрови цялата документация по отношение на DOMDocument. с надеждата, че по някакъв начин можете да посочите източник кодиране. В крайна сметка, нищо ново не може да бъде намерен.
Изводът, който трябваше да направя, беше разочароващо - ако искате да работите с DOMDocument. и работи в UTF-8. Между другото, SimpleXML не е изключение, неговата диета трябва да е вход само от UTF-8.
Следователно, въпросът за мястото на кодиране и бе извършено плащането по недвусмислен начин - само UTF-8.
Ние превеждаме всички файлове на сайта в UTF-8
Мнозина ще кажат: -, казват те, големите сайтове се състоят от хиляди файлове "... 50 файлове овце кихат?!". В действителност, 50 файлове - това е двадесет минути работа. Но. Промъкнах се в идеята, че това действие може да има някои автоматизирани за мен.
Да потърсите с Google в интернет, разбрах, че програмите, които ме интересува, се издава само два - по един за конзолата, а вторият под .NET. И първо аз не подкрепям UTF-8, а другият просто не се стартира - злонамерен freymvok не е установена.
От отчаяние и нежелание да се ангажират с overstoring метода повтаряща се на случаен принцип, трябваше да се вземат в ръка, и Visual Basic да напише изисква самата програма. Резултатът е един инструмент, наречен recoder.
Въоръжени с recoder. Преведох всички необходими файлове от Windows-1251 за UTF-8 за няколко секунди. Струваше ми се, че целта е достигната. Въпреки това, открих още един все пак. - recoder работил точно 100%, а при записването на файловете добавени подпис UTF-8, така наречените BOM.
Подписът на BOM - това са три специални байта, които идват в началото на файла, и трябва да е сигнал, че самият файл съдържа UTF-8. Но проблемът е, че BOM е по избор и може или не може да бъде. В този случай, PHP не знае ли какво е животно, и как да го използвате. Ето защо, моя проект е в лошо състояние - при наличието на файлови изкачвания никой няма нужда от подписване на UTF-8.
За решаване на проблема с BOM, аз трябваше да запретнем ръкави и отново пиша друг полезност. Така се ражда програмата за BOM-отстраняване. Може би такива програми повече от конвертори, но както се казва, ходи да ходи!
И сега, след смилане BOM-отстраняване. сайтът бе официално прехвърлен в UTF-8. Най-накрая да се сбогува с прозорци-1251, е необходимо просто да промените локала и зададете кодирането.
Настройки за UTF-8 оказаха такова:
Свързани статии