Last Comment Bug 144995 - File Save dialog box doesn't show proper Korean char on Sol2.8 ( Kor locale) in Netscape 4.7 and above browsers.
: File Save dialog box doesn't show proper Korean char on Sol2.8 ( Kor locale) ...
Status: VERIFIED WONTFIX
: intl
Product: Core
Classification: Components
Component: Internationalization (show other bugs)
: Trunk
: Sun Solaris
: -- critical (vote)
: ---
Assigned To: Roy Yokoyama
: Yuying Long
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2002-05-16 06:28 PDT by Saumyabrata Bandyopadhyay
Modified: 2002-05-20 09:29 PDT (History)
6 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Saumyabrata Bandyopadhyay 2002-05-16 06:28:32 PDT
Test case :
The jsp file is given below .
<%@ page contentType="application/vnd.ms-excel" %>
<%@ page session="false" %>
<%!        
public static String iso8859(String str) 
{           
        if (str == null)    
        { 
                return  str; 
        }                
        
        try 
        { 
                str = new String(str.getBytes("KSC5601"), "8859_1");             
   
        } 
        catch (Exception e) { System.err.println(e.toString()); }                
        
        return  str; 
}
%>
<%
String fileName ="ÇѱÛ.xls";
response.setHeader("Content-Disposition", "attachment; filename=" + fileName + 
";");
%>
ºÐ±â    1       2       3       4
¼­¿ï    1       3       5       7
´ëÀü    7       8       9       0
´ë±¸    0       0       8       9
ºÎ»ê    9       0       8       6


This is working perfectly fine with Win2K.

WebServer response :
IE on Win2k (Korean locale):
---------------------------

HTTP/1.1 200 OK

Server: Netscape-Enterprise/6.0

Date: Tue, 14 May 2002 09:37:51 GMT

Content-type: application/vnd.ms-excel

Content-disposition: attachment; filename=ÇѱÛ.xls;

Transfer-Encoding: chunked

b9

ºÐ±â    1       2       3       4

¼­¿ï    1       3       5       7

´ëÀü    7       8       9       0

´ë±¸    0       0       8       9

ºÎ»ê    9       0       8       6


0

Netscape6.2.2 on Solaris(Korean)
-----------------------------------

HTTP/1.1 200 OK

Server: Netscape-Enterprise/6.0

Date: Tue, 14 May 2002 09:43:42 GMT

Content-type: application/vnd.ms-excel

Content-disposition: attachment; filename=ÇѱÛ.xls;

Connection: close


ºÐ±â    1       2       3       4

¼­¿ï    1       3       5       7

´ëÀü    7       8       9       0

´ë±¸    0       0       8       9

ºÎ»ê    9       0       8       6



Netscape4.76 on Win2k(Korean)
---------------------------------

HTTP/1.1 200 OK

Server: Netscape-Enterprise/6.0

Date: Tue, 14 May 2002 09:47:30 GMT

Content-type: application/vnd.ms-excel

Content-disposition: attachment; filename=ÇѱÛ.xls;

Connection: close



ºÐ±â    1       2       3       4

¼­¿ï    1       3       5       7

´ëÀü    7       8       9       0

´ë±¸    0       0       8       9

ºÎ»ê    9       0       8       6
Comment 1 Matthias Versen [:Matti] 2002-05-16 11:40:02 PDT
What do you mean with "Netscape 4.7 and above browsers." ?
This is a mozilla bug database. Do you see this with Mozilla RC2 or later ?
Comment 2 Saumyabrata Bandyopadhyay 2002-05-16 22:49:15 PDT
This bug is reproducible in Netscape6.2.2. It seems that is the snapshot of 
Mozilla. 
Anyway I filed a bug against netscape 6.x , but it doesn't give me any bug id to 
track .
Comment 3 Matthias Versen [:Matti] 2002-05-17 04:09:47 PDT
Ns6.2.2 is old (based on Mozilla0.9.4) 

-> Int for a look
Comment 4 Yuying Long 2002-05-17 18:19:40 PDT
cc some experts: Katakai for Sun, Junkshik Shin for Korean.

Could any of you please help confirm this? thanks!
Comment 5 Jungshik Shin 2002-05-17 21:36:30 PDT
It's not allowed to use non-US-ASCII character in filename
parameter of Content-Disposition field. What you're transmitting
is violating the MIME standard. You should properly encode
filename parameter in non-US-ASCII according to RFC 2231.
(http://www.faqs.org/rfcs/rfc2231.html)

IMHO,  MS IE is overly generous in this respect. 

I believe Mozilla (RC2) is able to handle RFC 2231-encoded 
filename parameters of Content-Disposition header fields.

In light of this, I think this should be marked as "won't fix". 


Comment 6 Jungshik Shin 2002-05-17 21:45:20 PDT
  The properly encoded http header should look like the following

Content-disposition: attachment; 
   filename*=euc-kr'%C7%D1%B1%DB.xls

or

Content-dispositon: attachment;
    filename*=UTF-8'%ED%95%9C%EA%B8%80.xls



Comment 7 Saumyabrata Bandyopadhyay 2002-05-19 05:38:58 PDT
Then how come it is working with netscape 4.7x on Win2K.
Comment 8 Jungshik Shin 2002-05-19 09:19:32 PDT
That does NOT mean  that what you're doing is compliant to
MIME/HTTP standard. That does ONLY mean that NS 4.7x was just as lazy
(or overindulgent) as MS IE in not properly checking the value of the
filename parameter(and  condoning your and many others' mistakes).  As you
should be able to see by reading RFC's, using non-US-ASCII chars. in
filename parameter is not allowed.  You should NOT rely on browsers'
generousity/overindulgence when writing server-side applications.

  Moreover, what you're doing does NOT work even with MS IE(and
NS 4.7x) unless your clients set their locale to Korean with the
encoding set to EUC-KR or CP949. I don't use ko_KR.EUC-KR any more,
but use ko_KR.UTF-8 locale. Even if Mozilla is modified to behave as
you requested, it would not work for me, let alone many
other users who use non-Korean locales.

  If you make your server-side application compliant to MIME/HTTP
standard, it would work regardless of what locale your clients
use as long as they use multilinugal OS' like Win2k and Unix(-like)
OS under UTF-8 locale. (of course, it would also work under Korean
locale with the encoding set to EUC-KR or CP949.)
Comment 9 Yuying Long 2002-05-20 09:27:44 PDT
Mark as won't fix according to Junk-Shik Shin's comments.

Please re-open if disagree.
Comment 10 Yuying Long 2002-05-20 09:29:21 PDT
Verified.

Note You need to log in before you can comment on or make changes to this bug.