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

  • 8
    It means I'd never consider using it. Feb 19, 2011 at 8:20
  • 1
    @dan_waterworth: +1 I don't agree but your answer made my day XD Feb 19, 2011 at 12:13

4 Answers 4


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, http://amazon.jp 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, http://facebook.jp 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.

  • 2
    Facebook is multilingual and is built in PHP. How is the lack of unicode problematic for them? Feb 19, 2011 at 8:03
  • Well perhaps PHP does support Unicode. I'm not the person who said it didn't.
    – Stephen C
    Feb 19, 2011 at 8:05
  • 10
    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. Feb 19, 2011 at 8:17
  • 6
    It's not that PHP (and other languages) can't support Unicode, they just do it poorly.
    – user7043
    Feb 19, 2011 at 11:35
  • 1
    @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, 2013 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.

  • 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. Oct 10, 2015 at 7:42
  • That is true. Sometimes it is. However, usually it is not. If you want to fetch each character from a string, if you want to fetch a substring, if you want to manipulate strings in many different ways, PHP will make it difficult unless the mb_ functions happen to work with your encoding. I think we need an alternative to PHP that works natively with utf-8, the web standard for strings in any human language. Jan 7, 2020 at 16:52
  • The thing is though that there is not a 1:1 mapping between unicode code points and what humans regard as characters. So even if you use strings of unicode code points, you still need a bunch of special case code if you want things to be 100% correct. Jan 7, 2020 at 17:48

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.


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.

  • 2
    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. Oct 10, 2015 at 14:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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