Sign up ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

How can the lack of Unicode support in PHP affect a PHP web app?

share|improve this question
It means I'd never consider using it. – dan_waterworth Feb 19 '11 at 8:20
@dan_waterworth: +1 I don't agree but your answer made my day XD – Federico Culloca Feb 19 '11 at 12:13

4 Answers 4

up vote 13 down vote accepted

Any website that purports to be multi-lingual or to deal with documents or content that is not representable in Latin-1 is likely to be problematic if you don't have Unicode support.

  • For example, would be toast without Unicode.

Another problematic use-case is when content might contain mathematical and other symbols.

However, your example of Facebook suggests that in fact you can in fact "do" Unicode in PHP. Alternatively, is not implemented in PHP. Either way, the home page says:

<meta http-equiv="Content-type" content="text/html; charset=utf-8" />

and has lots of UTF-8 content.

OK, here's what the PHP doc for "String" says:

"A string is series of characters, therefore, a character is the same as a byte. That is, there are exactly 256 different characters possible. This also implies that PHP has no native support of Unicode. See utf8_encode() and utf8_decode() for some basic Unicode functionality."

So PHP does have Unicode support. It is just that "native strings" are not Unicode based.

So what it means is that if you need to deal with any language (or set of languages) that cannot be encode in an 8-bit character set, your PHP code is going to be more cumbersome at any point where it needs to process content as (real) characters.

share|improve this answer
Facebook is multilingual and is built in PHP. How is the lack of unicode problematic for them? – Emanuil Rusev Feb 19 '11 at 8:03
Well perhaps PHP does support Unicode. I'm not the person who said it didn't. – Stephen C Feb 19 '11 at 8:05
PHP can certainly output unicode text - bytes are bytes, after all. PHP really doesnt care if you are sending a PNG image or UTF8 text. But PHP's string types and string functions wont necessarily work with unicode correctly. – GrandmasterB Feb 19 '11 at 8:17
It's not that PHP (and other languages) can't support Unicode, they just do it poorly. – delnan Feb 19 '11 at 11:35
@Bernard - I doubt that it is the kind of thing that can be addressed in a framework. The problem is that any code that you write "within the framework" that has to deal with character data has to do it in a unicode-aware way. If you are going to address this, it would need to be something like the configuration option mentioned by DoPPler. The change has to happen at the core language / interpreter level. – Stephen C May 23 '13 at 6:51

There are (at least) three different approaches to text in the modern programming world.

  1. treat text as a sequence of bytes. There is a widespread convention that byte values 0-127 represent ascii but what byte values 128-255 mean depends on the context. They may be characters in a single byte legacy character set, code units of a multibyte legacy character set or code units of UTF-8.

  2. treat text as a sequence of unicode code points.

  3. treat text as a sequence of UTF-16 code units.

In general a language and/or the libraries, APIs and protocols used with it encourage or even force a given approach.

php takes the first approach. A string is just a sequence of bytes, there is no special type for Unicode. Some would characterise this as "not supporting unicode" but I would consider that a mis-characterisation.

What is does mean is that if you are using php with utf-8 it is your responsibility to do so correctly. UTF-8 is a fairly well behaved encoding so you don't have to worry as much as you did with some legacy multibyte encodings but you still need to be careful about some operations. Especially truncation (don't want to cut in the middle of a multibyte sequence) and character counting (is a count of utf-8 code units acceptable for the given application or do you need to count code points or even something else). If you don't take responsibility for these things your users are likely to see glitches.

On the other hand it matches well with how internet protocols work. A system that works with strings as sequences of bytes can deal with internet data without encoding conversions. A system that works in seuences of code points or utf-16 code units must usually perform conversions of text going to/from the internet.

share|improve this answer
Elaboration: Even if your language of choice supports (or forces) a UTF-16 / UTF-32 / full-unicode-character string, it's your responsibility to make sure that's actually the right way to look at things. Surprise: Sometimes it actually is. – Deduplicator Oct 10 at 7:42

Actually php has methods to manipulate multi byte strings - please see mbstring. There is also a configuration option in php.ini to use mbstring replacements for most (all) of the string manipulation functions - for details on that please see mbstring overload.

share|improve this answer
Mbstring overloading should not be used, it is legacy functionality that may induce bugs in popular frameworks. Also, the intl extension contains another set of useful functionality, such as the Collator class for unicode-aware sorting. – Joeri Sebrechts Oct 10 at 14:03

It means that you have to take some shortcuts and do nasty tricks in order to get unicode. And that those tricks are going to make the code more cumbersome and less readable.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.