Christian,
you replied:
> > How to do it?
> > You define an escape character (maybe really <Esc>=0x1B or even better a
> > char that is unlikely to show up in your data). Than replace any
> > occurance
> > of this char in your original data with a sequence of <escape><0x1> and
> > afterwards all occurances of <delimiter with <escape><0x2>. Send this
> > data
> > and perform the inverse operation before using your delimiter.
> > Both transcodings can be transparent.
> > I do not have VIs at hand, but exactly this is what is done when
> > transfering our medical measurements between different 'nodes' (may
> > those
> > be instances of operational units, devices or even machines).
> >
> > A side note:
> > You should test a set of your raw data and do a histogram of all chars
> > therein. Use the two chars that do show up least often as <escape> and
> > as
> > <delimiter>.
> 
> Since the array is binary data, potentially any bit pattern can appear in
> it.  You are just making the delimiter longer to decrease the odds of a
> false positive. Theoretically, I could always create artificial sample data
> that would fail your approach.
No. This is a misunderstanding. This is a failsafe aproach if done
properly!
I replace any occurence of the delimiter and of an <Esc> char with a set of
two chars, where the first is that <Esc> char. This adds some extra chars
to the string; the number of extra chars depends on the number of <Esc> and
<delimiter> char in the raw string.
After trancoding every occurence of <Esc> together with its successor is a
representation of one of the original special chars as are <Esc> and
<delimiter>.

> Actually (after sleeping over this), I think the programmatically simplest
> solution would be to make an array of strings, then flatten it again.
> 
> To decode: you unflatten the string to an "array of strings", then
> unflatten
> each string back to the numeric arrays.
> 
> It is so much easier to work with arrays compared to searching through a
> string.
You're right, but with a lot of short strings (and a more slow connection)
the overhead can be very important. 4 extra bytes for every String and at
least 8 extra bytes for the array and its size.

Greetings from Germany!
-- 
Uwe Frenz


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dr. Uwe Frenz
Entwicklung
getemed Medizin- und Informationtechnik AG
Oderstr. 59
D-14513 Teltow

Tel.  +49 3328 39 42 0
Fax   +49 3328 39 42 99
[EMAIL PROTECTED]
WWW.Getemed.de


Reply via email to