Maison > Article > développement back-end > Solutions aux problèmes d'encodage qui surviennent lors du XSLT côté serveur
Solutions aux problèmes d'encodage qui surviennent lors du XSLT côté serveur
- Y2Joriginal
- 2017-04-22 14:50:191992parcourir
Récemment, lors de la discussion de l'optimisation de Weather For Google Earth avec Apple Pi, nous avons utilisé XSLT pour convertir les données XML. Ensuite, un moteur de conversion doit être utilisé ici. Le processus approximatif consiste à transférer à la fois le fichier XML et le fichier XSLT. la mémoire. Le moteur DOM le convertit en HTML souhaité (dans ce cas, je souhaite générer un fichier KML). Ce processus de conversion est divisé en côté client et côté serveur. Étant donné que la conversion côté client nécessite que le navigateur de l'utilisateur prenne entièrement en charge XML, mais que tous les navigateurs des utilisateurs ne le prennent pas actuellement en charge (IE5, IE4, etc.), le serveur est donc utilisé. -la conversion côté est effectuée. Elle est relativement idéale.
Format de fichier XML :
<?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> Format de fichier XSLT (partie du contenu omise) :
<?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> Le code de conversion que j'ai commencé à utiliser est ASP+JavaScirpt :
//========Type de sortie et encodage du flux========================== =
Response.ContentType = "application/vnd.google-earth.kml+xml";
Response.CharSet = "UTF-8" ;//=====Récupérer et charger le fichier XML distant======================== = ==
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);//======Charger le fichier XSL======================== = =
var xsl = Server.CreateObject("Microsoft.XMLDOM");
xsl.async = false;
xsl.load(Server.MapPath("gew.xsl"));//======Conversion de fichier====================
Réponse Écrire ( oXD.transformNode(xsl));
Il va de soi qu'il ne devrait pas y avoir de problème d'encodage, car l'encodage est déclaré partout. Mais quelque chose s'est mal passé. L'instruction d'ouverture du fichier KML de sortie est toujours
<?xml version="1.0" encoding="UTF-16"?>
. Grâce aux tests, il a été constaté qu'il n'y avait aucun problème avec les deux fichiers sources XML et XSLT. Le problème réside dans la conversion. moteur dans le code ASP, et plus tard dans le RE : [xsl] Problème avec le chinois (Solution) Cet article a trouvé à peu près la raison. Il dit que le moteur transformNode génère une chaîne, et sur la plate-forme win32, il utilise toujours UTF-16. pour traiter les chaînes, puis si nous utilisons cette chaîne pour générer un fichier KML, le résultat ne peut être qu'UTF-16.
La solution est d'utiliser le moteur transformNodeToObject. La partie conversion de fichier est remplacée par oXD.transformNodeToObject(xsl, Response). La différence entre ces deux méthodes est que la première génère une variable de chaîne et la seconde enregistre directement les données XML converties sur le nœud spécifié.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!