Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.php > #2178 > unrolled thread

Displaying UTF-8-encoded strings from MySQL with PHP

Started byLuke <kickingjesus@gmail.com>
First post2011-06-15 03:18 -0700
Last post2011-06-17 13:23 +0200
Articles 14 — 5 participants

Back to article view | Back to comp.lang.php


Contents

  Displaying UTF-8-encoded strings from MySQL with PHP Luke <kickingjesus@gmail.com> - 2011-06-15 03:18 -0700
    Re: Displaying UTF-8-encoded strings from MySQL with PHP "Álvaro G. Vicario" <alvaro.NOSPAMTHANX@demogracia.com.invalid> - 2011-06-15 12:26 +0200
      Re: Displaying UTF-8-encoded strings from MySQL with PHP Jerry Stuckle <jstucklex@attglobal.net> - 2011-06-15 06:53 -0400
        Re: Displaying UTF-8-encoded strings from MySQL with PHP "Álvaro G. Vicario" <alvaro.NOSPAMTHANX@demogracia.com.invalid> - 2011-06-15 13:57 +0200
          Re: Displaying UTF-8-encoded strings from MySQL with PHP Jerry Stuckle <jstucklex@attglobal.net> - 2011-06-15 12:07 -0400
            Re: Displaying UTF-8-encoded strings from MySQL with PHP "Álvaro G. Vicario" <alvaro.NOSPAMTHANX@demogracia.com.invalid> - 2011-06-16 09:29 +0200
      Re: Displaying UTF-8-encoded strings from MySQL with PHP Luke <kickingjesus@gmail.com> - 2011-06-15 05:56 -0700
        Re: Displaying UTF-8-encoded strings from MySQL with PHP Luke <kickingjesus@gmail.com> - 2011-06-15 06:05 -0700
          Re: Displaying UTF-8-encoded strings from MySQL with PHP Luke <kickingjesus@gmail.com> - 2011-06-15 06:23 -0700
            Re: Displaying UTF-8-encoded strings from MySQL with PHP Luke <kickingjesus@gmail.com> - 2011-06-15 06:50 -0700
              Re: Displaying UTF-8-encoded strings from MySQL with PHP "Álvaro G. Vicario" <alvaro.NOSPAMTHANX@demogracia.com.invalid> - 2011-06-15 16:17 +0200
                Re: Displaying UTF-8-encoded strings from MySQL with PHP Tim Streater <timstreater@waitrose.com> - 2011-06-15 15:26 +0100
    Re: Displaying UTF-8-encoded strings from MySQL with PHP Jo Schulze <antispam@feuersee.de> - 2011-06-16 23:34 +0200
      Re: Displaying UTF-8-encoded strings from MySQL with PHP "Álvaro G. Vicario" <alvaro.NOSPAMTHANX@demogracia.com.invalid> - 2011-06-17 13:23 +0200

#2178 — Displaying UTF-8-encoded strings from MySQL with PHP

FromLuke <kickingjesus@gmail.com>
Date2011-06-15 03:18 -0700
SubjectDisplaying UTF-8-encoded strings from MySQL with PHP
Message-ID<e1fa9d06-3720-4489-9667-14bba4aa3506@d1g2000yqm.googlegroups.com>
Hi there,

I'm trying to migrate my project from ISO-8859-1 (Western Europe) to
UTF-8. I *can* write special characters as regular text in my php-
files, I can use special characters in echo-statements and I can even
use special characters in .ini-files, load them, and display them. But
when I load Strings with special characters from MySQL and display
them, the string's "broken".

I've tried many things: First of all, I use

<?xml version="1.0" encoding="utf-8" ?>
and
<meta http-equiv="Content-Type" content="text/html;charset=utf-8" />

in the markup. In the database I tried to set my table's collation to
"utf8_general_ci". Also I tried the following functions:

mysql_query("SET NAMES ‘utf8′");
mysql_set_charset('utf8');
mb_internal_encoding("UTF-8");

