[jcifs] [firstname.lastname@example.org: Re: secrets.tdb in the wrong place]
Michael B. Allen
mballen at erols.com
Tue Sep 25 09:56:42 EST 2001
On Mon, Sep 24, 2001 at 02:44:10AM +0200, Luke Kenneth Casson Leighton wrote:
> what u guys do? :)
Use the source Luke.
Seriously. We funnel everything through static serialization routines in:
But this just handles alignment, the useUnicode flag, and presents a
very general interface interface; String readString( byte src, int
srcIndex ). The real work is handled by Java as Joe points out "quite
nicely". To encode it's just:
byte bytes = str.getBytes( "UnicodeLittleUnmarked" );
and to decode its:
str = new String( src, srcIndex, len, "UnicodeLittle" );
Trivial, by comparison to iconv or xICU.
> Luke Kenneth Casson Leighton wrote:
> > so, data comes in off-wire in unicode-16. it gets
> > converted using iconv. then, data goes out, but it has
> > to go out in unicode-16, so gets converted again.
> Personally I like Java, and Java handles unicode quite nicely :-))).
> I wonder how Jcifs unicode stuff is handled, do they use it natively or convert
Incedentally, on the subject of decoding and encoding Unicode strings in
c, I have prepared a package that attempts to abstact the particulars
on top of iconv. The CIFS encoding is UCS-2LE (although Peter Anvin
on linux-utf8 thought it was UTF-16LE so I'm not sure). This package
normalizes these encodings to wchar_t. It's here:
It also, handles times and of course integers. It's not perfect, but it's
a start and at lease separates the peas and carrots. Most people don't
like wchar_t for some reason, but tell me a better internal representation
with a portable set of string functions and I'll listen.
More information about the jcifs