#14499 [Com]: encoding with XSLT problem

ID: 14499 Comment by: jacob at pineberry dot com dot au Reported By: douglasd at iprimus dot com dot au Status: Closed Bug Type: Documentation problem Operating System: windows 2000 PHP Version: 4.1.0 New Comment: After having lots and lots of problems with "encoding" error messages from Sablotron in PHP 4.2.3, in total desperation I looked back at my XSLT and XML files and started playing with them again. What I found out is as follows: Sablotron in PHP 4.2.X looks at the <?xml version="1.0" ... ?> statement and if the statement contains any arguments, e.g. standalone="no", it always assumes that the argument is "encoding=...", which is obviously a bug. So to make your PHP 4.2.X working with XSLT, make sure that your XML and XSLT files do not rely on the DTDs as you'd have to drop the DOCTYPE statements as well (which need the "standalone" statement in the XML declaration). This means that all your XML files need to be validated outside the Sablotron - but this will save you hours of work investigating silly errors of the type "unknown encoding='no'" (or something similar depending on what arguments you have included in your XML header). This problem has now been fixed in PHP 4.3.X (at least in X >= 1). Jacob Previous Comments: ------------------------------------------------------------------------ [2003-01-05 11:55:31] derick@php.net This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. ------------------------------------------------------------------------ [2003-01-05 11:19:20] axel_kollmorgen at hotmail dot com this (not having xslt_set_encoding() available on windows because of HAVE_SABLOT_SET_ENCODING not defined in xslt.dsp) finally got fixed - see http://bugs.php.net/bug.php?id=20640 / http://cvs.php.net/cvs.php/php4/ext/xslt/xslt.dsp#rev1.3 . i had almost lost hope ... nice. ------------------------------------------------------------------------ [2002-06-27 09:41:17] ax at condat dot de please note: the php_xslt.dll mentioned in my previous post only works with php-4.1.2 (or was it 4.1.1?) and the mentioned sablotron binaries (sablot.dll etc) replacing the default ones! @ tim@zero-interactive.com: if you want xslt_set_encoding() to work on a php windows version of your choice, you have to get the mentioned sablotron binaries and recompile the php_xslt.dll with HAVE_SABLOT_SET_ENCODING set. get the php sources, open php4\ext\xslt\xslt.dsw, add "HAVE_SABLOT_SET_ENCODING" to project options > c/c++ > preprocessor definitions, and go. @ k.schroeder@php.net: i dont think this is the same as #14965: that one is about files not found, this one here is about HAVE_SABLOT_SET_ENCODING not compiled into the dll. @ the php developers / windows binaries packager: again - i would highly recommend to include the appropriate changes (sablotron dll's with encoding support; HAVE_SABLOT_SET_ENCODING defined) into the next windows binary release. this error is really frustrating for windows users because most of them dont have the possibility to recompile php. ------------------------------------------------------------------------ [2002-06-02 16:04:35] k.schroeder@php.net Same problem as #14965. Regards, Kai ------------------------------------------------------------------------ [2002-05-02 00:19:42] tim at zero-interactive dot com Same problem occurs with PHP 4.2.0 on Win2K. Updating with the proposed dll by ax@condat.de doesn't fix it either. Neither does setting the encoding in the xml and/or the xslt file. Sorry Sterling, but I'd say it definitely is a bug ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/14499 -- Edit this bug report at http://bugs.php.net/?id=14499&edit=1