[jcifs] [joed@interlude.eu.org: Re: secrets.tdb in the wrong place]

[Michael B. Allen]

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:

http://auditorymodels.org/jcifs/src/src/jcifs/smb/ServerMessageBlock.java

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
> it?
> 
> Joe.

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:

http://auditorymodels.org/encdec/

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.

Mike