My keyboard has no £ key so if I need one I either copy and paste one or use
alt 0163......... works ok.
This is _potentially_ a big complicated area. There's a narrow path
through it to "just make it work" without needing to understand
everything, but you need to listen carefully to advice and do what
you're told. Trying to set off on your own with a partial
understanding (such as using <meta>) is likely to go wrong.
There are levels of understanding you can reach to get it working.
These range for "knowing everything" (read and _understand_ Jukka's
web pages on the subject, together with their links) to "knowing
nothing" (just type in "£" and smile) or else a middle way for
"competent" web coders.
You need to make three things _all_ work to display a "£"
* A client-side font for the user that has a "£" glyph
* A reference to a character that will display as this glyph
* Correctly encoding some bytes so as to be recognised as this
character (that's where most people go wrong).
The font is easy these days. It's also difficult to fix otherwise
(i.e. for ancient browsers and OS) - web coders have always had very
limited control over client-side fonts. If you leave the client-side
font choice with the family names of serif or sans-serif, most
commonplace desktop browsers will now have access to a suitable font
with a glyph that covers "£".
To refer to the character, either enter it from the keyboard (either
by pressing "£" or by pressing Alt-0163). This gives you the correct
character and if you get the encoding right too, then this ought to
work (sounds like it isn't here though).
Now what's an encoding? A "character" is one entry in a list of
characters, "encoding" is the selection of bits and bytes to indicate
which of these characters is meant. For most uses you need to make the
encoding used to read the web page the same as the encoding used to
create it. There are a great many encodings, but they come in three
families (at a vague hand-waving level): ASCII-like, ISO-8859-* and
UTF
ASCII-like encodings are old and only cope with a character set of up
to 127 or possibly 255 characters. This makes them simple "one byte
per character" encodings, but it isn't enough to do international web
work and so they're really not much use any more.
There are a number of ISO-8859-* character sets and encodings. They're
all the same as ASCII for the characters up to 127 (and are thus the
same as each other) but the characters beyond this vary. This gives
the advantage of simple "one byte per character" encoding and also
international coverage of Western languages. Their two disadvantages
are that you must know _which_ ISO-8859-* encoding was used before you
can decode it, also that you can't use two of them simultaneously in
the same document (makes a Russian - Norwegian dictionary difficult).
Then there's Unicode / UTF. Unicode takes the approach of _one_ huge
character set that works for everything from English ASCII though to
Klingon, via French, Norwegian, Russian, Chinese and 17th century
Tamil. You use one of the UTF encodings to handle it. This encoding is
a bit tricky - but that's OK, because you don't have to write the code
to handle it, your OS (if vaguely modern) does it for you. The easiest
choice is UTF-8, just watch out for M$oft tools that regard the
default for "Unicode" as being UTF-16 instead (UTF-8 is there too,
just a few choices down). UTF-8Y is similar, but not the same and
probably best avoided.
Your best approach for "typical" "competent" work these days is to go
straight for UTF-8. You need tools that handle it (nearly everything
vaguely modern can) and to ruthlessly purge old config settings that
are working with ISO-8859-*. You could use either approach on its own,
it's when you try and mix them carelessly that stuff actually goes
wrong. So decide on UTF-8 as a goal, and when anything shows up that
isn't set that way, fix it to UTF-8. This applies especially if you're
international, or a multi-developer project.
Part of this requires you to configure your web server so that it
serves HTTP headers to indicate UTF-8 and definitely NOT ISO-8859-* or
an ASCII default. That's 5 minutes work with .htaccess Just do it.
Don't be scared of switching to Unicode / UTF-8, it's the easiest
choice long-term.
What about <meta http-equiv="content-type" > ? Forget it! Don't use
it! The problem is that it can indicate the encoding used, but it's
given a low priority on receiving content, so that it's always over-
ridden by the real header. It's _only_ useful if you're publishing
through CDRs etc. rather than a web server and it's all you have. Set
it by all means, just don't expect any of the browsers reading it to
pay attention.
What if you still can't get the readers' encoding to match the
creator's encoding? In that case look at entities (or else fix the
HTTP headers). Rather than entering a literal "£" character into your
document, type in a string of characters instead that represent a HTML
entity: either "£" or "£"
They're listed here:
http://www.w3.org/TR/html4/sgml/entities.html
The great thing about these entities is that they always refer to the
_Unicode_ characters they describe, no matter what the encoding used
in the document. If you can't switch this from ISO-8859-foo for some
reason, specify the pound character through the entity instead and
it'll be understandable by the browser, no matter what the encoding
used for the page (this is also one way to do a Norwegian-Russian
dictionary in ISO-8859-*).
Even entities don't _always_ work. Many publishing engines (blogs,
wikis, etc.) convert the entity into a literal character on saving,
which is then prone to the same encoding errors as if you'd entered it
yourself. If you're just editing HTML files directly though, this
shouldn't affect you.
