PHP+XML

[neko]

В данном конкретном случае приходится. :-(

а оттрансформировать в HTML, что, несудьба?

Что-то я не понимаю твою терминологию.
Конкатенация чего? Дописывать в файл что-ли? А редактировать как?

ну что тут непонятного
надо сформировать xml документ перед отдачей процесоору
в данном случае скрипт просто исполняет роль сборщика
если у тебя вообще все берется из файла (в случае с базой там чуть сложнее) то он там php вообще не нужно сразу отдать процесоору и все.

а насчет редактирования какие тут проблемы то?
тоже самое абсолютно

В моём понимании ДОМ на php - извращение ;-)

ну если так им пользоваться то да, невопрос
ты подумай что ты делаешь
ты делаешь свой процессор
нафига спрашивается когда с php идут как минимум 2 готовых?

Понимаю к чему ты клонишь, но тут играет роль не мой редактор, а редактор человека, какой это будет администрировать. А у него notepad. :-(

ну а если так
то какая вообще разница, пускай берет и правит твой xml файл

 

[jahson]

нотепад в ХП понимает utf8.

 

[Julik]

Так как все же быть

Тем не менее - у меня полный юникод, SQL->PHP->DOM->XSLT

Назначаемое содержимое атрибутов конвертируется в unicode entities. Возвращаются программно эти значения нормально (entities раскодируются как надо), XSL-процессор их тоже раскодирует корректно, но "промежуточный" XML совершенно нечитаем.

Может есть какая-то функция которая может в уже готовом XML это entities разобрать обратно в нормальные юникодные русские буквы (то есть чтобы в виде entities оставались только "критичные" символы, которые по спецификации XML должны быть escaped)?

Держать DOM в 1251 несолидно (надо конквертить каждое передаваемое значение и все преимущества UTF теряются), переводить все скрипты обратно в 1251 тоже неохота.

 

[Alexandre]

<?xml version="1.0" encodind="windows-1251" ?>
не пробовал?

у меня ни когда с кодировкой в ДОМ проблем не было

 

[Julik]

1. Не понял, причем тут XML-пролог. Я же говорю - данные достаются из базы, обрабатываются скриптом и вставляются в DOM прямо в UTF. Потом UTF-ный же XSL это трансформирует в UTF-ный же HTML.

2. Если я буду создавать DOM-документ с кодировкой 1251 то мне придется:
а) конвертить все строки из UTF в 1251 при отправке их в DOM (большой гемор)
б) терять при этом все символы, которые как раз UTF позволяет сохранить (диакритика, а потенциально - иврит, китайский и далее со всеми).

Всю цепочку надо оставить юникодной.

 

[Alexandre]

Julik извини, не все до конца понял,

данные достаются из базы, обрабатываются скриптом и вставляются в DOM прямо в UTF

проверь xml который генерится из БД, какая там кодировака

Потом UTF-ный же XSL это трансформирует в UTF-ный же HTML

попробуй задать
<xslutput
method = "html"
encoding = "UTF-8"
/>

 

[Julik]

непонятки ;-)

база - PostgreSQL, кодировка базы - UTF, кодировка самого скрипта UTF и кодировка соединения с базой тоже UTF. Кодировка XSL-шаблона - UTF и более того - кодировка DOM тоже UTF. Короче говоря, полный Юникод.

Но при отправке текста в атрибуты DOM- узлов оный текст конвертится в числовые entities (амперсанд + юникодный индекс русской буквы). При присвоении содержимого узла русский текст остается "как был".

Никакой XML из БД не генерится. Данные из базы достает PHP-скрипт и кладет в формируемое DOM-дерево.

При обработке XSLT эти entities корректно транслируются в русские буквы, то есть окончательный XHTML-результат нормальный, но мне надо иметь "человекочитаемый" промежуточный XML (чтобы человек, который сайт будет поддерживать, мог в этом XML разобраться и править XSL-шаблон).

Подозреваю, что это один из двух тысяч багов в DOMXML.

Просто "склеивать" строки XML в PHP-скрипте не годится (генерировать его библиотекой - единственный способ на 100% быть уверенным, что он получится валидным, да и доступ ко всему дереву удобен).

 

[Long]

Julik генерировать xml через DOM это очень не разумное использование ресурсов. в обратную сторону - разбирать xml - согласен, часто бывает оптимальнее. а чтобы на 100% быть уверенным в валидности - напиши схему и проверяй по ней - вот тут ты точно получишь 100% гарантию.

 

[Alexandre]

Никакой XML из БД не генерится. Данные из базы достает PHP-скрипт и кладет в формируемое DOM-дерево.

под этим я и понимал - генерения xml из БД,
вывиди все что находится в ДОМ Дереве в отдельный файл и посмотри кодировку

-~{}~ 17.08.04 10:24:

если там не то - то ты прав:

это один из двух тысяч багов в DOMXML.

 

[Julik]

нда

2 Long:
Во-первых, я несколько криво выразился - четкой схемы (или DTD) у меня еще нет. Зато есть орда авторов и участников на сайте, так и жаждущих впихнуть в тексты какой-нибудь незакрытый FONT или другую лажу (то есть меня волнует для начала, чтобы документ был well-formed, иначе его XSL не съест и юзер увидит пустую страницу). Если DOMXML все эскейпит, то при использовании конкатенации о конверсии entities и убирании тегов я должен думать сам.

Можно конечно использовать XML::FastCreate, но все равно - как при таком раскладе например дописать атрибут в корневой элемент непонятно. Надо думать.

2 ALexandre
а я делаю просто dump_mem() из DOM, и в этом дампе вижу эти атрибуты. На самом деле все что там нужно - это написать какой-то простейший скрипт который русские entities (а лучше вообще все entities ;-) конвертит в буквы. По идее такой функционал есть в XML::Beautifier, но при его применении русские entities очень эффективно превращаются в знаки вопроса ;-) чтобы это пофиксить придетися разбирать по косточкам XML::Util, чего делать неохота. Такой документ раскодируется XSL нормально (да и вообще, по спецификациям character references любой XML-процессор "разворачивает" до символов при первой необходимости сам), только человек такой XML прочесть не может.

Жалко что никто в 4 PHP этот DOM уже чинить не будет, а для 5 скрипты переписывать.

 

[Alexandre]

я делаю просто dump_mem() из DOM,

а для чистоты эксперимента надо сделать то, что предлагаю я

 

[Julik]

теперь я не понимаю

/* Cкрипт отконвертить в UTF для демонстрации эффекта */

$_DOM = domxml_new_doc ('1.0');

/* Создаем корневой элемент */
$_element = $_DOM->create_element ('bogus');

/* Присваиваем значение атрибута */
$_element->set_attribute ('bogus', 'русские буквычки');

/* В скрипт значение атрибута возвращается правильно */
echo 'Attribute value is ' . $_element->get_attribute ('bogus');

$_element = $_DOM->append_child ($_element);

/* Далеам dump_mem - получаем entities */
echo $_DOM->dump_mem ($pretty = 0, 'UTF-8');

/* Пишем в файл - опять получаем entities*/
$len = $_DOM->dump_file ('/xmlout.xml', $compress = false, $indent = false);

Что там еще то можно придумать?

 

[Alexandre]

попробуй DomDocument->html_dump_mem

echo "<PRE>";
echo htmlentities($doc->dump_mem(true));
echo "</PRE>";

 

[Julik]

не помогает

похоже я идиот, но не помогает
если делать htmlentities то те character references которые уже есть кодируются повторно (то есть амперсанд в их начале превращается в amp)

у тебя то вышеприведенный скрипт сработал правильно? может дело в версии PHP? у меня 4.3.3

 

[Alexandre]

тогда html_entity_decode().

 

[Julik]

ха!

Warning: cannot yet handle MBCS in html_entity_decode()! in /тамтотамто/includes/autofooter.php on line 61

Мы его так, а он нас сяк

видимо придется самому функцию изобретать которая такие entities конвертит

ALexandre, у тебя мой скрипт нормальные атрибуты производит или нет?

 

[voituk]

Originally posted by Alexandre
тогда html_entity_decode().

Не поможет. Потому как html_entity_decode() принимает входную строку состоящую из сущностей, представленных 10-чным чиcлом (например \&\#1001\ , а DOM-дерево возвращает сущности в 16-ричных числах (например \#\x412\

Можно написать функцию, какая бдет представлять 16-ричные сущности в 10-чные, но за немимением времени, и низкого приоритета этой задачи, я пока её не писал.
Если кто напишет - поделитесь ;-)

 

[Julik]

глюкодром

Сейчас посмотрю как оно в пятом себя ведет.

А пока что придется все потенциально русские атрибуты в промежуточном XML сливать в дочерние элементы. Что есть глупость.

-~{}~ 17.08.04 18:52:

Кто может проверить эту историю с атрибутами на PHP 5? У меня какие-то дурацкие ошибки лезут, а разбираться времени нет (проект надо делать) :-(

 

[voituk]

Re: глюкодром

Originally posted by Julik
А пока что придется все потенциально русские атрибуты в промежуточном XML сливать в дочерние элементы. Что есть глупость.

Ага, но пока так и извращаемся

P.S. Но больше всего меня в этом радует что то, что мы сейчас обсуждаем я пытался спросить в первом сообщении этого топика. Потребовалось всего-лишь страница бесполезных постов, чтоб начать обсуждение по теме...
Вывод: надо учиться правильно задавть вопросы /гммм... вроде же старался придерживаться всех известных мне рекомендаций/

 

[jahson]

В ПХП5 есть глюк с ентитис. Зайди на пхп.нет, глянь список убитых багов - причем ентитисы там что-то не могли с утф