A conversion table is a very simple concept. In PHP, it's also very simple to implement.

Editor's note: This article is an excerpt from You Want to Do WHAT with PHP?, a new book from MC Press.

Computers know nothing about language. Actually, when you get right down to it, they know nothing of numbers either. All that computers know is on and off. They can change the ons and offs based on other ons and offs. If certain ons are on, the processor will do one thing; if they are off, it will do another. A computer is perfectly happy with this arrangement.

However, the purpose of a computer is to do work for a human. A computer is a machine whose purpose is to make a human's job easier (or enable a human to blow up zombies, for that matter). That means that the computer has a problem: it doesn't know how to talk to the human in its own language. For this reason, humans needed to teach computers how to talk with them.

In the early days, this task was quite simple. Given that computers were basically created in the English-speaking part of the world, English was a natural choice to provide the interface so that humans and computers could talk. However, if you were to read through some of the mainframe program calls, it would be apparent that some give and take took place in both directions; the commands that the humans gave the system are actually quite cryptic, unless you know the language.

The reason for this is the limitation of resources. In the early days of computing, every bit was sacred. Every bit was great. And so we started with what is called the American Standard Code for Information Interchange, or ASCII as we now know it. ASCII is a 7-bit code that gave developers more than enough room to handle the 26 characters of the English alphabet plus some punctuation, special characters, and control characters. All told, 127 options for managing data.

At its most basic level, a character set is a translation for the computer. It translates the numbers that the computer stores into graphical characters. A computer cannot store a letter, but it can store a numeric representation of that letter. The character set defines the standard of translation between the number and the graphical character.

For example, you cannot store the letter "A" on a computer. A computer doesn't really know numbers, and it really doesn't know letters. But numbers can have binary representations. You could also have a binary representation of a letter, but it would conflict with the binary representation of a number. Say you had the number 12 and you wanted to add 4 to it. Would that be the number 4 or the letter "d"?

So, a computer's primary method of communication is via numbers, and the character set is the mapping between the numbers, which the computer is able to work with, and the human. And thus the communication problem between computer and human is solved, right? Not exactly.

In the early days of computing, ASCII was not as prevalent as it is today. A competitor was Extended Binary Coded Decimal Interchange Code, or EBCDIC. Written on the IBM System/360, EBCDIC became quite common due to the popularity of that system.

With that (and other situations like it), character encoding issues arose. Why? Remember that a letter is just a certain number. In ASCII, the number for the letter "A" is 65. In EBCDIC, the number for the letter A is 193. Why the difference? I have heard from some IBM i (the IBM midrange integrated system) people that EBCDIC was good for punch cards because the way the bits were laid out made for more durable cards.

Before the Web-based whippersnappers (I count myself part of this crowd) go off on this, remember that modern computer science is a very new endeavor. The problems that people in the 1950s and 1960s had to solve were basically the same, but different limitations applied. The first commercially available microprocessor, the Intel 4004, was a 4-bit machine that debuted in 1971. Both ASCII and EBCDIC were available in 1963, eight years earlier. In other words, punch cards were a necessary step for us to get to the point where we are today.

But the problem of how to represent characters remains, and that is where character set conversion comes into play. Imagine that you have one system, an IBM mainframe, that started its life in the 1960s and has been upgraded through the years, first to a System/390 and then to a System i or System z. You may have some applications that continue to use EBCDIC, but you run on a computer that uses ASCII as its default character set, and you need to read from the older computer.

To illustrate the problem, let's take a look at what an EBCDIC-encoded "hello world" looks like. Figure 3.1 shows this PHP code.

$str = pack( 'CCCCCCCCCCC',

       0x88, 0x85, 0x93, 0x93, 0x96, 0x40, 0xa6, 0x96,

       0x99, 0x93, 0x84

);

echo $str;

Figure 3.1: EBCDIC-encoded character string

Remember that a character encoding is just a sequence of numbers, but each individual number represents an individual character. When we run the preceding code, we get something a little different from what we intended:

ˆ…""–@¦–™"„

The reason for this is simple. My browser understands ASCII, and according to ASCII, those are the characters I asked it to print out. To show this, let's change the code to its ASCII representation (Figure 3.2).

$str = pack( 'CCCCCCCCCCC',

       0x68, 0x65, 0x6c, 0x6c, 0x6f, 0x20, 0x77,0x6f,

       0x72, 0x6c, 0x64

);

echo $str;

Figure 3.2: ASCII-encoded character string

The code looks the same, except with different numbers. But when we print it out in the browser, we get a different result:

hello world

The question, then, is how do we get something that was returned to us in EBCDIC to display properly on a browser that does not support it? You typically do this with some kind of character set conversion. All the character set conversion does is change the numbers in a string of one character set to the numbers in the string of the other character set that matches the letter. This is usually done using a conversion table.

A conversion table is a very simple concept. In PHP, it's also very simple to implement. You basically have a numerical array of all characters that are convertible, starting at zero. Then, for each numerical key of the array, you have the corresponding value in the other character set that represents the same letter. So, for example, in ASCII the ordinal for the letter "h" is 0x68, or 104. In EBCDIC, the letter "h" is 0x88 or 136. So, basically, the conversion table for EBCDIC to ASCII will have, at key number 136, the number 104.

Figure 3.3 shows an EBCDIC-to-ASCII character converter.

$table = array(

       0x00, 0x10, 0x20, 0x30, 0x00, 0x90, 0x00, 0x7f,

       0x00, 0x00, 0x00, 0xb0, 0xc0, 0xd0, 0xe0, 0xf0,

       0x10, 0x11, 0x12, 0x00, 0x00, 0x00, 0x80, 0x17,

       0x18, 0x19, 0x00, 0x00, 0x1c, 0x1d, 0x1e, 0x1f,

       0x00, 0x00, 0x00, 0x00, 0x00, 0xa0, 0x16, 0x1b,

       0x00, 0x00, 0x00, 0x00, 0x00, 0x50, 0x60, 0x70,

       0x00, 0x00, 0x15, 0x00, 0x00, 0x00, 0x00, 0x40,

       0x00, 0x00, 0x00, 0x00, 0x13, 0x14, 0x00, 0x1a,

       0x20, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,

       0x00, 0x00, 0x5b, 0x2e, 0x3c, 0x28, 0x2b, 0x21,

       0x26, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,

       0x00, 0x00, 0x5d, 0x24, 0x2a, 0x29, 0x3b, 0x5e,

       0x2d, 0x2f, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,

       0x00, 0x00, 0x7c, 0x2c, 0x25, 0x5f, 0x3e, 0x3f,

       0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,

       0x00, 0x60, 0x3a, 0x23, 0x40, 0x27, 0x3d, 0x22,

       0x00, 0x61, 0x62, 0x63, 0x64, 0x65, 0x66, 0x67,

       0x68, 0x69, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,

       0x00, 0x6a, 0x6b, 0x6c, 0x6d, 0x6e, 0x6f, 0x70,

       0x71, 0x72, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,

       0x00, 0x7e, 0x73, 0x74, 0x75, 0x76, 0x77, 0x78,

       0x79, 0x7a, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,

       0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,

       0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,

       0x7b, 0x41, 0x42, 0x43, 0x44, 0x45, 0x46, 0x47,

       0x48, 0x49, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,

       0x7d, 0x4a, 0x4b, 0x4c, 0x4d, 0x4e, 0x4f, 0x50,

       0x51, 0x52, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,

       0x5c, 0x00, 0x53, 0x54, 0x55, 0x56, 0x57, 0x58,

       0x59, 0x5a, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,

       0x30, 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37,

       0x38, 0x39, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00

);

// EBCDIC "hello world"

$str = pack( 'CCCCCCCCCCC',

       0x88, 0x85, 0x93, 0x93, 0x96, 0x40, 0xa6, 0x96,

       0x99, 0x93, 0x84

);

$len = strlen($str);

$strBytes = array_values(

                    unpack(

                           'C*',

                           $str

                    )

);

for ($c = 0; $c < $len; $c++) {

       $str[$c] = pack(

                       'C',

                       $table[

                              $strBytes[$c]

                       ]

       );

}

echo $str;

Figure 3.3: EBCDIC-to-ASCII character converter

The first part of this code is the conversion table. It may look like just a series of bytes, but it is actually the numerically indexed array we noted earlier that matches the characters from one character set to another.

The first stage of the process is to extract the numerical values of the string. You could achieve this with repeated calls to the ord() function, but, in general, if you can do something in one call, you should. The $strBytes constant will contain all the individual byte values in our EBCDIC-encoded string.

The next step is just value replacement. Replace the value of $str[$c] with the table-corrected value. That's it. Now, when we run our code, we get the output we expect:

hello world

Our code is now complete. We have the mechanism for converting between any character set in the English language. So, we're all done, right? Nope. Clearly, there are other languages in the world. So, how do we handle many of them? Enter the eighth bit.

Most "Latin" character encodings support ASCII as part of their encoding. This is simply because large parts of most Western language alphabets use English characters, and the people who use these character sets will have a fair amount of contact with English-speaking people. For those two reasons, many of the Western world's character sets include the English ASCII component for the lower bits and then the language-specific characters in the upper values — those above character 127.

To see this in action, consider the script shown in Figure 3.4.

header(

       'Content-Type: text/plain; charset="'

       . $_GET['charset']

       . '"'

);

for ($c = 0; $c < 255; $c++) {

       if ($c % 16 == 1) echo "\n";

       $char = pack('C', $c);

       if (ctype_print($c)) {

             echo $char . ' ';

       } else {

             echo '  ';

       }

}

Figure 3.4: Demonstrating high-bit characters

What this code does is print the byte of each character from 0 to 254. However, you can tweak the character set via the query string. So, if we enter the URL print.php?charset=ISO-8859-1, we get the output shown in Figure 3.5.

Figure 3.5 Output of high-bit characters with IS0-8859-1 encoding

If we enter the URL print.php?charset=ISO-8859-7, the same bytes are being printed, but we're telling the browser to use the ISO Greek character set to render those bytes (Figure 3.6).

Figure 3.6: Output of high-bit characters with IS0-8859-7 encoding

If we enter print.php?charset=Windows-1255, we get the Hebrew characters (Figure 3.7).

 ?

Figure 3.7: Output of high-bit characters with Windows-1255 encoding

Again, nothing has changed in terms of the output between the individual URLs. Only the charset variable, as part of the header, has changed.