Character strings with no end-of-string ascii character

[aleslie]

Is there a command, within ACL, for outputting a character string without the end-of-string 0x00 ascii character ?

[bibach]

Assuming you mean output to a file, do the put() or write() functions
not do what you want?  If not, please show us what you're doing,
describe the result you want and how the result you're getting
differs.

-Brandon 🙂


On Fri, Jul 30, 2010 at 12:20 PM, Andy Leslie
<info@structuredinformation.co.uk> wrote:
> Is there a command, within ACL, for outputting a character string without
> the end-of-string 0x00 ascii character ?
> ----------

[aleslie]

Hi Brandon,

Yes - outputing a 10 chracter ascii string to a file using the write() command thus :

buf="1234567890';
write(fid, buf);

When I open the resulting text file in hex editor it shows :

31 00 32 00 33 00 34 00 35 00 36 00 37 00 36 00 etc.

The customer, however, does not want to see any end of string markers (0x00); they follow every character when viewed in hex editor. Is this normal ?

Does this make sense ?

Regards,

Andy

[bibach]

Hi, Andy...

Those 00 bytes aren't end-of-string markers.  The documentation for
the write() function (help 777) states:

"If writing to a binary stream, that is, a file opened with "wb" or a
network channel, write writes Unicode characters. Thus,

write(fid, "abc\n")

would write 8 bytes."

So, each 00 byte is the high-order portion of a character, since each
character is written as a 16-bit value.  This is a common practice for
Unicode data.  Because you're on a little-endian system (all Intel
processors are little-endian), the high-order byte comes after the
low-order byte.

To avoid this, use the pack() function, such as:

buf="1234567890';
write(fid, pack("a*", buf));

The "a*" template string means "write all available (*) values as
ascii characters (a)".

-Brandon 🙂


On Fri, Jul 30, 2010 at 4:18 PM, Andy Leslie
<info@structuredinformation.co.uk> wrote:
> Hi Brandon,
>
> Yes - outputing a 10 chracter ascii string to a file using the write()
> command thus :
>
> buf="1234567890';
> write(fid, buf);
>
> When I open the resulting text file in hex editor it shows :
>
> 31 00 32 00 33 00 34 00 35 00 36 00 37 00 36 00 etc.
>
> The customer, however, does not want to see any end of string markers
> (0x00); they follow every character when viewed in hex editor. Is this
> normal ?
>
> Does this make sense ?
>
>
>
> Regards,
>
>
>
> Andy
>
>
>
> ----------

[aleslie]

Thanks Brandon.

Very helpful. I will try this.

Also, some fields I need to write out to the file contain integer values.

Are integers and character strings written out in the same way within ACL ?

Regards,

Andy

[bibach]

Andy,

Typing "help 778" at the command line in Editor will bring up the help
page on the pack() function, which has all the details on how to
convert pretty much any type of value into a byte string that can be
passed to the write() function.  The unpack() function reverses the
process.

-Brandon 🙂


On Fri, Jul 30, 2010 at 5:41 PM, Andy Leslie
<info@structuredinformation.co.uk> wrote:
> Thanks Brandon.
>
> Very helpful. I will try this.
>
> Also, some fields I need to write out to the file contain integer values.
>
> Are integers and character strings written out in the same way within ACL ?
>
>
>
> Regards,
>
> Andy
>
> ----------

[GarethOakes]

I suppose the caveat here is if you have any non-ASCII characters in the
content then they most likely will be corrupted when you "export to
ASCII" via pack().

FYI Andy, the double byte encoding that was being used is either UTF16
or UCS2. The output should also have technically had a Unicode BOM (Byte
Order Mark) but I guess the write() function wasn't spitting that out
for you.

-Gareth

[aleslie]

Hi Brendon,

Do I use pack("S*", buf) for 16bit unsigned short integer value ?

The help states S as an unsigned short (16–bit) value but no mention of integer.

Regards,

Andy

[bibach]

Andy,

It sounds like you need to start with specifying exactly what an
"integer" is, for your application.  Beyond the basic mathematical
definition of "a whole number" (no fractional portion), should it be
8-bit, 16-bit, 32-bit?  Signed or unsigned?  Stored in the file as
little-endian or big-endian?

-Brandon 🙂


On Sat, Jul 31, 2010 at 4:13 AM, Andy Leslie
<info@structuredinformation.co.uk> wrote:
> Hi Brendon,
>
> Do I use pack("S*", buf) for 16bit unsigned short integer value ?
>
> The help states S as an unsigned short (16–bit) value but no mention of
> integer.
>
> Regards,
>
> Andy
>
> ----------

[aleslie]

Hi Brendon,

I need to convert to Big Endian 16bit unsigned integer.
Is this pack("n*", buf) ? or should I use S* ? The value could be 64

I also need to convert to Big Endian 32bit unsigned integer.
Is this pack("N*",buf) ? Value could be 0, 1 or 2.

Furthermore, how do I specify an unused byte ?

Many Thanks,

What is your email address ? - be easier than working through the forum.

Many Thanks

Andy