Uploaded test case that shows this issue.

Steps:

• Load welcomeICEfaces.jsf
• Export the content of the table and save the file some where.
• Open the csv file with an editor, Notepad++ for example. Looking at the encoding it is set to UTF-8 not ANSI

r48575: added support for the encoding attribute in ace:dataExporter for the CSV and XML formats.

Testing notes, documentation and other notes to follow.

r48583: added 'pdfFont' attribute to specify a custom font for the exported PDF file and added TLD documentation regarding encoding

Testing notes:

• Please read the new TLD documentation for the 'encoding' and 'pdfFont' attributes.
• Test the CSV, XML, and PDF formats separately (The XLS format is not affected by these changes).
• The test app needs to be modified and tested as explained below. Simply checking the Encoding menu in Notepad++ is not a reliable way to determine the encoding, since Notepad++ simply gives its best guess as to the encoding in use. There's nothing in plain text files to inform the readers/viewers what encoding is being used.
• Modify the test app by including some Unicode characters either in the XHTML file or hardcoded in the Java bean. The characters in the Java bean must be escaped, using the Java format (i.e. \u0000) in order for them to be displayed and exported correctly. The only Unicode character in the attached test app is not escaped, so it won't be displayed correctly, unless it's escaped. In the XHTML file, Unicode characters must be escaped in the XML format (i.e. &#x0000; ), unless the encoding is explicitly declared in the xml prolog (e.g. <?xml version='1.0' encoding='UTF-8' ?> ), in which case Unicode characters can be typed directly.
• For example, you can use these escaped characters in Java '\u0407 \u03fe \u0401' and these escaped characters in XHTML '&#x0407; &#x03FE; &#x0401;'.
• You can test the plain text formats (CSV and XML) by specifying the UTF-8 encoding (or simply not including the 'encoding' attribute, since UTF-8 is the default encoding) and verifying that Unicode characters can be viewed correctly in a text editor. Then, you can change the encoding to 'US-ASCII' or 'Windows-1252' and see that Unicode characters are replaced by question marks. The 'ANSI' value is not an official encoding type.
• You can test the PDF format by specifying the absolute path to a font file in the host system, using the 'pdfFont' attribute. I recommend using the most common TrueType fonts like Arial, Helvetica, Times New Roman, etc., since the font itself has to support the desired encoding in order to be used, and popular fonts usually support Unicode (Courier and other terminal/console fonts might not support Unicode completely or at all). Once the PDF document is exported, verify that Unicode characters are displayed correctly (if 'UTF-8' was the specified encoding) and that specified font was actually used in the document.
• More information will be added to the wiki page.

r48585: committed improvements to the 3.3 EE maintenance branch

ICEfaces4 trunk r48585: verified on Firefox41, IE11, Chrome49, MS Edge, no issues found.
Added QA dataExporter 'enconding' and 'pdfFont' test: http://dev.icesoft.com/svn/repo/qa/trunk/Regression-Icefaces4/Sparkle/Nightly/dataExporter
Test page: /dataExporterEncoding.jsf