xsl: include терпит неудачу после обновления версии PHP;проблема с версией libxml / libxslt? - PullRequest
Новая
       36

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

0 голосов
/ 03 февраля 2011

Я использую 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=> 2.6.26

5.2.8

libxml Version => 2.6.32
libxslt, скомпилированный с libxml Version => 2.6.32

=== itперерывы в версиях, начиная с 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?
  • что-то еще?

Яозадачен.Любые мысли, которые могут направить меня в правильном направлении, с благодарностью.Спасибо.

1 Ответ

1 голос
/ 26 марта 2011

Это было отправлено как Ошибка PHP # 53965 .

Правильное использование файла : // protocol диктует, что полные пути Windows должны иметь третий подрядкосая черта для обозначения localhost (то есть file: /// C: / path).Мое приложение неправильно использует две косые черты (например, file: // C: / path).Предположительно, синтаксический анализатор просто маркировал URI без полной проверки ошибок, а затем передал рекомбинированную строку процессору XSLT, что привело к появлению «file: / C: / path».

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

  1. добавьте этот третий слеш или
  2. полностью удалите протокол "file: //", так как это просто локальные файлы

Несмотря на то, что мой код был в конечном итоге неверным, моя путаница, таким образом, возникла из-за того, что не было сгенерировано ошибок, которые бы указывали на мой неверный URI, и что исходный файл все равно был успешно загружен.Либо оба файла должны загружаться, либо оба файла не должны загружаться - не один загружает, а другой - нет, как было в случае.

...