xsl: include не работает после обновления версии PHP; Версия libxml / libxslt не соответствует проблеме?

Я использую Windows XP с предварительно скомпилированными двоичными файлами PHP, доступными на windows.php.net. Я обновился с PHP 5.2.5 до PHP 5.2.16, и теперь xsl:include в некоторых моих таблицах стилей перестали работать. Последовательно тестируя каждую версию, я обнаружил, что она работала до 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 Version = ›2.6.26
libxslt скомпилирован с libxml Version =› 2.6.26

5.2.8

libxml Version = ›2.6.32
libxslt скомпилирован против libxml Version =› 2.6.32

=== он не работает в версиях, начиная с 5.2.9 ===
5.2.9
libxml Version = ›2.7.3
libxslt скомпилирован с libxml Version =› 2.6.32

5.2.16
libxml Version = ›2.7.7
libxslt скомпилирован против libxml Version =› 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