Home > Article > Backend Development > Solutions to encoding issues that arise during server-side XSLT
Solutions to encoding issues that arise during server-side XSLT
- Y2JOriginal
- 2017-04-22 14:50:191992browse
Recently, when discussing the optimization of Weather For Google Earth with Apple Pi, we used XSLT to convert XML data. Then a conversion engine must be used here. The approximate process is to transfer both XML files and XSLT files into memory for use. The DOM engine converts it to the HTML we want (in this case, I want to generate a KML file). This conversion process is divided into client-side and server-side. Because the client-side conversion requires the user's browser to fully support XML, but not all users' browsers currently support it (IE5, IE4, etc.), so the server-side conversion is performed. It is relatively ideal.
XML file format:
<?xml version="1.0" encoding="UTF-8"?>
<weather ver="2.0">
<head>[...]
</head>
<loc id="CHXX0101">[...]
</loc>
<cc>[...]
</cc>
<dayf>
<lsup>10/28/06 11:16 AM Local Time</lsup>
<day d="0" t="Saturday" dt="Oct 28">[...]
</day>
<day d="1" t="Sunday" dt="Oct 29">[...]
</day>
</dayf>
</weather> XSLT file format (content part omitted):
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="xml" version="1.0" encoding="UTF-8" indent="yes"/>
<xsl:template match="/">[...]
</xsl:stylesheet> The conversion code I started using is ASP+JavaScirpt:
//========Output type and stream encoding==========================
Response.ContentType = "application/vnd.google-earth.kml+xml";
Response.CharSet = "UTF-8" ;//======Get and load the remote XML file==========================
var oXHy = Server.CreateObject("MSXML2.XMLHTTP");
var url = http://www.dnxh.cn/ge/CHXX0101.xml;
oXHy.open("GET",url,false);
oXHy.send();
var oXD = Server.CreateObject("MSXML2.DOMDocument");
oXD.loadXML(oXHy.responseText);//======Load XSL file============================
var xsl = Server.CreateObject("Microsoft.XMLDOM");
xsl.async = false;
xsl.load(Server.MapPath("gew.xsl"));//======File conversion====================
Response.Write(oXD.transformNode(xsl));
It stands to reason that there should be no encoding problem, because the encoding is declared everywhere. But something went wrong. The opening statement of the output KML file is always
<?xml version="1.0" encoding="UTF-16"?>
. Through testing, it was found that there is no problem with the two source files of XML and XSLT. The problem lies in the conversion engine in the ASP code. Later, in RE: [ xsl] Problem with Chinese (Solution) This article roughly found the reason. It says that the engine transformNode generates a string, and on the win32 platform, UTF-16 is always used to process strings. Then we will Use this string to generate a KML file, and the result can only be UTF-16.
The solution is to use the transformNodeToObject engine. The file conversion part is replaced with oXD.transformNodeToObject(xsl, Response). The difference between these two methods is that the former generates a string variable, and the latter directly saves the converted XML data to the specified node.
The above is the detailed content of Solutions to encoding issues that arise during server-side XSLT. For more information, please follow other related articles on the PHP Chinese website!