incorrect utf8 characters in report.rxlog.data

Ask general questions here.
floolf
Posts: 12
Joined: Thu Nov 19, 2015 1:49 pm

incorrect utf8 characters in report.rxlog.data

Post by floolf » Thu Nov 19, 2015 3:35 pm

Hello,
I am using Ranorex 5.4.4.26486 - On Windows

I have some problems with non UTF8 characters in report.html.data :

. Ranorex report does not display when I log a string containins "&" : the following message appears vers I try to open the report in Ranorex Studio

Data file (Spot_RT_2011119_135915.rxlog.data ) or transformation file is missing

After investigation, I found that the Spot_RT_2011119_135915.rxlog.data exists, but contains a non encoded "&" in step parameters message

<message>
<table cellpadding='2' align='left' width='80%'><tr BGCOLOR='#EFECCA'><td colspan='2'>Methode : <b>LoginSpot</b></td></tr><tr BGCOLOR='#FCFAE1'><td>MODE</td><td></td></tr><tr BGCOLOR='#FCFAE1'><td>USECASE</td><td></td></tr><tr BGCOLOR='#FCFAE1'><td>Environnement</td><td>PREPROD</td></tr><tr BGCOLOR='#FCFAE1'><td>Browser</td><td>CHROME</td></tr><tr BGCOLOR='#FCFAE1'><td>Username</td><td>fxxx</td></tr><tr BGCOLOR='#FCFAE1'><td>Password</td><td>xxx&Szz</td></tr></table>
</message>

If I suppress this character in report.*.data, the report displays correctly.
What is odd is that some characters are encoded :

<message>
DEBUT : Chargement donn&#233;es r&#233;f&#233;rences
</message>


. I am trying to use Jenkins to launch my tests, and I tried to configure the XSLT transformation plugin ( with ranorex-to-xunit.xsl template ) to enable Jenkins to register my tests details. On one of the slave executing Ranorex, my Studio/compiler is configured in french, so the execution stack is displaid in French, containing "à" whenever the english translation contains "at".
This fired an exception in the plugin (
Caused by: com.sun.org.apache.xerces.internal.impl.io.MalformedByteSequenceException: Octet 2 de la séquence UTF-8 à 3 octets non valide.
)
Sorry I don't have the full stack anymore.
As a workaround, I make some substitutions in report.*.data by script in my build step. But then I have had a problem

... 16 more
Caused by: net.sf.saxon.s9api.SaxonApiException: Failed to compile stylesheet. 1 error detected.
at net.sf.saxon.s9api.XsltCompiler.compile(XsltCompiler.java:149)
at org.jenkinsci.lib.dtkit.util.converter.ConversionService.convert(ConversionService.java:324)
... 22 more
Caused by: javax.xml.transform.TransformerConfigurationException: Failed to compile stylesheet. 1 error detected.
at net.sf.saxon.PreparedStylesheet.prepare(PreparedStylesheet.java:176)
at net.sf.saxon.PreparedStylesheet.compile(PreparedStylesheet.java:79)
at net.sf.saxon.s9api.XsltCompiler.compile(XsltCompiler.java:146)


I tried to process the transformation using msxsl.exe. After suppression of special characters, msxsl.exe is able to process the transformation, and Jenkins can understand the resulting xml file
But now my problem is that the status of my build in Jenkins is the result of the transformation.

. I also have a problem with screenshot images path images_report\ which I have to transform to images_report/ to enable access to screenshots.


I don't master the writing in report.*.data, some , and I did not find any setting to act upon encoding.

How could I ensure proper UTF8 encoding of those characters ? In particular, how can I encode the Execution stack displayed in Ranorex exception ?
How can I investigate why is the report.*.data not compilable by the plugin ?

Thanks for your answer

User avatar
Support Team
Site Admin
Site Admin
Posts: 12145
Joined: Fri Jul 07, 2006 4:30 pm
Location: Houston, Texas, USA
Contact:

Re: incorrect utf8 characters in report.rxlog.data

Post by Support Team » Tue Nov 24, 2015 9:39 am

Hello floof,

May I ask how you log the message to the report? Which method do you use? We weren’t able to reproduce the issue with the Report.Info()-method

As for your question regarding Jenkins and the XSLT transformation, I’m afraid that we can’t help you in this matter, since this is not directly related to Ranorex itself.

Sincerely,
Robert