I'm thinking abour updating my VC++ 6.0 project to support localization. Right now it is an ANSI project (MBCS and UNICODE are not defined). If I do nothing else, what do I gain by moving to Unicode?
Printable View
I'm thinking abour updating my VC++ 6.0 project to support localization. Right now it is an ANSI project (MBCS and UNICODE are not defined). If I do nothing else, what do I gain by moving to Unicode?
Ansi means you only support a single codepage. and can thus you typically only support languages for the single codepage the program was designed for.
You may be able to make your program support multiple codepages, but if you need to go there, it's far easier to go unicode.
The advantage of Unicode is that you have more than 256 different types of characters in your character set.
The disadvantage of unicode is that you have more then 256 characters in your character set. (yes, I'm doing that on purpose).
Or putting it another way, you gain the ability for all the glyphs, but it also means you have to deal with that.
(you'll be using wchar_t instead of char, which is 2 bytes on Windows (and thus actually not unicode but either UCS2 or UTF16), 4 bytes on unix. It means you can't make common assumptions such as if a string has 14 characters (wchar_t) it'll have a display length of 14 symbols. It could be less since you have combing diacritics. you can't just take substrings by length etc etc etc.
Or essentially every single interaction with strings in your program needs to be re-evaluated for correctness.
If you standardized on UNICODE for your program, then the benefit is that is what Windows uses internally.
It's a benefit because if your program is ANSI, then the OS converts any win api calls that contain strings into UNICODE (and converts any strings back into ANSI on the return). If your program is compiled as UNICODE, then the win api's don't need to do any string conversions.
That being said, does your program read and write to ANSI data files? Does it receive or send ANSI data in other forms (such as through the serial port or other device)?
If so, a good approach for incoming string data is to provide a conversion layer for the inputs and convert the ANSI string data (from files/serial port, etc.) into UNICODE in one spot so that internally your program only deals with UNICODE. For output, if you need to write ANSI files or send ANSI data, you would convert on the output layer.
I believe folks run into problems when they try to do string conversions throughout their code rather than by creating a specific layer that is responsible for ANSI/UNICODE conversions for input/output data.
If you do decide to go to UNICODE, then I recommend still calling the Win api's without the A or W extensions (when you define UNICODE, the api's will be called with W extensions). Also, use the _T("") macro or L"" string prefix for any string literals.
If you do nothing else, you gain only native support from Windows in displaying Unicode compatible characters/symbols as well as user input in various common controls where applicable. This is way far from commonly understood localization, though is a point good enough to start from.Quote:
Originally Posted by Mike Douglas
Well, in fact it really depends on your definition of localization. You may have an MBCS app localized this or that way, or may have Unicode app able to interact with end user in English only. Ultimately, localization and Unicode have very little in common, though being not completely unrelated.
What igor said...
Turning your app into a unicode app is "the easy" part of the problem. Though depending on what your app does, even this could be difficult.
Localisation is A LOT more difficult. You're probably used to languages that read left to right, but the opposite exists (like arabic) as well. This has consequences for how stuff is sorted and displayed, how you organize your input screens and reports. Some languages have special rules about how combinations of characters are to be treated, (you can't "substring" one of those in the middle). For some languages an 'a', an 'â' and an 'ä' may be treated as identically characters, in other languages they are to be treated as different characters with unrelated sorting rules.
Anything depending heavily on fixed width fonts, typically has all sorts of issues. if you need to support languages where 'single characters/glyphs' don't really exist.
This may or may not be relevant to you depending on what languages you need to support.
Beside that already answered here, have a look at this FAQ: Which Windows API functions are faster, ANSI or UNICODE?
One nice additional note:
Japanese code page 932 maps the same code (0x5C) for backslash and Yen sign.
That was a source of troubles in a legacy application, when dealing with file paths.
After "porting" to UNICODE, this issue gone away with no additional sweat for programmers. :)
Can any one tell me how to get Unicode String in Controls (say CEdit) of VC++6.0 / Windows XP. I have been making a lot of programmes with ANSI chars.
If possible, explain all things to be done. I have failed attempting several times / ways (>20). I get Linker error "cannot open file uafxcwd.lib" (if MFC linked Statically) or "cannot open file uafxcwd.lib" () or mfc42uD.dll not found (But it is in Lib dir of MFC).
You must build your project as a UNICODE one (both UNICODE and _UNICODE must be defined)Quote:
Originally Posted by raghavan141248
https://www.google.de/search?q=canno...m=122&ie=UTF-8Quote:
Originally Posted by raghavan141248
https://www.google.de/search?q=mfc42...m=122&ie=UTF-8