Re: Why use the unicode version of the api?

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance



Sorry, it sounds like we're talking at cross purposes Thorsten. My point was
that there is an ANSI code page for each MBCS (incl. SBCS/DBCS), and that's
set as part of your locale configuration. Hence, not all ANSI character sets
have 1 byte-per-character -- it depends where you are. In general, the ANSI
code pages just deal with the local characters, plus 7-bit ASCII, but as you
say, they don't cope with all multi-national characters, whereas Unicode
does. I think that is the point you were making yourself.

Tony Proctor

"Thorsten Albers" <albersRE@xxxxxxxxxxxxxxxxxxx> wrote in message
news:01c5ed0e$d5cc7ac0$7d8ee684@xxxxxxxxxxx
> Tony Proctor <tony_proctor@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> schrieb im
> Beitrag <#PlYoyP7FHA.3752@xxxxxxxxxxxxxxxxxxxx>...
> > That's not quite true Thorsten. "ANSI" code pages include all potential
> > locale-specific MBCS, and this includes DBCS such as Shift-JIS, Big-5,
> etc.,
> > but not confined to those alone. This is mirrored in the APIs
> > MultiByteToWideChar()/WideCharToMultiByte() which may be considered to
> > perform A-to-W/W-to-A.
>
> MultiByteToWideChar() and WideCharToMultiByte() are, no doubt, able to
> handle all possible DCBS if the respective code page is installed, because
> as character conversion routines they are working with the code page
> information.
> But I am interpreting Gustavo's question on a more general term: Are all
> "A" versions able to handle DCBS? The answer is: no they aren't (excepting
> functions which are working with code page information explicitely like
> MultiByteToWideChar()). On a japanese and a chinese system the "A"
versions
> are guaranteed to support japanese/chinese DCBS - and nothing more.
>
> --
> ----------------------------------------------------------------------
> THORSTEN ALBERS Universität Freiburg
> albers@
> uni-freiburg.de
> ----------------------------------------------------------------------
>


.



Relevant Pages

  • Re: Why is this true: chr(254) = "th"
    ... I suspect because under Windows Control Panel you have a region selected ... where the ANSI code page maps Chrto a character that maps to th. ... Chr which uses your Windows ANSI code page value. ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Why is this true: chr(254) = "th"
    ... I suspect because under Windows Control Panel you have a region selected ... where the ANSI code page maps Chrto a character that maps to th. ... Chr which uses your Windows ANSI code page value. ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Problems with Replace Method
    ... I use Character Map under "Programs - Accessories - System Tools" on Windows ... Unicode code point. ... It just happens that in the US that the ANSI code point ... I almost always use ChrW & the Unicode code points as Chr & the Ansi code ...
    (microsoft.public.dotnet.languages.vb)
  • RE: Insert special character in a field with the press of a button
    ... I only need the character (the ansi code, ... > Just pointing out something you may already know: that only one font can be ... since the act of clicking the button will move the cursor. ...
    (microsoft.public.access.formscoding)