[
https://issues.apache.org/jira/browse/HTTPCLIENT-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12492334
]
Dolf Dijkstra commented on HTTPCLIENT-293:
------------------------------------------
Hi Oleg,
Maybe the report is not clear.
According to the mult-part mime spec the correct behaviour would be to use a
construct is via the MimeUtility. The problem with that is that the
mime-parsers that I have tested with don't handle this correctly.
When just encoding the filename with the charset of the request, it works but
it is not according to the spec.
The patch I handed in, works on most mime parsers (as IE is doing this too) but
is not according to the spec.
I understand that you don't want to introduce a new dependancy, but maybe you
don't need to as the patch works without the MimeUtility. The line containing
the MimeUtility is commented.
Dolf
> Provide support for non-ASCII charsets in the multipart disposition-content
> header
> ----------------------------------------------------------------------------------
>
> Key: HTTPCLIENT-293
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-293
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: HttpClient
> Affects Versions: 1.0 Alpha
> Environment: Operating System: All
> Platform: All
> Reporter: Eric Dofonsou
> Priority: Minor
> Fix For: 4.0 Final
>
>
> Because of the the following line in getAsciiBytes
> data.getBytes("US-ASCII");
> The returned string is modified if has Latin Characters.
> Ex : Document non-controlé -> Document non-control?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
