codepage

Posted by Admin on 20-Mar-2007 09:04

Hello,

I hope someone can help me with this one:

We have some issue's regarding the display of some special characters like the char "é".

Take a look at the following piece of code:

readkey.

display lastkey chr(lastkey).

> Now the problem:

We type in the character "é"

In a UNIX environment we get the result: 130 é

In a WINDOWS environment we get the result: 233 é

In both enviroments we use the same database. The startup parameter -cpstream is set to iso8859-1.

This code always returns "ISO8859-1":

DEFINE VARIABLE i AS INTEGER.

REPEAT i=1 TO NUM-DBS: /* For every connected database */

DISPLAY DBCODEPAGE(i).

END.

Does anybody have an idea how this is possible?

All Replies

Posted by Thomas Mercer-Hursh on 20-Mar-2007 10:59

I'm hardly an i18n expert, but I do know that there are a lot more -cp* parameters than just the stream and the database. I'd check out the manual and try a few and I'm pretty sure that you will find the key.

Posted by Admin on 21-Mar-2007 10:34

Thank you for your reply.

Something I've tried gave me a weird result:

In UNIX (telnet), I've ran "$DLC/bin/_progres" with the following parameters all set to iso8859-1:

-cpstream

-cplog

-cpprint

-cprcodeout

-cprcodein

-cpterm

-cpinternal

So NO databases are connected. This is the output i got of some test-code:

readkey. (typed the character "é")

display lastkey. --> 130

display asc("é"). --> 233

display chr(130). --> "é"

display chr(233). --> "é"

I read the documentation, and in my opinion this is normally not possible:

"A code page is a table that assigns a numeric value to each element in a collection of letters, numbers, punctuation, control codes, and other characters. The assignment is one-to-one: no two characters are assigned the same numeric value, and no two numeric values are assigned the same character. "

Any help would be appreciated!

Posted by Admin on 26-Mar-2007 04:19

Hi all!

After some investigation it turns out we've been using an older version of the PROTERMCAP file on the UNIX system.

When we use the new protermcap-file included with OpenEdge, we get the right result ("é" = chr(233)).

However, we need the older file because we've set some custom preferences. We will now compare the two files and make the adaptions to the new file so our custom preferences are also available.

There is just one problem left:

The special characters are stored in the DB as the wrong value. Is there a way by example, to convert all chr(130) to chr(233) troughout the entire DB?

Many thanks!

Posted by Admin on 16-Apr-2007 01:19

Hi All,

I have found some special character problems too.

In an xml file with the special characters in it inside any tag, the file when opened in excel can't be shown. Problem occurred in XML Parser of Office application. I have exported this file from the Progress database and the database contains the special characters.

Do we have some sort of replacing elements for these special characters like that for '' ?

e.g. for "

v-xmlstring = replace(v-xmlstring, "

If any have faced with such problem, please let me know how can we sort this out?

With regards,

Kamal Raj Subedi

Javra Software Nepal

IT Park, Banepa

Posted by Thomas Mercer-Hursh on 16-Apr-2007 11:07

For angle brackets in HTML, you need to use &-l-t and &-g-t (dashes added to keep it from converting) or, perhaps that is what you are doing, but we can't see it ... in which case I'm not sure what your problem is.

Posted by Admin on 10-May-2007 13:06

Hi Thomas,

this would need a bit more in depth analysis. Is this the only character / value you need to replace? If it is that your db characters (values) are in a code page that the DB is not labeled with then you can do proutil -C codepage convert and the values will be converted. If you just need to replace that value, you could create your own conversion table that would contain your new code page which would be identical in source and target values except for the 130 which would lead to 233 and do the same as above.

Also a good trick for changing code page in the DB is to "convert" the db's code page to undefined and then to the target. This will relabel the db with the new code page but will leave the data intact as no conversion occurs when undefined is either source or target code page. Of course, you should load the appropriate collation and case tables and re-index the DB!

Kind Regards,

Tom.

This thread is closed