You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@jmeter.apache.org by bu...@apache.org on 2017/07/19 15:23:09 UTC

[Bug 61317] New: Since 3.2 exporting aggregate report to .csv no longer supports "non UTF-8"

https://bz.apache.org/bugzilla/show_bug.cgi?id=61317

            Bug ID: 61317
           Summary: Since 3.2 exporting aggregate report to .csv no longer
                    supports "non UTF-8"
           Product: JMeter
           Version: 3.2
          Hardware: PC
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Main
          Assignee: issues@jmeter.apache.org
          Reporter: linard.verstraete@tenforce.com
  Target Milestone: ---

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)
6. Notice that the label has become "Kopiëren"

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).

* 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.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 61317] Since 3.2 exporting aggregate report to .csv no longer supports "non UTF-8"

Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=61317

--- Comment #4 from LinardAtTenForce <li...@tenforce.com> ---
(In reply to Philippe Mouawad from comment #3)
> Thanks for feedback.
> From your answers I see no problem in JMeter.
> In fact it's the opposite, it was broken before 3.2 (UTF-8 data was
> corrupt), it is ok now.
> 
> Closing as WORKSFORME

Maybe I need to rephrase my last paragraph.

Changing the default value of the following property in saveservice.properties

# Character set encoding used to read and write JMeter XML files and CSV
results
_file_encoding=ISO-8859-1

results in a UTF-8 .csv file. Why is that?

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 61317] Since 3.2 exporting aggregate report to .csv no longer supports "non UTF-8"

Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=61317

LinardAtTenForce <li...@tenforce.com> changed:

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

--- Comment #2 from LinardAtTenForce <li...@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.

[Bug 61317] Since 3.2 exporting aggregate report to .csv no longer supports "non UTF-8"

Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=61317

Philippe Mouawad <p....@ubik-ingenierie.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |WORKSFORME
           Hardware|PC                          |All
             Status|NEW                         |RESOLVED

--- Comment #3 from Philippe Mouawad <p....@ubik-ingenierie.com> ---
Thanks for feedback.
From your answers I see no problem in JMeter.
In fact it's the opposite, it was broken before 3.2 (UTF-8 data was corrupt),
it is ok now.

Closing as WORKSFORME

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 61317] Since 3.2 exporting aggregate report to .csv no longer supports "non UTF-8"

Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=61317

Philippe Mouawad <p....@ubik-ingenierie.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |NEEDINFO
                 CC|                            |p.mouawad@ubik-ingenierie.c
                   |                            |om
                 OS|                            |All

--- Comment #1 from Philippe Mouawad <p....@ubik-ingenierie.com> ---
(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


> 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 ?
> 
> 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).
> 
> * 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.