Comments on: How to use Unicode/UTF-8 in PHP properly (part 1)

By: AHSauge

AHSauge — Wed, 07 Jul 2010 22:18:35 +0000

Hi!

I’m not suprised that “set names” don’t work with MS Access, as it’s MySQL-spesific SQL. Unfortunatly, don’t know how it’s done with MS Access. The only tip I have is to look at the documentaton for Access and/or google it.

By: stylus

stylus — Wed, 07 Jul 2010 10:43:56 +0000

I am using ODBC(ms access), “set names ‘utf-8′”, not woking with odbc_exec()or odbc_do(),, how can i save ,update unicode data in access database .

Thank you,
Stylus

By: George Garchagudashvili

George Garchagudashvili — Wed, 23 Sep 2009 09:30:21 +0000

Very helpful, thanks too much…

By: Navigator

Navigator — Wed, 03 Jun 2009 10:12:46 +0000

Great article! Thanks!

By: Ziad Hilal

Ziad Hilal — Fri, 15 May 2009 20:32:43 +0000

Thanks for the great reply!

By: AHSauge

AHSauge — Sat, 02 May 2009 23:55:20 +0000

As far as I can see, PHP6 will definitely solve more or less all current problems with PHP and Unicode/UTF-8. It will provide top-to-bottom built-in support for Unicode (both UTF-8 and UTF-16) using Unicode-enabled versions of existing functions etc. and a new datatype for Unicode-strings. Though I too fear that it might take a while before it’s available at most hosting companies. The switching to PHP5 took years, and I fear we’ll be looking at similar times for PHP6 too, which basically means that we’re looking at years before you can assume your users have PHP6 available at their host. However, the Unicode semantics can be set to off as default in php.ini (and turned on at runtime), so the Unicode shouldn’t be that much of a problem for the hosts, but there are other changes in PHP 6 too … Hopefully some hosts might be sensible and default to PHP5 while also offering possibility to convert to a server with PHP6.

As for your question about htmlspecialchars: If and/or when you use it is up to you. From a performance point of view, it’s better to do it once before you store it instead of doing it multiple times afterwards (at each request), and I can’t see any benefits of doing it at each request vs. before storing. Any editing would require html entities for at least < and > anyway to prevent injection of malicious (X)HTML, and any entities will show up as normal characters in input and textareas even after using htmlspecialchars, so there’s no real drawback doing it before. As for the Unicode/UTF-8 side of it, there’s no difference from single byte charsets except that you have to add ‘UTF-8′ as the 3. parameter. Actually, stricly speaking, you don’t even need to add the paramter at all, as it’s only going to convert <> & ‘ and ” to entities which are all ASCII-characters anyway (which are stored the exact same way in UTF-8, hence ASCII-compatible).

PS: It’s worth noting that this does not apply for htmlentities which converts alot more than just those five characters, and in my opinion shouldn’t be used with Unicode/UTF-8 as it sort of defeats the point of using Unicode/UTF-8.

By: Ziad Hilal

Ziad Hilal — Sat, 02 May 2009 22:44:33 +0000

Great article, hopefully PHP 6 will solve most of these common unicode problems by switching to multibyte string functions. However, I can’t imagine the time it would take to get most hosting companies to update to version 6.

Here’s something I would like to know, when using unicode should we htmlspecialchars() the data before entering the database? Or leave data as is, and only htmlspecialchars() the output from the database?

I’m looking forward to your next article on this subject!

By: Oleg

Oleg — Tue, 14 Apr 2009 17:32:34 +0000

Thank’s a lot for the post. I’ve been coding (amateur-level) PHP since like 7-8 years, and I always had this encoding decoding problem. And I always had to invent something new That was such a shame