headers
Jungshik Shin | 1 Nov 2003 01:35

Re: Problem in downloading a pdf file having Japanese characters in the name of the file


A. Vine wrote:
> 
> I'm with Steve.  

On what? I don't think he took any position.

> RFC 2231 is so awkward and has so little support (it's
> been around for many years and yet only now have even a few products 
> decided to support it) 

  It's not more awkward than RFC 2047 for simple cases.

Content-Disposition: attachment; filename*=utf-8''abc%b3%80.txt

Content-Disposition: attachment; filename="=?utf-8?q?abc=b3=80.txt?="

It's not its awkwardness but mostly the ignorance that kept it from
being implemented, IMHO.

> that I never recommend using it.

So, what do you recommend? Using 'raw' UTF-8 chars in http header is 
reasonable  but using 'raw' non-ASCII/non-UTF-8 encodings must be avoided.
Permalink | Reply | 4 comments |
headers
souravm | 3 Nov 2003 09:46
Favicon

RE: Problem in downloading a pdf file having Japanese characters in the name of the file


Hi Steve,

Thanks a lot for sharing the information. I'm yet to implement the
approach.

Regards,
Sourav

-----Original Message-----
From: Steve Billings [mailto:billings <at> global360.com]
Sent: Thursday, October 30, 2003 10:53 PM
To: souravm; www-international <at> w3.org
Subject: RE: Problem in downloading a pdf file having Japanese
characters in the name of the file

I wrestled with this problem earlier this year, and unfortunately found
no
good solutions. As far as I can tell (and I hope someone can prove me
wrong), it's a yet-to-be solved problem in the internet infrastructure.
I
was using recent versions of IE and Netscape browsers, and a not-so-new
version of Tomcat (3.something, I think).

