Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Converting Portuguese characters
Message
 
To
18/08/2009 15:22:07
Dragan Nedeljkovich (Online)
Now officially retired
Zrenjanin, Serbia
General information
Forum:
Visual FoxPro
Category:
Other
Miscellaneous
Thread ID:
01418660
Message ID:
01418761
Views:
42
>>>>Hi
>>>>
>>>>I'm in the middle of building an international zip code file as part of a major project for an International Courier Company. Portuguese town names are giving me some problems.
>>>>
>>>>Cais de São Pedro and Campanário contain characters which on an English system don't make sense. Anyone got any bright ideas for 'internationalising' these characters so that they make sense in both Portuguese and English
>>>>
>>>>Thanks
>>>>
>>>>Colin
>>>
>>>I'm not sure this will work, but have you tried using STRCONV() to convert it to the corresponding UTF-8 encoded?
>>
>>Forgot to say that by Googling anf manually correcting town names I have been able to build up a dictionary of names and characters which I am now using in STRCONV()
>
>So how do you store them now? As converted? Good luck with that - you're losing information there.
>
>Though VFP can use one codepage at a time, it can make that time really short, i.e. nowadays every control which has .font* properties also has a .FontCharSet property, which can interpret the string in whichever way you like. So you can't mix codepages inside one control, but you can have multiple controls, or you can flip the codepage as needed. You only need to store the strings with NOCPTRAN and to know the applicable codepage - which would, I guess, be stored somewhere in parent tables, one per country or region. So just add a .fontharset=lnCharset in the .refresh() of a control, and it will display in the new codepage. You can flip from Western to Central European to Turkish to Baltic to Cyrillic to Greek to Chinese in less than a millisecond.
>
>Converting toponyms into Western codepage is an invitation to disaster, which can hit at random. Unfortunately, I can't show you any examples, because the current incarnation of UT is guilty of the same error (it was UTF-8 in VFP/dbfs, which were somehow more capable of handling multiple codepages than the current dot-net-sql implementation, which is mostly world-illiterate).

Dragan - very interesting and enlightening - I need to study it further - but I do need to store them as converted because the data will be used alongside the postal information of other countries, and used in the main by people whose IT skills are not great

It will also be bolted into other systems over which I will have no control - so the data has to be seen to be correct

Thanks Colin
Specialist in Advertising, Marketing, especially Direct Marketing

I run courses in Business Management and Marketing
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform