I am trying to put data into header. When i add it in latin, it is received on server side correctly. But when I try to add it in chinese, for example 中國的錯誤, it is received on client as ?????
How can I set header to be encoded as UTF-8?
I tried doing something like this, but it didn't help:
servletResponse.setCharacterEncoding("utf-8");
servletResponse.setContentType("text/html; charset=UTF-8");
Set additionally -Dfile.encoding=utf8 in the string of server startup.
Related
I'm trying to modify some server code which uses an httpExchangeobject to handle the server's response to the client.
My issue is that for responses containing characters not supported by iso-8859-1, such as Chinese characters, I get something like '????' in place of the characters. I'd like to set the encoding of the response to utf-8, but have thus far been unsuccessful in doing so.
I tried adding this line:
httpExchange.getResponseHeaders().put("charset", Arrays.asList("UTF-8"));
This successfully puts a "charset" header in the response, but I still can't send the characters I want in the response.
How do I set the encoding of the response to allow for these characters?
Use Content-Type header to specify encoding.
String encoding = "UTF-8";
httpExchange.getResponseHeaders().set("Content-Type", "text/html; charset=" + encoding);
Writer out = new OutputStreamWriter(httpExchange.getResponseBody(), encoding));
out.write(something);
Our application download files using HttpClient. We take the filename from the HTTP Header and emit out as SysOut (System.out.println())
When there are non-USASCII characters like umlauts the sysout does not decode correctlty.
Ex: filename Textkürzung.txt is printed in sysout (And also in console) as Textk³rzung.txt
How can we encode this to UTF-8? Unfortunately we don't get the encoded character-set from the HTTP Headers
i've a plugin that should process some mails, so i need to get attachments from an imap mail and do some stuff.
All seem to work but i've a single mail that have a strange attachment header and i'm not able to get it correctly, here the attachment header:
--_01d0aeb2-3f01-4153-9121-66b7af6924f1_
Content-Type: application/msword
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=
"=?iso-8859-1?Q?Atto_Aziendale_(xxx=E0_del_xxx_xxx_-_xxx)=2C_Pr?=
=?iso-8859-1?Q?of.xxx_xxx_-_Dr.xxx_xxx.doc?="
"x" are for privacy but that should not be important, the problem is that when i try to get the filename of this attachment with javaMail:
Attachment att = new Attachment(mailPart);
String filename = att.getFilename();
i get only this: "Atto Aziendale (xxx del xxx xxx - xxx), Pr"
seem that it doesn't read the second line.
I've also tried to get the filename in another way:
mailPart.getHeader("Content-Disposition").getAttribute("filename").toString();
and that return: filename="=?iso-8859-1?Q?Atto_Aziendale_(xxx=E0_del_xxx_xxx_-_xxx)=2C_Pr?==?iso-8859-1?Q?of.xxx_xxx_-_Dr.xxx_xxx.doc?="
so it seem that the attribute is correctly readed, but if i try to get:
mailPart.getHeader("Content-Disposition").getAttribute("filename").getValue();
then i get again a truncated filename: "Atto Aziendale (xxx del xxx xxx - xxx), Pr"
anyone know how to get the complete filename or how i should decode the filename attribute?
thanks for any help
If you're using IMAP, the IMAP server is parsing the mail headers and returning the parsed values to the JavaMail client. Your Content-Disposition header has several continuation lines. The IMAP server needs to properly combine those continuation lines and return the parameter values. It looks like the server is omitting the whitespace implied by the continuation line and joining the "?=" with the "=?". Without whitespace between them, they appear to be one encoded word instead of two, which likely explains why you're getting the wrong results when decoding them.
Try setting the System property "mail.mime.decodetext.strict" to "false"; this may allow JavaMail to decode the value. See the javadocs for the javax.mail.internet package for details.
I am talking to a file upload service that accepts post data, not form data. By default, java's HttpURLConnection sets the Content-Type header to application/x-www-form-urlencoded. this is obviously wrong if i'm posting pure data.
I (the client) don't know the content type. I don't want the Content-Type header set at all. the service has a feature where it will guess at the content type (based on the file name, reading some data from the file, etc).
How do I unset a header? There's no remove header, and setting it to null doesn't change the value and setting it to the empty string results in the header being set with no value.
I haven't tested this approach but you can try this:
Extend HttpURLConnection and try by overriding its getContentHandler() and setContentHandler(...) methods. Most probably this should work as, you will take a look at code of getContentHandler().
Use Apache HttpClient instead of URLConnection
Use fluent Request to generate your request
use removeHeader()
What do you mean "i don't want the Content-Type header to set at all"?
The browser (or other http client) sends your post request to the server, so it has to inform the server which way it encoded the parameters.
If the Content-Type header is not set, on the server side you (= your server) won't be able to understand how to parse the received data.
If you didn't set Content-Type, the default value will be used.
You browser (or other http client) MUST do two things:
Send key/value pairs.
Inform the server how the key/value pairs were encoded.
So, it is impossible to completely get rid of this header.
I just accomplished this by setting the header to null.
connection.setRequestProperty(MY_HEADER, null);
I am having trouble in returning compressed response (GZip) from my Java Servlet, to a JSP.
Flow :
Request comes to java servlet
Process the request, and create a JSON object, with the response
Convert the JSON object to string
Compress the response string with GZip
The compressed response string is set as attribute in the request object and control passed to JSP
In the JSP, the response string (compressed) is printed on screen
Precautions :
Request object has "Accepting-Encoding" set with "gzip"
Response header has "Content-Encoding" set to "gzip"
Response content type is set to "application/json"
Response character encoding is set to "ISO-8859-1"
Result :
Firefox shows "Content Encoding Error"
Chrome shows "Error 330 (net::ERR_CONTENT_DECODING_FAILED): Unknown error."
Can anyone help point me out, in the right direction please?
The compressed response string is set as attribute in the request object and control passed to JSP
You shouldn't have forwarded a JSON response to a JSP. You should have printed the JSON plain to the response and have the JavaScript/Ajax code in your JSP Android app to call the URL of the servlet which returns the JSON. See also How to use Servlets and Ajax?.
As to the GZIP compression, you shouldn't do it yourself. Let the server do itself.
Fix your code to remove all manual attempts to compress the response, it should end up to basically look like this:
#Override
protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
String json = createItSomehow();
response.setContentType("application/json");
response.setCharacterEncoding("UTF-8");
response.getWriter().write(json);
}
That's all, if you let your Android app call the URL of the servlet, it'll retrieve the JSON string.
Finally edit the server configuration to turn on automatic GZIP compression. In case of for example Tomcat, that would be a matter of adding compression="on" to the <Connector> element in Tomcat's /conf/server.xml file:
<Connector ... compression="on">
As per the documentation, the compressable mime types defaults to text/html,text/xml,text/plain. You can configure this to add application/json.
<Connector ... compression="on" compressableMimeType="text/html,text/xml,text/plain,application/json">
Unrelated to the concrete problem, the response character encoding must be set to UTF-8 which is as per the JSON specification.
JSPs are for rendering textual data to the client. GZIP is binary data, even if it is compressed text underneath.
I suggest using a GZIP servlet filter to compress your data on the fly, instead of doing it programmatically in your business logic.
See this prior question for how to get hold of one off-the shelf: Which compression (is GZIP the most popular) servlet filter would you suggest?
Failing that, then write your own servlet filter that does the same thing.