Apostrophes Again

Question

Wow, the world of special characters and entities rivals
mod-rewrites as
a black art...
I've long used &-#-8-2-1-7; (without the hyphens) to
represent
apostrophes in my articles, until David Powers informed me
that that's
actually the code for a right single quote (complemented by
the single
quote on the left).
That launched me on the surprisingly difficult quest to
discover exactly
WHAT people use to represent apostrophes. I was finally told
to use
this... ’ I don't know how it will show up in this post,
but it looks
pretty much like a stick-figure apostrophe leaning slightly
to the
right. Here it is again, to the left of a stick-figure
apostrophe: ’'
Anyway, I began replacing the apostrophes in my articles.
Today, I began
previewing some of my revised articles, only to discover that
Opera
doesn't like my new apostrophes. They looked fine in Firefox
and Safari,
but Opera displayed them as tiny black diamonds with white
question
marks. When I viewed the source code, they looked like tiny
squares.
Here's where it gets really weird: A few hours later, I
looked at my
pages in Firefox and Safari again, and they had also gone
bad. Safari
displays the apostrophes as black diamonds in both the text
and source code.
I have this in the head section:
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
Does anyone have any ideas what's going on? I'm about ready
to go back
to using &-#-8-2-1-7-; at least it works, and it can be
copied and
pasted between programs. My pages validate with it, so it
must not cause
any technical problems, right?
Thanks.

Answer 1

.oO(David Blomstrom)
>OK, I went back to latin1_general_ci and &#-8217;,
and everything seems
>to be OK. However, I'm going to take your advice and
implement some
>additional changes, like changing the collation on my
text fields to utf8.
Not only the collation, but the charset. Might take some time
to get
used to it, though, but IMHO it's worth it. Once you got it
all running
with UTF-8, it simply works.
>Michael Fesser wrote:
>
>> My text columns are all defined as UTF-8 (utf8 in
MySQL - note the
>> missing dash) without an explicitly defined
collation, so it defaults to
>> utf8_general_ci, e.g.
>>
>> CREATE TABLE foo (
>> bar CHAR(40) CHARACTER SET utf8 NOT NULL DEFAULT '',
>> ...
>> ) ENGINE=InnoDB DEFAULT CHARACTER SET latin1;
>
>I just created my first table via SQL ever after copying
the following
>code from a tutorial:
>
>CREATE TABLE people (name VARCHAR(30), age INTEGER,
height FLOAT, date
>DATETIME)
>
>Then I tried your code, but it appears that I need to
replace ... (on
>the third line) with something relevant - but I'm not
sure what.
It was just a snippet from a real query (with another table
name of
course ...) Usually there are some more columns, a primary
key
definition, maybe some indexes and foreign key constraints
and so on - I
simply stripped all that stuff in the example above. That was
the '...'
part.
>May I
>ask how I can modify your script so it works as is?
In its most simple form this should do:
CREATE TABLE foo (
bar CHAR(40) CHARACTER SET utf8
I usually declare some more things, for example the used
storage engine
and the default charset for the table, just to be sure and
independent
from the server configuration. You can safely ignore them for
now.
Given your own query from above, I would write it like this
(just
reformatted for legibility, one column definition per line):
CREATE TABLE people (
name VARCHAR(30),
age INTEGER,
height FLOAT,
date DATETIME
Making the 'name' column UTF-8 is pretty easy then:
CREATE TABLE people (
name VARCHAR(30) CHARACTER SET utf8,
age INTEGER,
height FLOAT,
date DATETIME
>Also, isn't there some way to display an existing table's
code using
>phpMyAdmin? In other words, if you have a table named
table_animals, you
>could open it, then somehow display a CREATE TABLE
statement that you
>could use to create an identical table in another
database.
>
>I checked in SQL, Export and Operations but didn't find
such a function.
I usually don't use phpMyAdmin, I prefer the command line. On
the MySQL
command line you could do a query like
SHOW CREATE TABLE table_animals\G
to get the full CREATE statement that was used internally by
MySQL to
create that table. Then there's also the powerful tool
mysqldump, which
can be used to dump a table structure to screen or into a
file:
mysqldump -uUsername -p -d DatabaseName table_animals
You can also use phpMyAdmin to get such a dump, but you'll
probably have
to copy the CREATE statement from it by hand. I don't know if
there's an
export option to only dump the table structure and not all
the data
(this is what the -d parameter does if you do it on the
command line).
>So in other words, I should do something like this?:
>
>* * * * *
>
><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01
Transitional//EN"
>"
http://www.w3.org/TR/html4/loose.dtd">
><?php
>header('Content-Type: text/html; charset=UTF-8');
>?>
><html>
><head>
><meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
><title></title>
>
>* * * * *
>
>I'm assuming the header thus inserted renders <meta
>http-equiv="Content-Type" content="text/html;
charset=UTF-8"> somewhat
>redundant, but I should probably hang on to it anyway,
right?
Correc, it is redundant. Dreamweaver always inserts it by
default and it
doesn't hurt anyway, but it's usually pretty useless. Its
only real use
is if the document is served to a browser without a server,
for example
a local copy stored on disk. But if the page is delivered by
a server,
then the HTTP header matters and always takes precedence.
It's safe to
use both the HTTP header and the meta thingy, just make sure
that both
have the same value.
>You also wrote, "The second thing can be solved by
sending this query
>right after connecting to the DB::"
>SET NAMES 'utf8';
>
>"This sets the connection encoding between the DB and
your script."
>
>How do you do that "SET NAMES utf8"? Or is that what this
is all about?...
>
>header('Content-Type: text/html; charset=UTF-8');
Nope, this is HTTP, not MySQL.
There are at least four places in MySQL where a character
encoding is
taken into account: the database, the tables, the columns and
the
connection to the client/script. All these encodings can be
defined
independently if necessary, but what really matters in
practice are the
encodings used in the table columns (as shown in the examples
above) and
the connection encoding. For example MySQL is able to store
the data as
UTF-8, but deliver it as something completely different to
your script.
We usually don't want this, so we set the connection encoding
to UTF-8
as well. This is done with the mentioned query. You should
send it as
the first query after establishing the connection to the DB:
mysql_connect(...);
mysql_query('SET NAMES utf8');
This ensures that all following data transfers between your
script and
the database will handle the data correctly as UTF-8 and
won't change
its encoding.
And simply spoken the header() call just does a similar thing
for the
way between your script and the user's browser:
SET NAMES utf8 header('Content-Type: ...')
DB ----------------> PHP Script
-----------------------------> Browser
It probably sounds more complicated than it actually is. ;-)
Micha