all not at the very beginning of my script, but before I queried the
database and before I printed the results. I still keep getting
'wierd' characters.

Does anyone have an idea what I can do?

Thanks,
Lukas

[toc] | [next] | [standalone]


#2179

From"Álvaro G. Vicario" <alvaro.NOSPAMTHANX@demogracia.com.invalid>
Date2011-06-15 12:26 +0200
Message-ID<ita1dk$1b8$1@dont-email.me>
In reply to#2178
El 15/06/2011 12:18, Luke escribió/wrote:
> I'm trying to migrate my project from ISO-8859-1 (Western Europe) to
> UTF-8. I *can* write special characters as regular text in my php-
> files, I can use special characters in echo-statements and I can even
> use special characters in .ini-files, load them, and display them. But
> when I load Strings with special characters from MySQL and display
> them, the string's "broken".
>
> I've tried many things: First of all, I use
>
> <?xml version="1.0" encoding="utf-8" ?>
> and
> <meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
>
> in the markup. In the database I tried to set my table's collation to
> "utf8_general_ci". Also I tried the following functions:
>
> mysql_query("SET NAMES ‘utf8′");
> mysql_set_charset('utf8');
> mb_internal_encoding("UTF-8");
>
> all not at the very beginning of my script, but before I queried the
> database and before I printed the results. I still keep getting
> 'wierd' characters.
>
> Does anyone have an idea what I can do?

Here's quite a complete list of the required steps:

http://www.itnewb.com/v/UTF-8-Enabled-Apache-MySQL-PHP-Markup-and-JavaScript

Whatever, are you sure that your data is actually stored as valid UTF-8 
after the migration?

The HEX() function can be handy:

http://dev.mysql.com/doc/refman/5.5/en/string-functions.html#function_hex



-- 
-- http://alvaro.es - Álvaro G. Vicario - Burgos, Spain
-- Mi sitio sobre programación web: http://borrame.com
-- Mi web de humor satinado: http://www.demogracia.com
--

[toc] | [prev] | [next] | [standalone]


#2181

FromJerry Stuckle <jstucklex@attglobal.net>
Date2011-06-15 06:53 -0400
Message-ID<ita2uk$a3f$1@dont-email.me>
In reply to#2179
On 6/15/2011 6:26 AM, "Álvaro G. Vicario" wrote:
> El 15/06/2011 12:18, Luke escribió/wrote:
>> I'm trying to migrate my project from ISO-8859-1 (Western Europe) to
>> UTF-8. I *can* write special characters as regular text in my php-
>> files, I can use special characters in echo-statements and I can even
>> use special characters in .ini-files, load them, and display them. But
>> when I load Strings with special characters from MySQL and display
>> them, the string's "broken".
>>
>> I've tried many things: First of all, I use
>>
>> <?xml version="1.0" encoding="utf-8" ?>
>> and
>> <meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
>>
>> in the markup. In the database I tried to set my table's collation to
>> "utf8_general_ci". Also I tried the following functions:
>>
>> mysql_query("SET NAMES ‘utf8′");
>> mysql_set_charset('utf8');
>> mb_internal_encoding("UTF-8");
>>
>> all not at the very beginning of my script, but before I queried the
>> database and before I printed the results. I still keep getting
>> 'wierd' characters.
>>
>> Does anyone have an idea what I can do?
>
> Here's quite a complete list of the required steps:
>
> http://www.itnewb.com/v/UTF-8-Enabled-Apache-MySQL-PHP-Markup-and-JavaScript
>
>
> Whatever, are you sure that your data is actually stored as valid UTF-8
> after the migration?
>
> The HEX() function can be handy:
>
> http://dev.mysql.com/doc/refman/5.5/en/string-functions.html#function_hex
>
>
>

Álvaro, I admit I'm not great at UTF-8.  This is a great guide if you 
have your own server and want everything in UTF-8.  However, do you know 
of a similar reference for those who use shared servers and/or don't 
want everything to default to UTF-8?

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]


#2182

