Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.misc -> Re: extended ASCII seems not to exist for some clients

Re: extended ASCII seems not to exist for some clients

From: Malcolm Dew-Jones <yf110_at_vtn1.victoria.tc.ca>
Date: 17 Dec 2002 12:11:21 -0800
Message-ID: <3dff84e9@news.victoria.tc.ca>


Christian BIERO (cbiero_no_spam_at_gold-solutions.com) wrote:

: the same way   select CHR(233)||' é' from dual;     gives me :

: - 'e i' using sqlplus under the server via telnet
: - 'é é' using sqlplusw under W98 connected the the same DB
: - 'Ú +' using sqplus under W98 (same PC as above) connected the the same DB

When you send a byte value to the display then the display software/hardware chooses a pixel pattern to display.

The pixel pattern thus displayed appears as a character to us humans.

By default, windows uses a different set of patterns than dos. Therefore the character you perceive when a byte of data is sent to the (virtual) screen of a dos box is different than the character you perceive when the same value is sent to the window of a windows application.

The character displayed by dos for each byte of data can be modified. This might be done by the codepage that the dos session is using. You can change that with MODE CON[:] CP SELECT=yyy (read `help mode' in NT). If the codepage doesn't change the pixel patterns displayed in the dos box then it's some other dos command, but one does exist).

The pixel pattern displayed by windows for each value of data can also be changed. The easiest way is to simply select a different font that displays a different set of patterns (e.g. dingbats will give you very interesting results).

Depending on the application (dos, windows, or any other), it may have a further level of translation that attempts to modify the data itself as it is sent to the display software, so that there might be a more logical relation between the byte values of the data and the small pixel image that gets displayed. Whether you want this depends on how the data is being input - the key issue being to keep the input and the output in sync so what you think you're inputting is what you are really inputting, and what you see as output is what you expect (and correctly represents the values stored in the database).

The telnet application will often add a further level of complication, because it may be trying to emulate which pixel patterns it thinks some other hardware would have chosen to display if the byte in question had been sent from an application on a server through a particular terminal driver and then along a serial connection to get to a specific model/brand of vt terminal that had its hardware set a certain way.

That makes it hard to know exactly why the telnet session displays what it does. Received on Tue Dec 17 2002 - 14:11:21 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US