php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #36244 Importing xsl:output breaks encoding attribute value
Submitted: 2006-02-01 11:14 UTC Modified: 2006-02-02 21:43 UTC
From: maximgb at is-a dot ru Assigned: chregu (profile)
Status: Not a bug Package: XSLT related
PHP Version: 5.1.2 OS: windows xp sp2
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: maximgb at is-a dot ru
New email:
PHP Version: OS:

 

 [2006-02-01 11:14 UTC] maximgb at is-a dot ru 
Description:
------------
I have two stylesheets first one with xsl:output tag only, where method="XML" and encoding="windows-1251", second one which imports the first one and where all other templates are stored. When I use <xsl:import href='first.xsl' /> then all russian characters after transformation become XML entities, when I use <xsl:include href="first.xsl' /> then everything is ok.

All XML files involved in transformation has following xml declaration
<?xml version="1.0" encoding="windows-1251"?>

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2006-02-01 11:16 UTC] tony2001@php.net 
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with <?php and ends with ?>,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc.

If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.
 [2006-02-01 21:51 UTC] maximgb at is-a dot ru 
bug.php
-------
<?php
$source = new DOMDocument();
$source->load("bugsrc.xml");
$transform = new DOMDocument();
$transform->load('bug2.xsl');
$xslt = new XSLTProcessor();
$xslt->importStyleSheet($transform);
file_put_contents("bugdest.xml", $xslt->transformToXML($source));
?>

bugsrc.xml
----------
<?xml version="1.0" encoding="windows-1251"?>
<bug/>

bug1.xsl
--------
<?xml version="1.0" encoding="windows-1251"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
    <xsl:output 
        method="xml"
        encoding="windows-1251" 
        indent="yes"
        omit-xml-declaration="no"
    />
</xsl:stylesheet>

bug2.xsl
--------
<?xml version="1.0" encoding="windows-1251"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

    <xsl:import href="bug1.xsl"/>
    <!--<xsl:import href="bug1.xsl"/>-->

    <xsl:template match="bug">
     <bug message="&#1042;&#1086;&#1090; &#1090;&#1091;&#1090; &#1085;&#1077; &#1076;&#1086;&#1083;&#1078;&#1085;&#1086; &#1073;&#1099;&#1090;&#1100; XML &#1089;&#1091;&#1097;&#1085;&#1086;&#1089;&#1090;&#1077;&#1081;" />
    </xsl:template>

</xsl:stylesheet>
 [2006-02-01 21:58 UTC] maximgb at is-a dot ru 
In the bug2.xsl in bug message attribute should be some text in windows-1251 encoding. In previous comment it was encoded by bug tracker posting system.
 [2006-02-02 12:20 UTC] tony2001@php.net 
Christian, is this some kind of libxml weirdness or ..?
 [2006-02-02 21:43 UTC] chregu@php.net 
Put 
     
<xsl:output 
        method="xml"
        encoding="windows-1251" 
        indent="yes"
        omit-xml-declaration="no"
    />

into bug2.xsl and it works. Besides from that, the output 
produced is correct, even 'though not really human readable 
(but if you open it up in Firefox, it shows the characters 
just fine)

xsltproc has the same behaviour, so if you think this is a 
bug, you have to complain to the libxslt guys (i'm too lazy 
to look up the specs right now)
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Wed Apr 24 17:01:30 2024 UTC