Closed
Bug 830153
Opened 12 years ago
Closed 12 years ago
response.setHeader( "Content-Disposition" "attachment;filename="+ java.net.URLEncoder.encode(filename,"UTF-8") ); shows incorrect header in Japanese platform
Categories
(Core Graveyard :: File Handling, defect)
Core Graveyard
File Handling
Tracking
(Not tracked)
RESOLVED
INVALID
People
(Reporter: nilesh_deshpande, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(1 file, 1 obsolete file)
|
(deleted),
image/gif
|
Details |
Problem with japanese
This code segment in JSP file is not showing the Japanese character in the header and hence the name of the saved file is not coming right. This works good in IE and Chrome. Issue is only with Mozialla. I used 17.0 and 18.0 both. Both has issue
response.setContentType( "application/octet-stream" );
response.setHeader( "Content-Disposition",
"attachment;filename=\""+ java.net.URLEncoder.encode(filename,"UTF-8") + "\"");
response.setBufferSize( bytes.length );
response.setContentLength( bytes.length );
<!DOCTYPE HTML>
<html>
<head>
<meta charset="UTF-8">
<title>JSP Test</title>
<%@ page import="java.util.Locale" %>
<%@ taglib uri="http://java.sun.com/jsp/jstl/fmt" prefix="fmt" %>
<%@ page import="java.util.ResourceBundle" %>
<fmt:setLocale value="ja_JP"/>
<%!
String message = "Hello, World.";
%>
</head>
<body>
<h2><%= message%></h2>
<%= new java.util.Date() %>
<%
//http://localhost:9080/examples/jsp/exportfile.jsp
String data="contents";
//ResourceBundle labels = ResourceBundle.getBundle("LabelsBundle", Locale.getDefault());
//ResourceBundle labels = ResourceBundle.getBundle("LabelsBundle", Locale.JAPANESE);
ResourceBundle labels = ResourceBundle.getBundle("LabelsBundle", Locale.JAPAN);
//Enumeration bundleKeys = labels.getKeys();
String value="";
value = labels.getString("city");
String filename=value+"_test.csv";
response.setCharacterEncoding("UTF-8");
out.println("<br>"+filename);
out.println("<br>"+java.net.URLEncoder.encode(filename,"UTF-8"));
/*English*/
/*
ResourceBundle labels2 = ResourceBundle.getBundle("LabelsBundle", Locale.ENGLISH);
//Enumeration bundleKeys2 = labels.getKeys();
String value2="";
value2 = labels2.getString("city");
String filename2=value2+"_test.csv";
response.setCharacterEncoding("UTF-8");
out.println("<br>"+filename2);
out.println("<br>"+java.net.URLEncoder.encode(filename2,"UTF-8"));
*/
/*Moziall
Sun Jan 13 23:54:58 GMT+05:30 2013
JPWords_test.csv
%E6%9C%89%E5%84%9F%E4%BD%BF%E7%94%A8_test.csv
PuneEnglish_test.csv
PuneEnglish_test.csv
IE
Hello, World.
Sun Jan 13 23:56:24 GMT+05:30 2013
JP_test.csv
%E6%9C%89%E5%84%9F%E4%BD%BF%E7%94%A8_test.csv
PuneEnglish_test.csv
PuneEnglish_test.csv
*/
try
{
byte[] bytes = data.getBytes( "UTF-8" );
// Assert.assertNotNull( bytes );
filename = filename.replace( '/', '-' );
filename = filename.replace( ':', '-' );
response.setContentType( "application/octet-stream" );
response.setHeader( "Content-Disposition",
"attachment;filename=\""+ java.net.URLEncoder.encode(filename,"UTF-8") + "\"");
response.setBufferSize( bytes.length );
response.setContentLength( bytes.length );
// response.getOutputStream().write( bytes );
/*
byte[] bytes = data.getBytes( "US-ASCII" );
// Assert.assertNotNull( bytes );
filename = filename.replace( '/', '-' );
filename = filename.replace( ':', '-' );
// response.setContentType( "application/octet-stream" );
response.setContentType( "application/csv" );
response.setHeader( "Content-Disposition",
"attachment;filename="+ java.net.URLEncoder.encode(filename,"UTF-8") );
response.setBufferSize( bytes.length );
response.setContentLength( bytes.length );
*/
/*
byte[] bytes = data.getBytes( encoding );
Assert.assertNotNull( bytes );
filename = filename.replace( '/', '-' );
filename = filename.replace( ':', '-' );
response.setContentType( "application/octet-stream" );
response.setHeader( "Content-Disposition",
"attachment;filename=\""+ java.net.URLEncoder.encode(filename,"UTF-8") + "\"");
response.setBufferSize( bytes.length );
response.setContentLength( bytes.length );
// response.getOutputStream().write( bytes );
*/
}
catch( Exception ex )
{
throw new ServletException( ex );
}
%>
</body>
</html>
|
||
Comment 1•12 years ago
|
||
We are here at the browser site and we don't know anything about server scripting language.
Please provide a testcase or the http headers that lead to a wrong filename.
|
Reporter | |
Comment 2•12 years ago
|
||
Here is the translated HTTP Header looks like from JSP file.
Content-Disposition: attachment; filename=<file name.ext>
Content-Type: application/octet-stream
(File name is encoded. If you pass the direct JP file name, it does not come at all. When we encode it, it works well on IE but on Mozilla firefox I have garbling)
|
|
||
Comment 3•12 years ago
|
||
Again, please provide an actual example
|
|
Reporter | |
Comment 4•12 years ago
|
||
Here is equivalent. I do not get the fil download box in here. But I am sure my JSP file generates similar to below. Can you help to work out this example?
When the filename is in JP characters, it does not work.
<html>
<head>
<meta http-equiv="content-type" content="application/octet-stream; charset=UTF-8">
<meta name="content-disposition" content="attachment; filename=openinexcel.csv">
</head>
<body>
Hello
</body>
</html>
|
|
||
Comment 5•12 years ago
|
||
Content-disposition in a meta header is no valid html
https://developer.mozilla.org/en-US/docs/HTML/Element/meta
You want to send the right http headers on the http level.
|
|
Reporter | |
Comment 6•12 years ago
|
||
Hi,
Actually we have tested number of combinations in our code. We can have we-bex for solving this issue. In this I can show you problem directly by executing our code on different browsers. As well as you will get complete background of problem.
|
||
Updated•12 years ago
|
Assignee: nobody → general
Component: General → JavaScript Engine
Product: Firefox → Core
|
||
Comment 7•12 years ago
|
||
This has nothing to do with JS.
Julian, what's the right way to get UTF8 data into a content-disposition filename?
Assignee: general → nobody
Component: JavaScript Engine → File Handling
|
||
Comment 8•12 years ago
|
||
The behavior of IE and Chrome is a bug; see <http://greenbytes.de/tech/tc2231/#attwithfnrawpctenca>.
The correct encoding is defined in RFC 6266; see examples in <http://greenbytes.de/tech/webdav/rfc6266.html#examples> and <http://greenbytes.de/tech/tc2231/#attwithfn2231utf8>.
See also <http://greenbytes.de/tech/webdav/rfc6266.html#advice.generating> if compatibility with IE <= 8 and/or Safari < 6 is an issue.
|
|
||
Updated•12 years ago
|
OS: Windows XP → All
Hardware: x86 → All
|
|
||
Updated•12 years ago
|
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → INVALID
|
|
Reporter | |
Comment 9•12 years ago
|
||
Japanese_problem
Attachment #701612 -
Attachment is obsolete: true
|
|
Reporter | |
Comment 10•12 years ago
|
||
So according to you UTF-8 encoded characters should not be decoded while displaying in dialog box(As Mozilla Firefox is doing in this scenario). Whereas IE and Chrome are displaying Japanese header properly by decoding and it is wrong?
If Mozilla Firefox is correct which encoding format should I use for it?
Is it expected behavior to have garbage/unicode characters on dialog box as shown in attachment as above (in description)?
|
|
Reporter | |
Updated•12 years ago
|
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
|
|
||
Comment 11•12 years ago
|
||
(In reply to Nilesh Deshpande from comment #10)
> So according to you UTF-8 encoded characters should not be decoded while
> displaying in dialog box(As Mozilla Firefox is doing in this scenario).
> Whereas IE and Chrome are displaying Japanese header properly by decoding
> and it is wrong?
What's wrong is applying percent-decoding to the filename. There is no such thing in the Content-Disposition spec, and IE and Chrome are the only browsers with this bug.
> If Mozilla Firefox is correct which encoding format should I use for it?
> Is it expected behavior to have garbage/unicode characters on dialog box as
> shown in attachment as above (in description)?
See Comment 8 (https://bugzilla.mozilla.org/show_bug.cgi?id=830153#c8)
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago → 12 years ago
Resolution: --- → WONTFIX
|
|
Reporter | |
Comment 12•12 years ago
|
||
>>>What's wrong is applying percent-decoding to the filename. There is no such thing in the Content-Disposition spec, and IE and Chrome are the only browsers with this bug.
Nilesh: What happens is when the download box opens, the title of the box does not show the valid multi byte name. It shows %encodechar%encodechar% like this
Like I asked earlier can you suggest which encoding form shall we use so that the file header shows correct file name for multi byte char
Thanks,
Nilesh
Status: RESOLVED → UNCONFIRMED
Resolution: WONTFIX → ---
|
|
||
Comment 13•12 years ago
|
||
(In reply to Nilesh Deshpande from comment #12)
> >>>What's wrong is applying percent-decoding to the filename. There is no such thing in the Content-Disposition spec, and IE and Chrome are the only browsers with this bug.
> Nilesh: What happens is when the download box opens, the title of the box
> does not show the valid multi byte name. It shows %encodechar%encodechar%
> like this
It shows the value of the filename parameter as sent by the server. It's a server bug to use percent-encoding in a protocol element that does not support it.
> Like I asked earlier can you suggest which encoding form shall we use so
> that the file header shows correct file name for multi byte char
I already answered that twice. See Comment 8.
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago → 12 years ago
Resolution: --- → INVALID
|
Assignee | |
Updated•8 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•