| blob | 88a48a7028a511a80cf4f4bc2068054e43148b48 |
6 <meta name="description" content="Describes the rationale for using UTF-8, the ramifications otherwise, and how to make the switch." />
9 .minor td {font-style:italic;}
10 </style>
14 <!-- Note to users: this document, though professing to be UTF-8, attempts
15 to use only ASCII characters, because most webservers are configured
16 to send HTML as ISO-8859-1. So I will, many times, go against my
17 own advice for sake of portability. -->
19 </head><body>
27 <p>Character encoding and character sets are not that
28 difficult to understand, but so many people blithely stumble
29 through the worlds of programming without knowing what to actually
31 experts." No, it is not! This document will walk you through
32 determining the encoding of your system and how you should handle
33 this information. It will stay away from excessive discussion on
34 the internals of character encoding.</p>
36 <p>This document is not designed to be read in its entirety: it will
37 slowly introduce concepts that build on each other: you need not get to
38 the bottom to have learned something new. However, I strongly
40 at that point you'd have made a conscious decision not to migrate,
41 which can be a rewarding (but difficult) task.</p>
46 interesting tidbits for the curious but not strictly necessary material to
47 do the tutorial. If you read this text, you'll come out
48 with a greater understanding of the underlying issues.</p>
49 </blockquote>
65 </ol></li>
68 </ol></li>
75 </ol></li>
78 </ol></li>
83 </ol></li>
89 </ol></li>
91 </ol></li>
93 </ol>
97 <p>In the beginning, there was ASCII, and things were simple. But they
98 weren't good, for no one could write in Cyrillic or Thai. So there
99 exploded a proliferation of character encodings to remedy the problem
100 by extending the characters ASCII could express. This ridiculously
101 simplified version of the history of character encodings shows us that
102 there are now many character encodings floating around.</p>
106 interpret raw zeroes and ones into real characters. It
107 usually does this by pairing numbers with characters.</p>
108 <p>There are many different types of character encodings floating
109 around, but the ones we deal most frequently with are ASCII,
111 <ul>
113 English alphabet.</li>
115 that add a potpourri of useful, non-standard characters
117 so usually only support one script at a time. When you
118 see a page on the web, chances are it's encoded in one
119 of these encodings.</li>
122 They go beyond 8-bits (the first two are variable length,
123 while the second one uses 16-bits), and support almost
124 every language in the world. UTF-8 is gaining traction
125 as the dominant international encoding of the web.</li>
126 </ul>
127 </blockquote>
129 <p>The first step of our journey is to find out what the encoding of
130 your website is. The most reliable way is to ask your
131 browser:</p>
133 <dl>
138 </dl>
140 <p>Internet Explorer won't give you the MIME (i.e. useful/real) name of the
141 character encoding, so you'll have to look it up using their description.
142 Some common ones:</p>
145 <thead><tr>
148 </tr></thead>
149 <tbody>
161 </tbody>
162 <tbody>
175 </tbody>
176 <tbody>
186 </tbody>
187 </table>
189 <p>Internet Explorer does not recognize some of the more obscure
190 character encodings, and having to lookup the real names with a table
191 is a pain, so I recommend using Mozilla Firefox to find out your
192 character encoding.</p>
197 encoding?" Well, as it turns out, there are multiple places where
198 a web developer can specify a character encoding, and one such place
201 <pre><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /></pre>
205 encoding: the HTML claims to be this encoding, but whether or not this
206 is actually the case depends on other factors. For now, take note
209 <ol>
210 <li>The character encoding is the same as the one reported by the
211 browser,</li>
214 </ol>
225 savvy! You can skip this section. If they don't...</p>
229 <p>If this is the case, you'll want to add in the appropriate
231 the code snippet above and replacing UTF-8 with whatever is the mime name
232 of your real encoding.</p>
235 <p>For all those skeptics out there, there is a very good reason
236 why the character encoding should be explicitly stated. When the
237 browser isn't told what the character encoding of a text is, it
238 has to guess: and sometimes the guess is wrong. Hackers can manipulate
239 this guess in order to slip XSS past filters and then fool the
240 browser into executing it as active code. A great example of this
243 <p>You might be able to get away with not specifying a character
245 sends the right Content-Type header, but why risk it? Besides, if
246 the user downloads the HTML file, there is no longer any webserver
247 to define the character encoding.</p>
248 </blockquote>
252 <p>This is an extremely common mistake: another source is telling
253 the browser what the
254 character encoding is and is overriding the embedded encoding. This
255 source usually is the Content-Type HTTP header that the webserver (i.e.
256 Apache) sends. A usual Content-Type header sent with a page might
257 look like this:</p>
261 <p>Notice how there is a charset parameter: this is the webserver's
262 way of telling a browser what the character encoding is, much like
266 designed as a substitute for the HTTP header for contexts where
267 sending headers is impossible (such as locally stored files without
269 </p></blockquote>
272 tag to match the HTTP header, or changing the HTTP header to match
274 on the website's content: after all, headers and tags are only ways of
275 describing the actual characters on the web page.</p>
279 <dl>
281 <dd>Either way is fine, but I recommend switching both to
283 <dt>...uses special characters, and they display
284 properly,</dt>
286 <dt>...uses special characters, but users often complain that
287 they come out garbled,</dt>
289 </dl>
291 <p>Changing a META tag is easy: just swap out the old encoding
292 for the new. Changing the server (HTTP header) encoding, however,
293 is slightly more difficult.</p>
299 <p>The simplest way to handle this problem is to send the encoding
300 yourself, via your programming language. Since you're using HTML
301 Purifier, I'll assume PHP, although it's not too difficult to do
302 similar things in
306 <pre><a href="http://php.net/function.header">header</a>('Content-Type:text/html; charset=UTF-8');</pre>
309 This code must come before any output, so be careful about
310 stray whitespace in your application (i.e., any whitespace before
315 <p>PHP also has a neat little ini directive that can save you a
316 header call: <code><a href="http://php.net/ini.core#ini.default-charset">default_charset</a></code>. Using this code:</p>
320 <p>...will also do the trick. If PHP is running as an Apache module (and
321 not as FastCGI, consult
322 <a href="http://php.net/phpinfo">phpinfo</a>() for details), you can even use htaccess to apply this property
323 across many PHP files:</p>
325 <pre><a href="http://php.net/configuration.changes#configuration.changes.apache">php_value</a> default_charset "UTF-8"</pre>
328 also go in your php.ini file. Some hosting providers allow you to customize
329 your own php.ini file, ask your support for details. Use:</p>
334 <p>You may, for whatever reason, need to set the character encoding
335 on non-PHP files, usually plain ol' HTML files. Doing this
336 is more of a hit-or-miss process: depending on the software being
337 used as a webserver and the configuration of that software, certain
338 techniques may work, or may not work.</p>
342 <p>On Apache, you can use an .htaccess file to change the character
343 encoding. I'll defer to
345 for the in-depth explanation, but it boils down to creating a file
346 named .htaccess with the contents:</p>
348 <pre><a href="http://httpd.apache.org/docs/1.3/mod/mod_mime.html#addcharset">AddCharset</a> UTF-8 .html</pre>
351 use and .html is a file extension that this will be applied to. This
352 character encoding will then be set for any file directly in
353 or in the subdirectories of directory you place this file in.</p>
357 <pre><a href="http://httpd.apache.org/docs/1.3/mod/core.html#adddefaultcharset">AddDefaultCharset</a> UTF-8</pre>
359 <p>...which changes the character set Apache adds to any document that
360 doesn't have any Content-Type parameters. This directive, which the
362 reasons, is probably why your headers mismatch
364 butting in on your character encodings, you can tell it not
365 to send anything at all:</p>
367 <pre><a href="http://httpd.apache.org/docs/1.3/mod/core.html#adddefaultcharset">AddDefaultCharset</a> Off</pre>
370 the sole source of character encoding
373 text before them is ASCII.</p>
376 placed in httpd.conf file for Apache, but
377 in most shared hosting situations you won't be able to edit this file.
378 </p></blockquote>
382 <p>If you're not allowed to use .htaccess files, you can often
383 piggy-back off of Apache's default AddCharset declarations to get
384 your files in the proper extension. Here are Apache's default
385 character set declarations:</p>
388 <thead><tr>
391 </tr></thead>
392 <tbody>
419 </tbody>
420 </table>
424 attached, the difference being that if there is an
427 from right to left). By default, Apache has no such declaration.</p>
431 <p>If anyone can contribute information on how to configure Microsoft
432 IIS to change character encodings, I'd be grateful.</p>
437 encodings, but they can also come from somewhere else: XML
438 Declarations. They look like:</p>
444 <p>For XHTML, this XML Declaration theoretically
446 XHTML is actually served as legit XML and not HTML, which is almost always
447 never due to Internet Explorer's lack of support for
452 <p>For XML, however, this XML Declaration is extremely important.
453 Since most webservers are not configured to send charsets for .xml files,
454 this is the only thing a parser has to go on. Furthermore, the default
455 for XML files is UTF-8, which often butts heads with more common
458 <p>In short, if you use XHTML and have gone through the
459 trouble of adding the XML Declaration, make sure it jives
461 if served in text/html) and HTTP headers.</p>
465 <p>This section is not required reading,
466 but may answer some of your questions on what's going on in all
467 this character encoding hocus pocus. If you're interested in
468 moving on to the next phase, skip this section.</p>
470 <p>A logical question that follows all of our wheeling and dealing
471 with multiple sources of character encodings is "Why are there
472 so many options?" To answer this question, we have to turn
473 back our definition of character encodings: they allow a program
474 to interpret bytes into human-readable characters.</p>
476 <p>Thus, a chicken-egg problem: a character encoding
477 is necessary to interpret the
481 if we don't know it's character encoding? And how do we figure out
482 the character encoding, if we don't know the contents of the
485 <p>Fortunantely for us, the characters we need to write the
487 over every character encoding that is in common use today. So,
488 all the web-browser has to do is parse all the way down until
489 it gets to the Content-Type tag, extract the character encoding
490 tag, then re-parse the document according to this new information.</p>
492 <p>Obviously this is complicated, so browsers prefer the simpler
493 and more efficient solution: get the character encoding from a
494 somewhere other than the document itself, i.e. the HTTP headers,
495 much to the chagrin of HTML authors who can't set these headers.</p>
499 <p>So, you've gone through all the trouble of ensuring that your
500 server and embedded characters all line up properly and are
501 present. Good job: at
502 this point, you could quit and rest easy knowing that your pages
503 are not vulnerable to character encoding style XSS attacks.
504 However, just as having a character encoding is better than
505 having no character encoding at all, having UTF-8 as your
506 character encoding is better than having some other random
507 character encoding, and the next step is to convert to UTF-8.
508 But why?</p>
512 <p>Many software projects, at one point or another, suddenly realize
513 that they should be supporting more than one language. Even regular
514 usage in one language sometimes requires the occasional special character
515 that, without surprise, is not available in your character set. Sometimes
516 developers get around this by adding support for multiple encodings: when
517 using Chinese, use Big5, when using Japanese, use Shift-JIS, when
518 using Greek, etc. Other times, they use character references with great
519 zeal.</p>
522 measures. After getting the system to use UTF-8 and adjusting for
523 sources that are outside the hand of the browser (more on this later),
524 UTF-8 just works. You can use it for any language, even many languages
525 at once, you don't have to worry about managing multiple encodings,
526 you don't have to use those user-unfriendly entities.</p>
531 a special character outside of their scope often will use a character
532 entity reference to achieve the desired effect. For instance, θ can be
534 support of Greek letters.</p>
536 <p>This works nicely for limited use of special characters, but
537 say you wanted this sentence of Chinese text: 激光,
538 這兩個字是甚麼意思.
539 The ampersand encoded version would look like this:</p>
541 <pre>&#28608;&#20809;, &#36889;&#20841;&#20491;&#23383;&#26159;&#29978;&#40636;&#24847;&#24605;</pre>
543 <p>Extremely inconvenient for those of us who actually know what
544 character entities are, totally unintelligible to poor users who don't!
547 uninterested in learning HTML scratching their heads. On the other
548 hand, if they see θ in an edit box, they'll know that it's a
549 special character, and treat it accordingly, even if they don't know
550 how to write that character themselves.</p>
554 when it became far to cumbersome to support foreign languages. Bots
555 will now actually go through articles and convert character entities
556 to their corresponding real characters for the sake of user-friendliness
557 and searchability. See
559 page on special characters</a> for more details.
560 </p></blockquote>
565 with characters that our outside of their character set? Rather than
566 discuss what UTF-8 does right, we're going to show what could go wrong
567 if you didn't use UTF-8 and people tried to use characters outside
568 of your character encoding.</p>
570 <p>The troubles are large, extensive, and extremely difficult to fix (or,
571 at least, difficult enough that if you had the time and resources to invest
572 in doing the fix, you would be probably better off migrating to UTF-8).
575 which may be used by POST, and is required when you want to upload
576 files.</p>
578 <p>The following is a summarization of notes from
579 <a href="http://web.archive.org/web/20060427015200/ppewww.ph.gla.ac.uk/~flavell/charset/form-i18n.html">
581 of useful information, but is written in a rambly manner, so
582 here I try to get right to the point. (Note: the original has
583 disappeared off the web, so I am linking to the Web Archive copy.)</p>
587 <p>This is the Content-Type that GET requests must use, and POST requests
588 use by default. It involves the ubiquituous percent encoding format that
590 determining the character encoding of such a request, since the percent
591 encoding operates on a byte level, so it is usually assumed that it
592 is the same as the encoding the page containing the form was submitted
593 in. You'll run into very few problems if you only use characters in
594 the character encoding you chose.</p>
596 <p>However, once you start adding characters outside of your encoding
597 (and this is a lot more common than you may think: take curly
599 a whole manner of strange things start to happen. Depending on the
600 browser you're using, they might:</p>
602 <ul>
606 <li>Send it anyway as a different character encoding mixed in
607 with the original encoding (usually Windows-1252 rather than
609 </ul>
611 <p>To properly guard against these behaviors, you'd have to sniff out
612 the browser agent, compile a database of different behaviors, and
613 take appropriate conversion action against the string (disregarding
614 a spate of extremely mysterious, random and devastating bugs Internet
615 Explorer manifests every once in a while). Or you could
616 use UTF-8 and rest easy knowing that none of this could possibly happen
621 <p>Multipart form submission takes away a lot of the ambiguity
622 that percent-encoding had: the server now can explicitly ask for
623 certain encodings, and the client can explicitly tell the server
624 during the form submission what encoding the fields are in.</p>
626 <p>There are two ways you go with this functionality: leave it
627 unset and have the browser send in the same encoding as the page,
628 or set it to UTF-8 and then do another conversion server-side.
629 Each method has deficiencies, especially the former.</p>
631 <p>If you tell the browser to send the form in the same encoding as
632 the page, you still have the trouble of what to do with characters
633 that are outside of the character encoding's range. The behavior, once
634 again, varies: Firefox 2.0 converts them to character entity references
635 while Internet Explorer 7.0 mangles them beyond intelligibility. For
636 serious internationalization purposes, this is not an option.</p>
639 begs the question: Why aren't you using UTF-8 for everything then?
640 This route is more palatable, but there's a notable caveat: your data
641 will come in as UTF-8, so you will have to explicitly convert it into
642 your favored local character encoding.</p>
644 <p>I object to this approach on idealogical grounds: you're
645 digging yourself deeper into
646 the hole when you could have been converting to UTF-8
647 instead. And, of course, you can't use this method for GET requests.</p>
652 support: the number of troublesome cases can be counted with the
653 fingers of one hand, and these browsers usually have trouble with
654 other character encodings too. Problems users usually encounter stem
655 from the lack of appropriate fonts to display the characters (once
656 again, this applies to all character encodings and HTML entities) or
657 Internet Explorer's lack of intelligent font picking (which can be
658 worked around).</p>
660 <p>We will go into more detail about how to deal with edge cases in
661 the browser world in the Migration section, but rest assured that
662 converting to UTF-8, if done correctly, will not result in users
663 hounding you about broken pages.</p>
667 <p>And finally, we get to HTML Purifier. HTML Purifier is built to
668 deal with UTF-8: any indications otherwise are the result of an
669 encoder that converts text from your preferred encoding to UTF-8, and
670 back again. HTML Purifier never touches anything else, and leaves
671 it up to the module iconv to do the dirty work.</p>
673 <p>This approach, however, is not perfect. iconv is blithely unaware
674 of HTML character entities. HTML Purifier, in order to
675 protect against sophisticated escaping schemes, normalizes all character
676 and numeric entitie references before processing the text. This leads to
677 one important ramification:</p>
679 <p><strong>Any character that is not supported by the target character
680 set, regardless of whether or not it is in the form of a character
681 entity reference or a raw character, will be silently ignored.</strong></p>
684 in your HTML, but the output is in Latin-1 (which, understandably,
685 does not understand Greek), the following process will occur (assuming you've
686 set the encoding correctly using %Core.Encoding):</p>
688 <ul>
690 (note that theta is preserved here since it doesn't actually use
693 character entities to their corresponding raw UTF-8 equivalents:
698 will be either ignored or replaced with a question mark:
700 </ul>
702 <p>This behaviour is quite unsatisfactory. It is a deal-breaker for
703 international applications, and it can be mildly annoying for the provincial
704 soul who occasionally needs a special character. Since 1.4.0, HTML
705 Purifier has provided a slightly more palatable workaround using
706 %Core.EscapeNonASCIICharacters. The process now looks like:</p>
708 <ul>
715 original (which is strictly unnecessary for 99% of encodings
717 </ul>
719 <p>...which means that this is only good for an occasional foray into
720 the land of Unicode characters, and is totally unacceptable for Chinese
721 or Japanese texts. The even bigger kicker is that, supposing the
723 theta, the character would get converted into a character entity reference
724 anyway! (The Encoder does not discriminate).</p>
726 <p>The current functionality is about where HTML Purifier will be for
727 the rest of eternity. HTML Purifier could attempt to preserve the original
728 form of the character references so that they could be substituted back in, only the
729 DOM extension kills them off irreversibly. HTML Purifier could also attempt
730 to be smart and only convert non-ASCII characters that weren't supported
731 by the target encoding, but that would require reimplementing iconv
732 with HTML awareness, something I will not do.</p>
735 not being sarcastic here: some people could care less about other languages).</p>
740 Note that this is not for the faint-hearted, and you should expect
741 the process to take longer than you think it will take.</p>
744 and then you set all the headers and META tags we discussed earlier
745 to UTF-8. There are many ways going about doing this: you could
746 write a conversion script that runs through the database and re-encodes
747 everything as UTF-8 or you could do the conversion on the fly when someone
748 reads the page. The details depend on your system, but I will cover
749 some of the more subtle points of migration that may trip you up.</p>
753 <p>Most modern databases, the most prominent open-source ones being MySQL
754 4.1+ and PostgreSQL, support character encodings. If you're switching
755 to UTF-8, logically speaking, you'd want to make sure your database
756 knows about the change too. There are some caveats though:</p>
760 <p>Standardization in terms of SQL syntax for specifying character
761 encodings is notoriously spotty. Refer to your respective database's
762 documentation on how to do this properly.</p>
764 <p>For <a href="http://dev.mysql.com/doc/refman/5.0/en/charset-conversion.html">MySQL</a>, <code>ALTER</code> will magically perform the
765 character encoding conversion for you. However, you have
766 to make sure that the text inside the column is what is says it is:
768 the text when you try to convert it to UTF-8. You'll have to convert
769 it to a binary field, convert it to a Shift-JIS field (the real encoding),
770 and then finally to UTF-8. Many a website had pages irreversibly mangled
771 because they didn't realize that they'd been deluding themselves about
772 the character encoding all along, don't become the next victim.</p>
774 <p>For <a href="http://www.postgresql.org/docs/8.2/static/multibyte.html">PostgreSQL</a>, there appears to be no direct way to change the
775 encoding of a database (as of 8.2). You will have to dump the data, and then reimport
776 it into a new table. Make sure that your client encoding is set properly:
777 this is how PostgreSQL knows to perform an encoding conversion.</p>
780 the new column. Collation is how a DBMS sorts text, like ordering
781 B, C and A into A, B and C (the problem gets surprisingly complicated
782 when you get to languages like Thai and Japanese). If in doubt,
783 going with the default setting is usually a safe bet.</p>
785 <p>Once the conversion is all said and done, you still have to remember
786 to set the client encoding (your encoding) properly on each database
788 usually supported).</p>
792 <p>Due to the abovementioned compatibility issues, a more interoperable
793 way of storing UTF-8 text is to stuff it in a binary datatype.
796 Doing so can save you some huge headaches:</p>
798 <ul>
803 which represent characters beyond the basic multilingual
804 plane, and</li>
805 <li>You will never have to worry about your DBMS being too smart
806 and attempting to convert your text when you don't want it to.</li>
807 </ul>
809 <p>MediaWiki, a very prominent international application, uses binary fields
810 for storing their data because of point three.</p>
814 <ul>
815 <li>Database tools like PHPMyAdmin won't be able to offer you inline
816 text editing, since it is declared as binary,</li>
817 <li>It's not semantically correct: it's really text not binary
818 (lying to the database),</li>
819 <li>Unless you use the not-very-portable wizardry mentioned above,
820 you have to change the encoding yourself (usually, you'd do
821 it on the fly), and</li>
823 </ul>
829 <p>For more flat-file oriented systems, you will often be tasked with
830 converting reams of existing text and HTML files into UTF-8, as well as
831 making sure that all new files uploaded are properly encoded. Once again,
832 I can only point vaguely in the right direction for converting your
833 existing files: make sure you backup, make sure you use
835 make sure you know what the original character encoding of the files
836 is (or are, depending on the tidiness of your system).</p>
838 <p>However, I can proffer more specific advice on the subject of
839 text editors. Many text editors have notoriously spotty Unicode support.
840 To find out how your editor is doing, you can check out <a
842 or <a href="http://en.wikipedia.org/wiki/Comparison_of_text_editors#Encoding_support">Wikipedia's list.</a>
843 I personally use Notepad++, which works like a charm when it comes to UTF-8.
845 (usually Save as or Format) what encoding you want it to use. An editor
847 ambiguous. Make sure you know whether or not they really mean UTF-8
850 <p>The two things to look out for are whether or not the editor
853 Font mixing is important because fonts rarely have support for every
854 language known to mankind: in order to be flexible, an editor must
855 be able to take a little from here and a little from there, otherwise
856 all your Chinese characters will come as nice boxes. We'll discuss
857 BOM below.</p>
862 Order Mark</a>, is a magical, invisible character placed at
863 the beginning of UTF-8 files to tell people what the encoding is and
864 what the endianness of the text is. It is also unnecessary.</p>
866 <p>Because it's invisible, it often
867 catches people by surprise when it starts doing things it shouldn't
868 be doing. For example, this PHP file:</p>
871 header('Location: index.php');
875 PHP error. And because the BOM is invisible, this culprit will go unnoticed.
876 My suggestion is to only use ASCII in PHP pages, but if you must, make
877 sure the page is saved WITHOUT the BOM.</p>
881 which are sent to the browser before any HTML to tell it various
882 information. The moment any regular text (and yes, a BOM counts as
883 ordinary text) is output, the headers must be sent, and you are
884 not allowed to send anymore. Thus, the error.</p>
885 </blockquote>
887 <p>If you are reading in text files to insert into the middle of another
888 page, it is strongly advised (but not strictly necessary) that you replace out the UTF-8 byte
890 via:</p>
896 <p>Generally speaking, people who are having trouble with fonts fall
897 into two categories:</p>
899 <ul>
900 <li>Those who want to
901 use an extremely obscure language for which there is very little
902 support even among native speakers of the language, and</li>
903 <li>Those where the primary language of the text is
904 well-supported but there are occasional characters
905 that aren't supported.</li>
906 </ul>
908 <p>Yes, there's always a chance where an English user happens across
909 a Sinhalese website and doesn't have the right font. But an English user
910 who happens not to have the right fonts probably has no business reading Sinhalese
911 anyway. So we'll deal with the other two edge cases.</p>
915 <p>If you run a Bengali website, you may get comments from users who
916 would like to read your website but get heaps of question marks or
917 other meaningless characters. Fixing this problem requires the
918 installation of a font or language pack which is often highly
919 dependent on what the language is. <a href="http://bn.wikipedia.org/wiki/%E0%A6%89%E0%A6%87%E0%A6%95%E0%A6%BF%E0%A6%AA%E0%A7%87%E0%A6%A1%E0%A6%BF%E0%A6%AF%E0%A6%BC%E0%A6%BE:Bangla_script_display_help">Here is an example</a>
920 of such a help file for the Bengali language, I am sure there are
921 others out there too. You just have to point users to the appropriate
922 help file.</p>
926 <p>A prime example of when you'll see some very obscure Unicode
927 characters embedded in what otherwise would be very bland ASCII are
928 letters of the
930 Phonetic Alphabet (IPA)</a>, use to designate pronounciations in a very standard
931 manner (you probably see them all the time in your dictionary). Your
932 average font probably won't have support for all of the IPA characters
934 So what's a poor browser to do? Font mix! Smart browsers like Mozilla Firefox
935 and Internet Explorer 7 will borrow glyphs from other fonts in order
936 to make sure that all the characters display properly.</p>
938 <p>But what happens when the browser isn't smart and happens to be the
939 most widely used browser in the entire world? Microsoft IE 6
940 is not smart enough to borrow from other fonts when a character isn't
941 present, so more often than not you'll be slapped with a nice big �.
942 To get things to work, MSIE 6 needs a little nudge. You could configure it
943 to use a different font to render the text, but you can acheive the same
944 effect by selectively changing the font for blocks of special characters
945 to known good Unicode fonts.</p>
947 <p>Fortunantely, the folks over at Wikipedia have already done all the
948 heavy lifting for you. Get the CSS from the horses mouth here:
951 other classes you can use for other purposes, check out
952 <a href="http://meta.wikimedia.org/wiki/Help:Special_characters#Displaying_Special_Characters">this page</a>
953 for more details. For you lazy ones, this should work:</p>
955 <pre>.Unicode {
961 font-family /**/:inherit; /* resets fonts for everyone but IE6 */
962 }</pre>
967 usually don't need to be fixed, but for anything else you probably
968 want to play it safe. Unless, of course, you don't care about IE6
969 users.</p>
973 <p>When people claim that PHP6 will solve all our Unicode problems, they're
974 misinformed. It will not fix any of the abovementioned troubles. It will,
975 however, fix the problem we are about to discuss: processing UTF-8 text
976 in PHP.</p>
979 notable exceptions). Sometimes, this will cause problems, other times,
980 this won't. So far, we've avoided discussing the architecture of
982 and yes, it is variable width. Other traits:</p>
984 <ul>
985 <li>Every character's byte sequence is unique and will never be found
986 inside the byte sequence of another character,</li>
991 </ul>
993 <p>Each of these traits affect different domains of text processing
994 in different ways. It is beyond the scope of this document to explain
995 what precisely these implications are. PHPWact provides
997 on what to expect from each function, although coverage is spotty in
998 some areas. Their more general notes on
1000 are also worth looking at for information on UTF-8. Some rules of thumb
1001 when dealing with Unicode text:</p>
1003 <ul>
1007 </ul></li>
1009 <li>...count characters (strlen will return bytes, not characters;
1010 str_split and word_wrap may corrupt)</li>
1013 </ul></li>
1014 </ul>
1017 a string that you are 100% sure is ASCII, be my guest and use
1020 <p>Regardless, always think in bytes, not characters. If you use strpos()
1021 to find the position of a character, it will be in bytes, but this
1022 usually won't matter since substr() also operates with byte indices!</p>
1025 probably need replacements for some of these functions. I recommend
1028 also defines a few useful UTF-8 compatible functions: check out
1030 directory.</p>
1034 <p>Well, that's it. Hopefully this document has served as a very
1035 practical springboard into knowledge of how UTF-8 works. You may have
1036 decided that you don't want to migrate yet: that's fine, just know
1037 what will happen to your output and what bug reports you may recieve.</p>
1039 <p>Many other developers have already discussed the subject of Unicode,
1040 UTF-8 and internationalization, and I would like to defer to them for
1041 a more in-depth look into character sets and encodings.</p>
1043 <ul>
1045 The Absolute Minimum Every Software Developer Absolutely,
1046 Positively Must Know About Unicode and Character Sets
1048 good high-level look at Unicode and character sets in general.</li>
1050 provides a lot of useful details into the innards of UTF-8, although
1051 it may be a little off-putting to people who don't know much
1052 about Unicode to begin with.</li>
1053 </ul>
1055 </body>
1056 </html>