[General Topics] Menneisyys:
2.1.1 How my custom server emulator should be used?

The application listens to incoming HTTP requests at port 82. It requires a custom parameter (as extra path info - that is, you don't need to use the ? but / instead) in the following form:

http://127.0.0.1:82/xyz

(change 127.0.0.1 to the Internet address of your desktop PC's address if you want to access it from your PDA)

where

x tells the server emulator to set the ‘charset' attribute of the HTTP response header Content-Type. (Doesn't set it at all if you pass a ‘N' instead.)

y tells the program emulator to set the ‘charset' attribute of the "Content-Type" http-equiv meta tag. (Doesn't set it at all if you pass a ‘N' instead.) This is the only way for a plain user (not having access to the Web server configuration) to set a charset for a given page.

z tells the server what character encoding to use internally. In most cases, you can safely keep it as ‘2' for the test.

All values are one-digit numerals; I've tested the browsers with value ‘1' (Western charset) and ‘2' (Central-European charset). As has already been mentioned, with the first two digits, you can also supply ‘N' (which stands for ‘No', ‘Doesn't exist' or ‘Not known'); then, the given HTTP header / HTTP-Equiv tag won't be set / returned. If you set something other than ‘1' or ‘2' for the ‘z' digit, it'll default back to ‘1'.

For example, if you enter http://127.0.0.1:82/111 in your Internet Explorer browser running on the same machine as the server emulator, you'll see this.

In here, there are three rows of special interest (the fourth, the date row is only included so that you can be absolutely sure the browser doesn't just returning a cached document):

"8-bit 8859-1-only punctuation marks" contains strictly 8859-1 punctuation marks. You should see real punctuation marks (if you render the page as a 8859-1 page) after this introduction: no squares, no question marks, no nothing.

"Central-European chars (will ONLY work with the third parameter being 2):" contains two Central-European characters. You'll see them rendered in three ways: as question marks (if you pass anything but ‘2' as the third, ‘z' parameter), as (the closest Western rendering of these characters) and, finally, as , which is how they should be rendered. (Finally, as a - mark (hyphen) in Thunderhawk because it doesn't contain any non-Western character in its custom character set.)

Finally, the third row will be always displayed the same way because it explicitly uses HTML Unicode character entities, which aren't affected by the language setting. That is, it'll be always rendered as

2.2 The chart

In the following chart, I've (keeping ‘z' as ‘2' in all the cases - again, it doesn't have direct affect on any HTTP header or HTML meta-tag, only the way Java encodes the returned contents) tested all the available combinations. This way, I was able to see

whether the HTTP-Equiv meta tag overrides the "Content-Type" HTTP response header (nope, only in NetFront - this is a big difference in NetFront and any other Web browser and should be modified by the NetFront people! Other browsers only take into account the meta tag if there is absolutely no charset parameter in the HTTP Content-Type response header)

if none of the two alternates are used, what charset the browser defaults to (fortunately, Western charset in all cases)

Click here for the chart

2.2.1 Explanation for the chart

2.2.1.1 NetFront and Content-Type (charset) overriding: different from the approach of all other browsers!

Again and again, NetFront works differently from all other browsers, header overriding-wise. That is, something that works on a desktop browser or any other Pocket PC browser will not necessarily work on NetFront if the HTML document contains a Content-Type metatag. Again, NetFront will override the encoding of the page with the value found in this metatag, unlike any other browser. This seems to be the reason why several people have reported char encoding problems with NetFront.

It should also be pointed out that the overriding being non-standards-compliance aside (which should be fixed by the Access folks - the developers of NetFront - as soon as possible), NetFront isn't able to display any extended punctuation mark contained in the 8859-1 codepage if you don't use the default (and ugly) Courier New font but switch to a proportional font. No matter what language info you return from the Web server, these characters will just not be displayed. A quick fix for this problem (before the Access folks fix this bug) is forcing the browser to, say, use the Central European (windows-1250 as opposed to 8859-2), Baltic or Greek encoding (but not to UTF-8, which hides all these chars) encoding as can be seen in here (note that now the punctuation is displayed in the background, on the Web page).

2.2.1.1.1 How Web administrators should treat NetFront clients?

This also means if you're a Web hoster / Web author and would like to allow your NetFront users to be able to browse your otherwise Western (8859-1) pages and there aren't any, say, French and Spanish names / texts on the website (with all those funny accented characters), you should consider marking these pages as, say, Central-European (windows-1250) or Baltic if and only if your client using NetFront (you can easily see this by checking for the User-Agent HTTP request header as has already been explained in several of my User-Agent header-related articles; for example, this one).