Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>As mentioned already the first look should always go to the <a href="http://www.greenbytes.de/tech/webdav/rfc2616.html" rel="nofollow noreferrer">HTTP 1.1 spec</a> (RFC 2616). <a href="http://www.greenbytes.de/tech/webdav/rfc2616.html#basic.rules" rel="nofollow noreferrer">It says</a> that text in header values must use the MIME encoding as defined <a href="http://tools.ietf.org/html/rfc2047" rel="nofollow noreferrer">RFC 2047</a> if it contains characters from character sets other than ISO-8859-1. </p> <p>So here's a plus for you. If your requirements are covered by the ISO-8859-1 charset then you just put your characters into your request/response messages. Otherwise MIME encoding is the only alternative.</p> <p>As long as the user agent sends the values to your custom headers according to these rules you wont have to worry about decoding them. That's what the Servlet API should do. </p> <hr> <p>However, there's a more basic reason why your code sniplet doesn't do what it's supposed to. The first line fetches the header value as a Java string. As we know it's represented as UTF8 internally so at this point the HTTP request message parsing is already done and finished. </p> <p>The next line fetches the byte array of this string. Since no encoding was specified (IMHO this method with no argument should have been deprecated long ago), the current system default encoding is used, which is usually not UTF8 and then the array is again converted as being UTF8 encoded. Outch.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload