Legacy Character Encoding

Question

I'm messing around with the source code for an old Java game written in the early nineties. If I remember correctly, it's written for JDK 1.1.

Somewhere in the code, int primitives (in the range of 0 to about 120) are converted to chars. Here's an example:

char c = (char)(i+32);

This causes a problem for ints greater than 95. Here's the code and some of the output from a test case:

for(int i = 120; i >= 0; i--)
   System.out.println(i + " -> " + (char)(i+32));

Output:

...
100 -> ?
99 -> ?
98 -> ?
97 -> ?
96 -> ?
95 -> 
94 -> ~
93 -> }
92 -> |
91 -> {
90 -> z
89 -> y
88 -> x
87 -> w
...
3 -> #
2 -> "
1 -> !
0 ->  

The integer value seems to be lost since the index goes past the bounds of normal character values.

This seems to be the root cause of a bug on the client-side portion of the game's UI. This encoded integer is sent back to the client, which then performs the inverse operation (subtracting 32 from the char and casting to get an int back).

It seems that the '?' is taken literally by the client-side processing module, as the bar is redundantly filled with the mapped integer value for '?' until the server starts sending back values smaller than 95.

1. What character encoding might have been used on the authors' platform?
2. What exactly is happening on my platform differently?
3. What is, in your opinion, the easiest solution to this problem?

Answer 1

char in Java is a 16bit Unicode character. It is possible the old code was expecting to treat the int values as bytes and you could then convert the bytes to chars specifying different character sets until you get one that makes sense (i.e. new String(byteArrayData, "ASCII")).

What you will need to take account of is that bytes are signed in Java and so range from -128->+127. If your old game code was expecting to use the values in the extended ascii set (> 127), then you'll need to subtract 256 from any int > 127 to get the correct byte value. See: How does Java convert int into byte? for more details.

Answer 2

The integer value seems to be lost since the index goes past the bounds of normal character values.

Well, it's not really "lost" - it's just going into a range of control characters.

What character encoding might have been used on the authors' platform?

I don't believe this is a "normal" encoding on any platform.

What exactly is happening on my platform differently?

It's not clear what you expected to happen, but those characters can't be displayed by your console, so it's translating them into '?'

What is, in your opinion, the easiest solution to this problem?

You'd have to define the problem better to start with, in terms of what you want to happen, to get a solution to this. It's not clear whether this is really a console game or something else, or what you want to happen.

Work out exactly what you want the behaviour to be first, and then it may well be quite easy to accomplish it - I suspect the problem may be that you don't (yet) have a very clear idea of what the final outcome should be. Often, then act of just defining that very specifically is enough to get you going.

Answer 3

What is, in your opinion, the easiest solution to this problem?

First, you have to understand what the application is actually trying to output; i.e. what those integer values really mean. That will determine the requirements for rendering them to (I guess) printable characters.

If you are simply trying to render the integers as something printable, then you could do it with a lookup table implemented as an array of characters; e.g.

char[] map = new char[128];  // ... or whatever the limit is 
for (int i = 0; i < 96; i++) {
    map[i] = (char) (i + 32);
}
// fill the rest of the array with suitable Unicode characters.
map[96] = ...
map[97] = ...

and then map the characters like this:

char c = (i >= 0 && i < 128) ? map[i] : '?'; // ... or throw an exception.

Answer 4

It could be that an 8-bit encoding such as Win1252 was used, which has visible characters in the 80-9F range.

See http://en.wikipedia.org/wiki/Windows-1252