jmeter-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject [Bug 61317] Since 3.2 exporting aggregate report to .csv no longer supports "non UTF-8"
Date Mon, 24 Jul 2017 08:49:36 GMT
https://bz.apache.org/bugzilla/show_bug.cgi?id=61317

LinardAtTenForce <linard.verstraete@tenforce.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEEDINFO                    |NEW

--- Comment #2 from LinardAtTenForce <linard.verstraete@tenforce.com> ---
(In reply to Philippe Mouawad from comment #1)
> (In reply to LinardAtTenForce from comment #0)
> > Step to reproduce:
> > 1. Create a .jmx file with a request containing a typical ISO-8859-1
> > character, for example "Kopiëren" (Dutch for 'to copy')
> > 2. Run the JMeter test to produce a .jtl file
> > 3. Open the .jtl in an Aggregate Report listener.
> > 4. Export the table to .csv
> > 5. Open the .csv file in a spreadsheet editor (e.g. Excel)
> 
> How do you do that ? Are you sure you respect encoding of file ?
> https://stackoverflow.com/questions/6002256/is-it-possible-to-force-excel-
> recognize-utf-8-csv-files-automatically

I have Excel as default application for .csv files. I open the file by double
clicking it.

> > 6. Notice that the label has become "Kopiëren"
> Are you sure it's not the way you open it in excel that is broken ?

Based on the stackoverflow post you provided, I can confirm that opening Excel
and importing the .csv file (with specify the encoding) in separate steps,
results in the expected behavior.

> > 
> > Expected:
> > 6. The label remains "Kopiëren" and is readable.
> > 
> > This scenario works in version 2.13, 3.0 and 3.1, but broke in 3.2.
> > 
> > I expect that the scenario broke since this commit:
> > 24e22e433 ("sonar: fix errors and false-positive Fix missing Encoding issue
> > by saving in UTF-8", 2016-12-28)
> > git-svn-id: https://svn.apache.org/repos/asf/jmeter/trunk@1776330
> > 13f79535-47bb-0310-9956-ffa450edef68
> > 
> > It seems that the bug is still present on trunk:
> > https://svn.apache.org/viewvc/jmeter/trunk/src/components/org/apache/jmeter/
> > visualizers/StatVisualizer.java?view=markup#l220
> > 
> > I don't know the project well enough to define the best solution. But if it
> > helps, these are 3 alternative approaches to resolve the issue:
> > 
> > * Revert line that introduced the hardcoding of UTF-8 character set.
> > 
> > * Replace it by using the existing property "_file_encoding" specified in
> > "saveservice.properties" (According to the documentation: Character set
> > encoding used to read and write JMeter XML files and CSV results)
> > By default it is set to "_file_encoding=UTF-8", but can be configured to be
> > "_file_encoding=ISO-8859-1"
> > This property is already used for reading/writing to .jmx and .jtl file
> > (Steps 1-3) but not in reading/writing this .csv (Step 4).

I do understand that the program (e.g. Excel) that reads the .csv needs to use
the right encoding, but coming from previous JMeter versions, it feels tedious
to do these extra steps. I'm still confused that the .csv can't be written in
something else than UTF-8, even when setting the saveservice.properties.

> > * Provide the Byte Order Mark when writing in UTF-8, so that other program
> > that consumes the .csv file can be sure that the text stream is in Unicode.
> 
> I tested your scenario, it works fine for me with LibreOffice.
> I don't have Excel.

-- 
You are receiving this mail because:
You are the assignee for the bug.
Mime
View raw message