From"Álvaro G. Vicario" <alvaro.NOSPAMTHANX@demogracia.com.invalid>
Date2011-06-15 13:57 +0200
Message-ID<ita6mq$vtv$1@dont-email.me>
In reply to#2181
El 15/06/2011 12:53, Jerry Stuckle escribió/wrote:
>> http://www.itnewb.com/v/UTF-8-Enabled-Apache-MySQL-PHP-Markup-and-JavaScript
>>
>>
>>
>> Whatever, are you sure that your data is actually stored as valid UTF-8
>> after the migration?
>>
>> The HEX() function can be handy:
>>
>> http://dev.mysql.com/doc/refman/5.5/en/string-functions.html#function_hex
>>
>>
>>
>
> Álvaro, I admit I'm not great at UTF-8.  This is a great guide if you
> have your own server and want everything in UTF-8.  However, do you know
> of a similar reference for those who use shared servers and/or don't
> want everything to default to UTF-8?

I suppose you refer to the MySQL section (the rest of the stuff is easy 
to customize). I believe you can safely ignore it: it's only a trick to 
use UTF-8 with misconfigured clients. All you have to do is, well, 
configure your client properly. From my experience, this is all you need 
in PHP:


// Good old MySQL extension
mysql_set_charset('utf8', $conn)


// PDO
$pdo_options = array(
	PDO::MYSQL_ATTR_INIT_COMMAND => 'SET NAMES utf8',
);
$conn = new PDO(..., $pdo_options);


With mb_convert_encoding() you can retrieve and store UTF-8 data even if 
your app does not use it ;-)


-- 
-- http://alvaro.es - Álvaro G. Vicario - Burgos, Spain
-- Mi sitio sobre programación web: http://borrame.com
-- Mi web de humor satinado: http://www.demogracia.com
--

[toc] | [prev] | [next] | [standalone]


#2196

FromJerry Stuckle <jstucklex@attglobal.net>
Date2011-06-15 12:07 -0400
Message-ID<italc3$4n8$1@dont-email.me>
In reply to#2182
On 6/15/2011 7:57 AM, "Álvaro G. Vicario" wrote:
> El 15/06/2011 12:53, Jerry Stuckle escribió/wrote:
>>> http://www.itnewb.com/v/UTF-8-Enabled-Apache-MySQL-PHP-Markup-and-JavaScript
>>>
>>>
>>>
>>>
>>> Whatever, are you sure that your data is actually stored as valid UTF-8
>>> after the migration?
>>>
>>> The HEX() function can be handy:
>>>
>>> http://dev.mysql.com/doc/refman/5.5/en/string-functions.html#function_hex
>>>
>>>
>>>
>>>
>>
>> Álvaro, I admit I'm not great at UTF-8. This is a great guide if you
>> have your own server and want everything in UTF-8. However, do you know
>> of a similar reference for those who use shared servers and/or don't
>> want everything to default to UTF-8?
>
> I suppose you refer to the MySQL section (the rest of the stuff is easy
> to customize). I believe you can safely ignore it: it's only a trick to
> use UTF-8 with misconfigured clients. All you have to do is, well,
> configure your client properly. From my experience, this is all you need
> in PHP:
>

That's part of it, but even the PHP and Apache configurations can be 
hard to duplicate in your code, and generally you need to do it in every 
file.

Of course, you can use .htaccess to configure such, if the web server 
allows.  But I'm not even sure if some of those Apache settings are 
valid in the .htaccess (haven't checked).  And of course .htaccess isn't 
available if you're running on IIS.

>
> // Good old MySQL extension
> mysql_set_charset('utf8', $conn)
>
>
> // PDO
> $pdo_options = array(
> PDO::MYSQL_ATTR_INIT_COMMAND => 'SET NAMES utf8',
> );
> $conn = new PDO(..., $pdo_options);
>
>
> With mb_convert_encoding() you can retrieve and store UTF-8 data even if
> your app does not use it ;-)
>
>

How's mb_convert_encoding() working?  Is it correct in converting 
(assuming, of course, the character exists in the character set being 
converted to).

I'm asking this because I only dabbled a bit in utf-8 several years ago, 
and haven't touched it since (yea, we Americans think the whole world 
revolves around us :) ).  But I may soon be involved in a project which 
does use it.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]


#2201

From"Álvaro G. Vicario" <alvaro.NOSPAMTHANX@demogracia.com.invalid>
Date2011-06-16 09:29 +0200
Message-ID<itcbdj$5dp$1@dont-email.me>
In reply to#2196
El 15/06/2011 18:07, Jerry Stuckle escribió/wrote:
>> With mb_convert_encoding() you can retrieve and store UTF-8 data even if
>> your app does not use it ;-)
>>
>>
>
> How's mb_convert_encoding() working?  Is it correct in converting
> (assuming, of course, the character exists in the character set being
> converted to).

You can do something like this:

mb_convert_encoding(
	htmlspecialchars($foo, ENT_COMPAT, 'UTF-8'),
	'HTML-ENTITIES',
	'UTF-8'
)

 From "ABC <123> áéí € ㍝" you'd get:

ABC &lt;123&gt; &aacute;&eacute;&iacute; &euro; &#13149;

It's not something I'd recommend if you can avoid it but it can be done.


> I'm asking this because I only dabbled a bit in utf-8 several years ago,
> and haven't touched it since (yea, we Americans think the whole world
> revolves around us :) ).  But I may soon be involved in a project which
> does use it.

Well, you Americans can switch to UTF-8 quite easily, given that's a 
superset of good old 7-bit ASCII. It's not like in Europe, where failing 
to recognise the file charset will ruin your data :)


-- 
-- http://alvaro.es - Álvaro G. Vicario - Burgos, Spain
-- Mi sitio sobre programación web: http://borrame.com
-- Mi web de humor satinado: http://www.demogracia.com
--

[toc] | [prev] | [next] | [standalone]


#2186

FromLuke <kickingjesus@gmail.com>
Date2011-06-15 05:56 -0700
Message-ID<0477a430-ce92-409c-8096-f3ec2108bc54@x3g2000yqj.googlegroups.com>
In reply to#2179
> Whatever, are you sure that your data is actually stored as valid UTF-8
> after the migration?
>
> The HEX() function can be handy:
>
> http://dev.mysql.com/doc/refman/5.5/en/string-functions.html#function...

Hm.. getting closer. But this is very weird:


// Simply performs a query and returns mysql_fetch_assoc on the first
result
$hex = $theDB->getResult("SELECT HEX(link_text) FROM language WHERE
id=2");

// Echos "C3BC" (which is the correct value for the character in the
DB ("ü"))
echo $hex['HEX(link_text)'];

// Selecting the actual value instead of its hex-represenation
$char = $theDB->getResult("SELECT link_text FROM language WHERE
id=2");

// Echos "fc" (which is "�" (broken character))
echo bin2hex($char['link_text']);


I'm a little confused. I tried various functions on this:

$theDB->query("SET NAMES ‘utf8′");
mysql_set_charset('utf8');
mb_internal_encoding("UTF-8");

mb_internal_encoding("UTF-8");

Nothing helps. Changing configurations is not impossible, but very
difficult. Also the database seems fine, as HEX(xx) returns the
correct value, and in my PHP-Scripts I can use UTF-8 characters (that
aren't loaded from the database) and they work too. There must be
something in 'between'…

[toc] | [prev] | [next] | [standalone]


#2187

FromLuke <kickingjesus@gmail.com>
Date2011-06-15 06:05 -0700
Message-ID<673fc65f-1d71-40d2-92ac-354b29536662@r2g2000vbj.googlegroups.com>
In reply to#2186
On Jun 15, 2:56 pm, Luke <kickingje...@gmail.com> wrote:
> > Whatever, are you sure that your data is actually stored as valid UTF-8
> > after the migration?
>
> > The HEX() function can be handy:
>
> >http://dev.mysql.com/doc/refman/5.5/en/string-functions.html#function...
>
> Hm.. getting closer. But this is very weird:
>
> // Simply performs a query and returns mysql_fetch_assoc on the first
> result
> $hex = $theDB->getResult("SELECT HEX(link_text) FROM language WHERE
> id=2");
>
> // Echos "C3BC" (which is the correct value for the character in the
> DB ("ü"))
> echo $hex['HEX(link_text)'];
>
> // Selecting the actual value instead of its hex-represenation
> $char = $theDB->getResult("SELECT link_text FROM language WHERE
> id=2");
>
> // Echos "fc" (which is " " (broken character))
> echo bin2hex($char['link_text']);
>
> I'm a little confused. I tried various functions on this:
>
> $theDB->query("SET NAMES ‘utf8′");
> mysql_set_charset('utf8');
> mb_internal_encoding("UTF-8");
>
> mb_internal_encoding("UTF-8");
>
> Nothing helps. Changing configurations is not impossible, but very
> difficult. Also the database seems fine, as HEX(xx) returns the
> correct value, and in my PHP-Scripts I can use UTF-8 characters (that
> aren't loaded from the database) and they work too. There must be
> something in 'between'…

And it seems FC is the "Hex code point" of the character I'm looking
for. But I actually have no clue what to do. Wikipedia says Hex code
point marks the range in which characters are assigned to languages
(more or less), but i'm not sure why that is returned or even how to
handle this.

[toc] | [prev] | [next] | [standalone]


#2189

FromLuke <kickingjesus@gmail.com>
Date2011-06-15 06:23 -0700
Message-ID<ae9a8953-fc02-4da2-b720-1a3886e5e1e8@a10g2000vbz.googlegroups.com>
In reply to#2187
On Jun 15, 3:05 pm, Luke <kickingje...@gmail.com> wrote:
> On Jun 15, 2:56 pm, Luke <kickingje...@gmail.com> wrote:
>
>
>
>
>
> > > Whatever, are you sure that your data is actually stored as valid UTF-8
> > > after the migration?
>
> > > The HEX() function can be handy:
>
> > >http://dev.mysql.com/doc/refman/5.5/en/string-functions.html#function...
>
> > Hm.. getting closer. But this is very weird:
>
> > // Simply performs a query and returns mysql_fetch_assoc on the first
> > result
> > $hex = $theDB->getResult("SELECT HEX(link_text) FROM language WHERE
> > id=2");
>
> > // Echos "C3BC" (which is the correct value for the character in the
> > DB ("ü"))
> > echo $hex['HEX(link_text)'];
>
> > // Selecting the actual value instead of its hex-represenation
> > $char = $theDB->getResult("SELECT link_text FROM language WHERE
> > id=2");
>
> > // Echos "fc" (which is " " (broken character))
> > echo bin2hex($char['link_text']);
>
> > I'm a little confused. I tried various functions on this:
>
> > $theDB->query("SET NAMES ‘utf8′");
> > mysql_set_charset('utf8');
> > mb_internal_encoding("UTF-8");
>
> > mb_internal_encoding("UTF-8");
>
> > Nothing helps. Changing configurations is not impossible, but very
> > difficult. Also the database seems fine, as HEX(xx) returns the
> > correct value, and in my PHP-Scripts I can use UTF-8 characters (that
> > aren't loaded from the database) and they work too. There must be
> > something in 'between'…
>
> And it seems FC is the "Hex code point" of the character I'm looking
> for. But I actually have no clue what to do. Wikipedia says Hex code
> point marks the range in which characters are assigned to languages
> (more or less), but i'm not sure why that is returned or even how to
> handle this.

Oh wait FC is the ASCII-Value for ü. So the question is, why does PHP
recieve an ASCII-char if the MySQL-Function HEX() returns the correct
UTF-8 hexvalue?

[toc] | [prev] | [next] | [standalone]


#2190

FromLuke <kickingjesus@gmail.com>
Date2011-06-15 06:50 -0700
Message-ID<5eb8ed99-fa58-4112-bdcc-93035b34b588@z37g2000yqb.googlegroups.com>
In reply to#2189
On Jun 15, 3:23 pm, Luke <kickingje...@gmail.com> wrote:
> On Jun 15, 3:05 pm, Luke <kickingje...@gmail.com> wrote:
>
>
>
>
>
> > On Jun 15, 2:56 pm, Luke <kickingje...@gmail.com> wrote:
>
> > > > Whatever, are you sure that your data is actually stored as valid UTF-8
> > > > after the migration?
>
> > > > The HEX() function can be handy:
>
> > > >http://dev.mysql.com/doc/refman/5.5/en/string-functions.html#function...
>
> > > Hm.. getting closer. But this is very weird:
>
> > > // Simply performs a query and returns mysql_fetch_assoc on the first
> > > result
> > > $hex = $theDB->getResult("SELECT HEX(link_text) FROM language WHERE
> > > id=2");
>
> > > // Echos "C3BC" (which is the correct value for the character in the
> > > DB ("ü"))
> > > echo $hex['HEX(link_text)'];
>
> > > // Selecting the actual value instead of its hex-represenation
> > > $char = $theDB->getResult("SELECT link_text FROM language WHERE
> > > id=2");
>
> > > // Echos "fc" (which is " " (broken character))
> > > echo bin2hex($char['link_text']);
>
> > > I'm a little confused. I tried various functions on this:
>
> > > $theDB->query("SET NAMES ‘utf8′");
> > > mysql_set_charset('utf8');
> > > mb_internal_encoding("UTF-8");
>
> > > mb_internal_encoding("UTF-8");
>
> > > Nothing helps. Changing configurations is not impossible, but very
> > > difficult. Also the database seems fine, as HEX(xx) returns the
> > > correct value, and in my PHP-Scripts I can use UTF-8 characters (that
> > > aren't loaded from the database) and they work too. There must be
> > > something in 'between'…
>
> > And it seems FC is the "Hex code point" of the character I'm looking
> > for. But I actually have no clue what to do. Wikipedia says Hex code
> > point marks the range in which characters are assigned to languages
> > (more or less), but i'm not sure why that is returned or even how to
> > handle this.
>
> Oh wait FC is the ASCII-Value for ü. So the question is, why does PHP
> recieve an ASCII-char if the MySQL-Function HEX() returns the correct
> UTF-8 hexvalue?

Ok, I got it. As supposed here http://akrabat.com/php/utf8-php-and-mysql/
I had to query "SET NAMES UTF8;" right after I connected to the
database. No need to change tables or configuring Apache and PHP
(well, I had to insert meta-tags setting UTF-8 as charset, but apart
from that there was nothing else to do).

Still thanks.

[toc] | [prev] | [next] | [standalone]


#2191

From"Álvaro G. Vicario" <alvaro.NOSPAMTHANX@demogracia.com.invalid>
Date2011-06-15 16:17 +0200
Message-ID<itaeu4$lgp$1@dont-email.me>
In reply to#2190
El 15/06/2011 15:50, Luke escribió/wrote:
>>>> // Simply performs a query and returns mysql_fetch_assoc on the first
>>>> result
>>>> $hex = $theDB->getResult("SELECT HEX(link_text) FROM language WHERE
>>>> id=2");
>>
>>>> // Echos "C3BC" (which is the correct value for the character in the
>>>> DB ("ü"))
>>>> echo $hex['HEX(link_text)'];
>>
>>>> // Selecting the actual value instead of its hex-represenation
>>>> $char = $theDB->getResult("SELECT link_text FROM language WHERE
>>>> id=2");
>>
>>>> // Echos "fc" (which is " " (broken character))
>>>> echo bin2hex($char['link_text']);
>>
>>>> I'm a little confused. I tried various functions on this:
>>
>>>> $theDB->query("SET NAMES ‘utf8′");
>>>> mysql_set_charset('utf8');
>>>> mb_internal_encoding("UTF-8");
>>
>>>> mb_internal_encoding("UTF-8");
>>
>>>> Nothing helps. Changing configurations is not impossible, but very
>>>> difficult. Also the database seems fine, as HEX(xx) returns the
>>>> correct value, and in my PHP-Scripts I can use UTF-8 characters (that
>>>> aren't loaded from the database) and they work too. There must be
>>>> something in 'between'…
>>
>>> And it seems FC is the "Hex code point" of the character I'm looking
>>> for. But I actually have no clue what to do. Wikipedia says Hex code
>>> point marks the range in which characters are assigned to languages
>>> (more or less), but i'm not sure why that is returned or even how to
>>> handle this.
>>
>> Oh wait FC is the ASCII-Value for ü. So the question is, why does PHP
>> recieve an ASCII-char if the MySQL-Function HEX() returns the correct
>> UTF-8 hexvalue?


ASCII is a 7-bit encoding that does not have non-English letters like 
"ü". That FC you get is the ISO-8859-1 code. The data gets converted 
from UTF-8 to ISO-8859-1 (or a similar charset).

> Ok, I got it. As supposed here http://akrabat.com/php/utf8-php-and-mysql/
> I had to query "SET NAMES UTF8;" right after I connected to the
> database. No need to change tables or configuring Apache and PHP

Hadn't you tried that already?

http://dev.mysql.com/doc/refman/5.0/en/charset-connection.html

 > (well, I had to insert meta-tags setting UTF-8 as charset, but apart
 > from that there was nothing else to do).

Meta-tags are not useful unless you save the page to disk from your 
browser and open it later. You should either use header() to set the 
Content-Type header or configure it via .htaccess.


-- 
-- http://alvaro.es - Álvaro G. Vicario - Burgos, Spain
-- Mi sitio sobre programación web: http://borrame.com
-- Mi web de humor satinado: http://www.demogracia.com
--

[toc] | [prev] | [next] | [standalone]


#2192

FromTim Streater <timstreater@waitrose.com>
Date2011-06-15 15:26 +0100
Message-ID<timstreater-D2F6FE.15261815062011@news.individual.net>
In reply to#2191
In article <itaeu4$lgp$1@dont-email.me>,
 "輙varo G. Vicario" <alvaro.NOSPAMTHANX@demogracia.com.invalid> wrote:

> El 15/06/2011 15:50, Luke escribi�/wrote:
> >>>> // Simply performs a query and returns mysql_fetch_assoc on the first
> >>>> result
> >>>> $hex = $theDB->getResult("SELECT HEX(link_text) FROM language WHERE
> >>>> id=2");
> >>
> >>>> // Echos "C3BC" (which is the correct value for the character in the
> >>>> DB ("�"))
> >>>> echo $hex['HEX(link_text)'];
> >>
> >>>> // Selecting the actual value instead of its hex-represenation
> >>>> $char = $theDB->getResult("SELECT link_text FROM language WHERE
> >>>> id=2");
> >>
> >>>> // Echos "fc" (which is " " (broken character))
> >>>> echo bin2hex($char['link_text']);
> >>
> >>>> I'm a little confused. I tried various functions on this:
> >>
> >>>> $theDB->query("SET NAMES ヤutf8′");
> >>>> mysql_set_charset('utf8');
> >>>> mb_internal_encoding("UTF-8");
> >>
> >>>> mb_internal_encoding("UTF-8");
> >>
> >>>> Nothing helps. Changing configurations is not impossible, but very
> >>>> difficult. Also the database seems fine, as HEX(xx) returns the
> >>>> correct value, and in my PHP-Scripts I can use UTF-8 characters (that
> >>>> aren't loaded from the database) and they work too. There must be
> >>>> something in 'between'…
> >>
> >>> And it seems FC is the "Hex code point" of the character I'm looking
> >>> for. But I actually have no clue what to do. Wikipedia says Hex code
> >>> point marks the range in which characters are assigned to languages
> >>> (more or less), but i'm not sure why that is returned or even how to
> >>> handle this.
> >>
> >> Oh wait FC is the ASCII-Value for �. So the question is, why does PHP
> >> recieve an ASCII-char if the MySQL-Function HEX() returns the correct
> >> UTF-8 hexvalue?
> 
> 
> ASCII is a 7-bit encoding that does not have non-English letters like 
> "�". That FC you get is the ISO-8859-1 code. The data gets converted 
> from UTF-8 to ISO-8859-1 (or a similar charset).
> 
> > Ok, I got it. As supposed here http://akrabat.com/php/utf8-php-and-mysql/
> > I had to query "SET NAMES UTF8;" right after I connected to the
> > database. No need to change tables or configuring Apache and PHP
> 
> Hadn't you tried that already?
> 
> http://dev.mysql.com/doc/refman/5.0/en/charset-connection.html
> 
>  > (well, I had to insert meta-tags setting UTF-8 as charset, but apart
>  > from that there was nothing else to do).
> 
> Meta-tags are not useful unless you save the page to disk from your 
> browser and open it later. You should either use header() to set the 
> Content-Type header or configure it via .htaccess.

Indeed. Doing this at the start of all my PHP scripts:

header ("Content-Type: text/plain; charset=utf-8");

fixed my char-set problems.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

[toc] | [prev] | [next] | [standalone]


#2204

FromJo Schulze <antispam@feuersee.de>
Date2011-06-16 23:34 +0200
Message-ID<4dfa76fc$0$6554$9b4e6d93@newsspool4.arcor-online.net>
In reply to#2178
Luke wrote:

> I'm trying to migrate my project from ISO-8859-1 (Western Europe) to
> UTF-8. I *can* write special characters as regular text in my php-
> files, I can use special characters in echo-statements and I can even
> use special characters in .ini-files, load them, and display them. But
> when I load Strings with special characters from MySQL and display
> them, the string's "broken".

Which MySQL Server version are we talking about?

> <?xml version="1.0" encoding="utf-8" ?>
> and
> <meta http-equiv="Content-Type" content="text/html;charset=utf-8" />

Both instruct the client that the data to be displayed should be UTF-8. 
No verification done.

> in the markup. In the database I tried to set my table's collation to
> "utf8_general_ci". 

As the name implies, the collation does only affect the sorting behavior 
of MySQL. It does _not_ change the encoding of the database content.

> Also I tried the following functions:
> 
> mysql_query("SET NAMES ‘utf8′");

good one

> mysql_set_charset('utf8');

good one (if avail)

> mb_internal_encoding("UTF-8");

Depends on your application and mbstring usage, usually bad choice.

> all not at the very beginning of my script, but before I queried the
> database and before I printed the results. I still keep getting
> 'wierd' characters.

1) Dump your DB to SQL
2) Convert the content from the former encoding to UTF-8 (eg. iconv)
3) Change MySQL metadata
4) Import the UTF-8 dump
5) Change DB wrapper code to negotiate UTF-8 as encoding (This is the 
point where a DB wrapper comes in handy, if you haven't noticed before).

[toc] | [prev] | [next] | [standalone]


#2214

From"Álvaro G. Vicario" <alvaro.NOSPAMTHANX@demogracia.com.invalid>
Date2011-06-17 13:23 +0200
Message-ID<itfdga$v0f$1@dont-email.me>
In reply to#2204
El 16/06/2011 23:34, Jo Schulze escribió/wrote:
>> mb_internal_encoding("UTF-8");
> Depends on your application and mbstring usage, usually bad choice.

Why exactly?

(I've found live systems where mb_internal_encoding defaulted to single 
byte encoding, thus effectively running multi-byte data. So it's nice to 
ensure it has a known value.)



-- 
-- http://alvaro.es - Álvaro G. Vicario - Burgos, Spain
-- Mi sitio sobre programación web: http://borrame.com
-- Mi web de humor satinado: http://www.demogracia.com
--

[toc] | [prev] | [standalone]


Back to top | Article view | comp.lang.php


csiph-web