The approach that came closest to working was to encode the filename
using
URLEncoder
(http://java.sun.com/j2se/1.4.1/docs/api/java/net/URLEncoder.html) with
UTF-8, and set the Content-Disposition according to RFC 2047 as follows:
String encoded_filename = URLEncoder.encode(filename, "UTF-8");
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Deuter | 3 Nov 2003 13:06

AW: Problem in downloading a pdf file having Japanese characters in the name of the file


Steve is correct.  There does not seem to be any standard for encoding
the "filename" value in the Content-Disposition header.

Martin: is this something the W3C could take up?

As far as I can tell, the standards concerning the Content-Disposition header
omit any mention of how to handle characters outside the ASCII range.  As a
result, servers and user agents and apps have all done their own thing.

We also found the 17 character limit in IE for Japanese characters.  This 
may sound
like a strange limit, but it makes more sense if one realizes that the 
conversion
of Japanese characters to UTF-8 and then %HH encoding causes a 9x expansion.
Still, it seemed to us that this was a bug in IE and Microsoft 
agreed.  Microsoft
issued a patch (Q816868) which has subsequently been superseded by other 
patches
(Q818506).

We also found that different Japanese versions of IE work differently than 
the US English
version.  And also there are differences in IE 5, 5.5, and 6.x.  It seems 
that some
versions of Japanese IE want the filename to be %HH encoded in 
Shift-Jis.  In our experience,
Netscape 7.x works best.  That does not help much, since not too many 
people are using
Netscape.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Richard Ishida | 3 Nov 2003 13:15
Picon
Favicon
Gravatar

FW: Common Locale Data Repository V1.0 Beta Available!


FYI
-----Original Message-----
From: w3c-i18n-ig-request <at> w3.org [mailto:w3c-i18n-ig-request <at> w3.org] On
Behalf Of Helena Shih
Sent: 01 November 2003 01:52
To: w3c-i18n-ig <at> w3.org
Subject: Common Locale Data Repository V1.0 Beta Available!

The OpenI18N WG of the Free Standards Group is pleased to inform you
that

CLDR (Common XML Locale Data Repository) V1.0 Beta snapshot is
available.

The CLDR repository provides application developers a consistent and

uniform resource in managing the locale-sensitive data used for
formatting,

parsing, and analysis. It also includes the comparison charts that

demonstrates the locale data differences on various platforms.

New in this snapshot are initial versions of collation tailoring data.

For details on the data, reporting problems, and information on the LDML
specification, see:

http://oss.software.ibm.com/cvs/icu/~checkout~/locale/CLDR_status.html.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Addison Phillips [wM] | 3 Nov 2003 17:10

RE: Problem in downloading a pdf file having Japanese characters in the name of the file


I think that an Internet-Draft with the IETF (that is, a new RFC) would be a
more likely alternative, since RFCs define the headers and their semantics.

It also seems that there are standards, but that they are not implemented
consistently. That might actually be the starting place.

Best Regards,

Addison

Addison P. Phillips
Director, Globalization Architecture
webMethods | Delivering Global Business Visibility
http://www.webMethods.com
Chair, W3C Internationalization (I18N) Working Group
Chair, W3C-I18N-WG, Web Services Task Force
http://www.w3.org/International

Internationalization is an architecture.
It is not a feature.

> -----Original Message-----
> From: www-international-request <at> w3.org
> [mailto:www-international-request <at> w3.org]On Behalf Of Paul Deuter
> (by way of Martin Duerst <duerst <at> w3.org>)
> Sent: lundi 3 novembre 2003 04:06
> To: www-international <at> w3.org
> Subject: AW: Problem in downloading a pdf file having Japanese
> characters in the name of the file
(Continue reading)

Permalink | Reply | 1 comment |
headers
A. Vine | 3 Nov 2003 19:23
Picon

Re: Problem in downloading a pdf file having Japanese characters in the name of the file


What a response.  }sigh{

Jungshik Shin wrote:
> A. Vine wrote:
> 
>>
>> I'm with Steve.  
> 
> 
> On what? I don't think he took any position.

Explained just after I made that comment, but since you didn't make the 
connection - I'm with Steve who said he didn't use RFC 2231.  I'm with 
Steve who used RFC 2047.  I agree with Steve's solution, as imperfect as 
it may be.

> 
>> RFC 2231 is so awkward and has so little support (it's
>> been around for many years and yet only now have even a few products 
>> decided to support it) 
> 
> 
>  It's not more awkward than RFC 2047 for simple cases.

For simple cases.  But you can't support RFC 2231 for "simple cases" 
only.  It is as awkward as RFC 2047 in simple cases but has the extra 
disadvantage that it is different from RFC 2047, and RFC 2047 was 
implemented first.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Jungshik Shin | 3 Nov 2003 19:30

Re: Problem in downloading a pdf file having Japanese characters in the name of the file


On Mon, 3 Nov 2003, A. Vine wrote:

> Jungshik Shin wrote:
> > A. Vine wrote:

> >> I'm with Steve.
> >
> >
> > On what? I don't think he took any position.
>
> Explained just after I made that comment, but since you didn't make the
> connection -
> I'm with Steve who said he didn't use RFC 2231.  I'm with

  It was perfectly clear to me what you're alluding to by that sentence.
See below.

> Steve who used RFC 2047.  I agree with Steve's solution, as imperfect as
> it may be.

 I knew he had done that, but he tried RFC 2231 first _before_ falling
back to RFC 2047. Besides, he didn't make any comment on the awakardness
of RFC 2231. So, apparently, his position was not (entirely) in line with
yours, which was my point.

> >> RFC 2231 is so awkward and has so little support (it's
> >> been around for many years and yet only now have even a few products
> >> decided to support it)
> >
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jungshik Shin | 3 Nov 2003 19:59

RE: Problem in downloading a pdf file having Japanese characters in the name of the file


On Mon, 3 Nov 2003, Addison Phillips [wM] wrote:

> I think that an Internet-Draft with the IETF (that is, a new RFC) would be a
> more likely alternative, since RFCs define the headers and their semantics.
>
> It also seems that there are standards, but that they are not implemented
> consistently. That might actually be the starting place.

 I agree.

> > -----Original Message-----
> > From: www-international-request <at> w3.org
> >
> > Steve is correct.  There does not seem to be any standard for encoding
> > the "filename" value in the Content-Disposition header.

  At least for emails, there is clearly the standard(it's RFC 2231).
To be compliant with RFC 822/STD 11, one cannot use RFC 2047-style
encoding for filename and other parameters of MIME header fields.

  When it comes to http headers, there's no explicit mention. However,
http borrows several things from MIME so that it's quite natural to
assume what's true of RFC 822/STD 11 and MIME is also true of HTTP in
absence of a provision explicitly saying otherwise.

 As I wrote earlier, it's regrettable and unfortunate that it's buried
deep inside RFC 2231. It's certainly unlikely that many people came to
that document while looking for answers on the issue.
(Continue reading)

Permalink | Reply | 0 comments |
headers
A. Vine | 3 Nov 2003 20:18
Picon

Re: Problem in downloading a pdf file having Japanese characters in the name of the file


Too hostile.  Your word is last.  Bask in your glory.

Jungshik Shin wrote:

> On Mon, 3 Nov 2003, A. Vine wrote:
> 
> 
>>Jungshik Shin wrote:
>>
>>>A. Vine wrote:
> 
> 
>>>>I'm with Steve.
>>>
>>>
>>>On what? I don't think he took any position.
>>
>>Explained just after I made that comment, but since you didn't make the
>>connection -
>>I'm with Steve who said he didn't use RFC 2231.  I'm with
> 
> 
>   It was perfectly clear to me what you're alluding to by that sentence.
> See below.
> 
> 
>>Steve who used RFC 2047.  I agree with Steve's solution, as imperfect as
>>it may be.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Richard Ishida | 4 Nov 2003 18:03
Picon
Favicon
Gravatar

News: Addison Phillips becomes Internationalization Working Group Chair


Addison Phillips, Director of Globalization Architecture at WebMethods
[1], has become Chair of the W3C Internationalization Working Group [2].
Addison has been chairing the Internationalization Web Services Task
Force [3] since November last year, and will continue in that role.
Richard Ishida will now replace Martin Dürst as Staff Contact for the
Internationalization Working Group, but will continue in his role as
chair of the GEO Task Force [4].

[1] http://www.webmethods.com/
[2] http://www.w3.org/International/
[3] http://www.w3.org/International/ws/
[4] http://www.w3.org/International/geo/

============
Richard Ishida
W3C

contact info: http://www.w3.org/People/Ishida/ 

http://www.w3.org/International/ 
http://www.w3.org/International/geo/ 

W3C Internationalization FAQs
http://www.w3.org/International/questions.html
RSS feed: http://www.w3.org/International/questions.rss
Permalink | Reply | 0 comments |

Gmane