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
The 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
<%@page pageEncoding="UTF-8" %>
or on an application-wide basis by
<jsp-config>
<jsp-property-group>
<url-pattern>*.jsp</url-pattern>
<page-encoding>UTF-8</page-encoding>
</jsp-property-group>
</jsp-config>
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 response Content-Type
header to UTF-8, which is already implicitly done by the solution to cause #2.
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.htm