Take the 2-minute tour ×

Hey everybody. I'm developing a new site (php5/mySQL) and am looking to finally get on the Unicode bandwagon. I'll admit to knowing next to absolutely nothing about supporting Unicode at the moment, but I'm hoping to resolve that with your help.

After desperately flexing my tiny, pathetic excuses for Googlefu-muscles, and scouring over each page that looked promising to my Unicode-newbie eyes, I have come to the conclusion that, while not entirely supported, my precious language of choice (PHP for those that have forgotten) has made at least a half-assed attempt at managing the foreign beast (and from what else I see, succeeding?). I have also come to the conclusion that


is a great place to start and that I should be looking into supporting UTF-8 since I have plenty of space on my (shared, for the moment) hosting.

However, I'm not sure what this strange functionality known as mb_* means or how to incorporate it into functions such as strlen() and . . . to be honest at this point I don't know what other functionality (that I can't live without) is affected.

So I've come to you SO-ites in search of enlightenment and possibly straightening out my confused (where Unicode is concerned!) brain. I really want to support it but I need serious help.

P.S.: Does Unicode affect mysql_real_escape_string() or any other XSS prevention/security measures? I need to stay on top of this as well!

Thanks ahead of time.

  • Adding Javascript into the mix, since I'll be using a mix of pure and jQuery and no knowing about Unicode support + this language. ;)
share|improve this question
+1 for asking the questions that too few ask. Unicode is something every programmer should understand. –  Thanatos Jan 18 '11 at 2:59
Not to mention PHP and unicode isn't very straightforward –  GWW Jan 18 '11 at 3:03
Focus on understanding character sets, character encodings, a little binary. This is pretty language independent stuff. Once you start to get a grip on it, you'll realize php's "shortcomings" aren't really a big deal. –  rambo coder Jan 18 '11 at 3:14
@chris: I'm sorry, but I'm not really sure I understand. I'm looking for supporting Unicode in PHP (specifically through UTF-8 since like I said I'm not worried about space but don't need UTF-32). I know it requires "odd" things to work properly, but I'm not sure what all "odd" defines, like what mb_* 'replaces' (thank you etranger). –  Zydeco Jan 18 '11 at 3:24
My bad. The purpose of my comment was that I feel the most important thing in order to support unicode is to understand the things I listed, and not so much php specifics of unicode support. –  rambo coder Jan 18 '11 at 3:34
show 3 more comments

3 Answers

up vote 5 down vote accepted
  1. Welcome onboard utf8 :)
  2. You should simply use mb_* functions in place of your traditional str* functions
  3. MySQL and its API has long and well been supporting utf8, the only requirement that you use encoding when saving data and connecting. google for 'SET NAMES utf8'
  4. Note the 'u' modifier for preg_* functions that tells them to use unicode mode.
share|improve this answer
PS Your source code files should be utf8 WITHOUT BOM, because it makes output before PHP even starts and causes painfully strange "Headers already sent" issues. –  Dennis Kreminsky Jan 18 '11 at 3:08
1) Thank you very much. I'm happy to be here. :) 2) Is there any "cheat sheet" type place that lists them, or a place that shows how-to? (PHP's manual erm, well, pretty much lost me). 3) I did find that much out at least, and how to store in UTF-8. 4) '/u', right? 5) I use Notepad++ running in Wine, so to respond to your response I select "UTF-8 without BOM" and that should solve the source code file? -Also, I'm sorry this is a mess of a reply. I'm kind of new to responding here and don't know if there's anyway to newline since pressing the Enter key seems to send my comments along their way. –  Zydeco Jan 18 '11 at 3:17
2) sorry, never had any, original php documentation was good enough for me 4) yup! 5) yes, sounds right. BTW, I'm not even sure that comments on SO support line breaks at all :) –  Dennis Kreminsky Jan 18 '11 at 3:25
Hm. So mb_* is a replacement for any byte (or character)-specific function in that it supports multi-byte characters (Unicode!), right? This leaves my question of security and whether anything changes there, like mysql_real_escape_string() (probably doesn't) or htmlentities() (does it?). And, of course, if there's anything else that I haven't discovered that I need to know. –  Zydeco Jan 18 '11 at 4:25
you are correct about mb_*; mb stands for mbstring, a multibyte strings extension. mysql_real_escape_string() uses the same encoding as database connection, so as long as you connect as utf8, you're safe. as far as htmlentities, can't really confirm reliability, as it has had issues with cyrillics (which was my reason behind using utf8 in the first place) –  Dennis Kreminsky Jan 18 '11 at 4:27
show 5 more comments

When working with unicode:

  • use <meta content="text/html; charset=utf-8" http-equiv="Content-Type" /> on top of your page when you output
  • right after you connect to your database use the sql query: mysql_query("set names 'utf8'");
  • make sure all tables and required fields have a collation type of: 'utf8_unicode_ci'
share|improve this answer
I was under the impression that a combination of proper doctype and html tag did a better job than the meta. Can someone clarify that for me? And as far as connecting to the database, I thought that if the page itself was encoded UTF-8 and the database was UTF-8, all was well there? –  Zydeco Jan 18 '11 at 4:47
I have used the above combination to make things work. I also found the 'mysql_query("set names 'utf8'")' necessary. As for proper doctype vs meta question do consult an expert. –  Imran Omar Bukhsh Jan 18 '11 at 5:16
why the down vote?? –  Imran Omar Bukhsh Jan 26 '11 at 15:27
I don't know who did it, but it wasn't me. –  Zydeco Jan 27 '11 at 3:43
add comment

Your Answer


