I'm creating a webapp which involves displaying financial data to the user. Being from the UK and using GBP £ for currency, this character is used a lot.
However, every now and then, the £ is shown as a diamond with a question mark in the middle, and on the web page it throws an invalid charachter UTF-8 byte 1 of 1 byte string.
Is there a UTF safe way to display the £
sign? Here is an example of what I am doing at the moment:
"Rent Per Annum: £" + '${tenant.currentRent}'
A portable way of writing this in HTML as an entity is
£
or in the general case by its character code£
or£
£. This way, your source is plain 7-bit ASCII, so basically independent of encoding (ignoring esoterics like EBCDIC etc). See also http://www.fileformat.info/info/unicode/char/a3/index.htmThe particular problem can have at least the following one or more causes:
The JSP file is not by the editor (Eclipse, Netbeans, Notepad, etc) been saved using UTF-8 encoding.
The server didn't use UTF-8 to decode the characters produced by the JSP to a byte stream before sending it over network.
The browser didn't use UTF-8 to encode the byte stream from the network to characters.
Those problems can be solved as follows:
Configure the editor to save JSP files using UTF-8. I'm not familiar with STS, but I know that it is Eclipse based, so it'll probably be the same as in standard Eclipse. Go to Window > Preferences > General > Workspace > Text File Encoding and then pick the right encoding in the dropdown.
An alternative is to use the HTML entity
£
(as suggested by the other answerer), this way it's not relevant anymore in which encoding the JSP file is saved. All characters involved in the string£
are supported by the basic ASCII encoding already (every decent character encoding used in the world basically "extends" ASCII, so it'll always work) and the HTML interpreter (the webbrower) will translate the HTML entity into the right character.The server has to be instructed to use UTF-8 to decode the JSP output. This can on a per-JSP basis be done by
or on an application-wide basis by
The browser has to be instructed to use UTF-8 to encode the HTTP response. This is to be solved by setting the
charset
attribute of the HTTP responseContent-Type
header to UTF-8, which is already implicitly done by the solution to cause #2.See also: