[Mono-list] string encoding

[Jaroslaw Kowalski]

1. If you want GTK Support to be mono-only then adding an extension is a way
to go. I don't think that it should be done that way.

2. If you want portability and want to see a quick progress then try
System.Text.Encoding.UTF8.GetBytes(...) and passing strings as byte arrays.
It may not be fast, though because it creates new heap object (garbage) for
each input parameter.

3. You may also want to create a wrapper aroung GTK that would accept utf-16
parameters and convert them to utf-8 which is used by gtk. I think this
would be the fastest way, because all the costly conversion is done in
unmanaged (and highly optimized) code, there are no managed objects (byte
arrays) allocated. Also transition from managed to unmanaged requires no
marshalling as string can be blitted to wchar_t * according to MS specs. I
also think this kind of wrapper could be done automatically using techniques
similar to what gtk-sharp uses today.

Jarek

----- Original Message -----
From: "Havoc Pennington" <hp@redhat.com>
To: "Jaroslaw Kowalski" <jaroslaw.kowalski@atm.com.pl>
Cc: "Marcus" <mathpup@mylinuxisp.com>; <mono-list@lists.ximian.com>
Sent: Sunday, June 22, 2003 9:06 PM
Subject: Re: [Mono-list] string encoding


> On Sun, Jun 22, 2003 at 08:38:34PM +0200, Jaroslaw Kowalski wrote:
> >
> > Charset.Ansi is dependent on windows installation. In Polish Windows it
uses
> > 1250 codepage.
> > All ANSI versions of WIN32 APIs (like GetCurrentDirectoryA) use this
> > codepage.
>
> Yikes. Maybe on UNIX then CharSet.Ansi should be interpreted as "the
> current locale encoding"?
>
> That leaves no way to marshal functions that take UTF-8 regardless of
> locale as GTK does, but Mono could add some nonstandard extension to
> make that easier I suppose.
>
> Havoc
> _______________________________________________
> Mono-list maillist  -  Mono-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-list
>