xsl:include се проваля след надграждане на PHP версията; дали версията на libxml/libxslt не съответства на проблема?

Работя с Windows XP с предварително компилирани PHP двоични файлове, налични от windows.php.net. Надстроих от PHP 5.2.5 до PHP 5.2.16 и сега xsl:includes в някои от моите таблици със стилове спряха да работят. Тествайки всяка версия последователно, открих, че работи до 5.2.8 и не работи в 5.2.9+. Сега получавам следните три грешки за всеки xsl:include.

Warning: XSLTProcessor::importStylesheet() [xsltprocessor.importstylesheet]: I/O warning : failed to load external entity "file%3A/C%3A/path/to/included/stylesheet.xsl" in ... on line 227

Warning: XSLTProcessor::importStylesheet() [xsltprocessor.importstylesheet]: compilation error: file file%3A//C%3A/path/to/included/stylesheet.xsl line 36 element include in ... on line 227

Warning: XSLTProcessor::importStylesheet() [xsltprocessor.importstylesheet]: xsl:include : unable to load file%3A/C%3A/path/to/included/stylesheet.xsl in ... on line 227

Предполагам, че това е така, защото не може да намери посочения файл. Много от включванията са в същата директория като таблицата със стилове, която се трансформира, и нямат директория в пътя, т.е. <xsl:include href="fileInSameDir.xsl">. Интересното е, че при първата и третата грешка той показва протокола file:// само с една наклонена черта вместо правилните две. Предполагам, че това е проблемът. (Когато твърдо кодирам пълен път с помощта на file:/ той се проваля, но когато кодирам твърдо пълен път с file://, той работи.) Но какво може да причини това? Грешка в libxslt/libxml? Също така открих очевидно несъответствие на версията между libxml и версията на libxml, срещу която е компилиран libxslt.

5.2.5
libxml Версия =› 2.6.26
libxslt компилиран срещу libxml Версия =› 2.6.26

5.2.8

libxml версия =› 2.6.32
libxslt компилиран срещу libxml версия =› 2.6.32

=== прекъсва се във версии, започващи от 5.2.9 ===
5.2.9
libxml Версия =› 2.7.3
libxslt компилиран срещу libxml Версия =› 2.6.32

5.2.16
libxml версия =› 2.7.7
libxslt компилиран срещу libxml версия =› 2.6.32

До PHP 5.2.9 libxslt беше компилиран срещу същата версия на libxml, която беше включена в PHP. Но започвайки с PHP 5.2.9, libxslt беше компилиран срещу по-стара версия на libxml от тази, която беше включена в PHP. Това проблем с разпределените двоични файлове ли е или просто съвпадение?

За да тествам това, предполагам, че PHP може да бъде изграден с различни версии на libxml/libxslt, за да се види кои комбинации работят или не. За съжаление, аз съм извън моята стихия в света на Windows и изграждането на PHP на Windows ми се струва излишно.

За съжаление, досега не успях да възпроизведа този проблем с пример извън моето приложение, така че се боря да го стесня и не мога да изпратя конкретна грешка.

И така, смятате ли, че е причинено от

  • проблем с несъответствие на версията в разпределените двоични файлове?
  • грешка, въведена в PHP 5.2.9?
  • грешка, въведена в libxml 2.7?
  • нещо друго?

Смаян съм. Всички мисли, които биха могли да ме насочат в правилната посока, са високо оценени. Благодаря.


php libxml2 libxslt
person Wiseguy    schedule 02.02.2011    source източник

Отговори (1)


arrow_upward
1
arrow_downward

Това е изпратено като PHP грешка #53965.

Правилното използване на протокола file:// диктува, че пълните пътища на Windows трябва да имат трета поредна наклонена черта предполагат localhost (т.е. file:///C:/path). Моето приложение неправилно използва две наклонени черти (т.е. file://C:/path). Предполага се, че анализаторът просто е токенизирал URI без пълна проверка за грешки и след това е предал рекомбинирания низ към XSLT процесора, което е довело до появата на "file:/C:/path".

Два варианта за решаване на моя проблем:

  1. добавете тази трета наклонена черта, или
  2. премахнете изцяло протокола "file://", тъй като те са само локални файлове

Въпреки че кодът ми в крайна сметка беше неправилен, объркването ми по този начин произтичаше от факта, че не бяха генерирани грешки, които отбелязваха моя невалиден URI и че първоначалният файл така или иначе се зареди успешно. Или и двата файла трябва да се зареждат, или и двата файла не трябва да се зареждат -- нито единият се зарежда, нито единият не, както беше в случая.

person Wiseguy    schedule 26.03.2011