Чому XML і XSLT?
Жив був сайт. Звичайний самопісанний сайт. Поки він був маленький, мало оновлювався і погано відвідували, то особливої потреби щось змінювати не було. Сайт працював на cp1251, нікого не чіпав. Але в один прекрасний момент інформація, яка накопичувалася, як пил за монітором, раптом стала потребувати структуризації і більш грамотному поданні. Потрібно було кардинально змінювати застарілий движок, а якщо точніше, то прикрутити шаблони.
Порившись в засіках пам'яті і повивчавши інет, я змалював для себе два типи шаблонизатор - PHP-залежні і XSLT.
PHP-залежні шаблонизатор - це програми для махінацій над шаблонами довільного формату, в результаті, яких виходить робочий PHP-сценарій з потрібним функціоналом. Найяскравішим представником таких шаблонизатор є, звичайно ж, Smarty. Такі шаблонизатор відрізняє дуже висока швидкість роботи, гнучкий синтаксис і повна залежність від пхп.
XSLT-шаблони - це XML-файли, які містять правила обробки вихідного XML-файла. В результаті обробок може вийти текстовий документ будь-якого формату, хоч HTML, хоч той же пхп. Обробкою таких шаблонів займається окремий модуль, при цьому витрачається досить багато ресурсів.
Однак, незважаючи на порівняно великі ресурсовитрати, використання XSLT дозволяє позбутися від PHP-залежності і чітко відокремити шаблон від даних. Крім того, і XML, і XSLT стандартизовані, а їх підтримка впроваджена далеко за межі пхп. Тобто, одного разу сформований шаблон, можна використовувати як завгодно і де завгодно.
Ще одним важливим плюсом XSLT є його повна нетерпимість до помилки і структурним помилок. Тобто, якщо шаблон робочий, то він і буде працювати, незалежно від вхідних даних. Якщо ж шаблон містить якусь помилку, то ви дізнаєтеся про це відразу.
Взесів все «за» і «проти», я розсудив так - XSLT, це зручний, добре документований мову шаблонів, який підтримується більшістю сучасних браузерів і дозволяє вивести обробку даних на абсолютно новий рівень.
Після ряду експериментів на локальній машині, рішення використовувати XSLT було прийнято остаточно і безповоротно.
Чому UTF-8?
Спочатку сайт прекрасно працював на windows-1251, і міняти це кодування я не хотів. Та й навіщо щось міняти, якщо і так все працює.
У локальних тестах з XML ніяких проблем з windows-1251 не спостерігалося. Але милиці не змусили себе довго чекати. При портировании XML на пхп вималювалися деякі трабли.
Поки код був таким, проблем не було:
Щоб розібратися, чим не догодили 0xC7 0xE0 0xE3 0xEE. довелося провести ряд експериментів. В результаті з'ясувалася одна проста, але дуже важлива річ. Кодування, яка була вказана при створенні об'єкта документа, це не вихідна, як я наївно думав, а результуюча. Тобто, поки рядки 'Тема' і 'Вміст' були в windows-1251 (при лобой кодуванні DOMDocument), нічого доброго не було. Але варто було їх перевести в UTF-8, як все працювало на ура.
Розібравшись з кодуванням при створенні, перерив всю документацію щодо DOMDocument. в надії, що якось можна задати вихідну кодування. У підсумку, нічого нового не вдалося відшукати.
Висновок, який довелося зробити, був невтішним - хочеш працювати з DOMDOcument. працюй в UTF-8. До речі, SimpleXML теж не виняток, його раціон вхідних даних повинен бути виключно з UTF-8.
Тому питання про кодування сайту було вирішене однозначно - тільки UTF-8.
Переводимо всі файли сайту в UTF-8
Багато хто скаже: «50 файлів?! ... - баран чхнув», мовляв, великі сайти складаються з тисяч файлів. І дійсно, 50 файлів - це двадцять хвилин роботи. Але. у мене закралася думка, що це дійство, можливо, вже хтось автоматизував до мене.
Погуглити простори інтернету, я виявив, що програм, які мене цікавили, видається тільки дві - одна під консоль, друга під .NET. Причому перша не підтримувала UTF-8, а друга просто не запускалася - шкідливий фреймвок ні встановлено.
Від безвиході і небажання займатися пересохраненіем за методом багаторазового тику, довелося взяти в руки Visual Basic і написати потрібну програму самому. В результаті вийшла утиліта під назвою recoder.
Озброївшись recoder. я перевів всі потрібні файли з windows-1251 в UTF-8 за пару секунд. Здавалося, що мета досягнута. Однак, знайшлося ще одне однако. - recoder спрацював рівно на 100% і при збереженні файлів додав сигнатуру UTF-8, т.зв. BOM.
Сигнатура BOM - це три спеціальних байта, які йдуть на початку файлу і повинні сигналізувати, що сам файл містить UTF-8. Але проблема в тому, що BOM носить опціональний характер і може бути, а може і не бути. При цьому PHP знати не знає, що це за звір, і як з ним працювати. Тому мій проект виявився в жалюгідному стані - при підключенні будь-якого файлу вилазила нікому не потрібна сигнатура UTF-8.
Для вирішення проблеми з BOM, довелося знову засукати рукава і писати ще одну утиліту. Так народилася програма bom-remover. Можливо, подібних програм більше, ніж перекодировщик, але, як то кажуть, гуляти так гуляти!
І ось вже після шліфування bom-remover. сайт формально був переведений на UTF-8. Щоб остаточно попрощатися з windows-1251, треба було просто змінити локаль і виставити кодування.
Налаштування для UTF-8 вийшли такими: