Skip to main content
A
aleslie1-Visitor
1-Visitor
July 30, 2010
Question

Character strings with no end-of-string ascii character

  • July 30, 2010
  • 9 replies
  • 1379 views
Is there a command, within ACL, for outputting a character string without the end-of-string 0x00 ascii character ?

    9 replies

    B
    bibach1-Visitor
    1-Visitor
    July 30, 2010
    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 ?
    > ----------
    A
    aleslie1-VisitorAuthor
    1-Visitor
    July 30, 2010

    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

    B
    bibach1-Visitor
    1-Visitor
    July 30, 2010
    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
    >
    >
    >
    > ----------
    A
    aleslie1-VisitorAuthor
    1-Visitor
    July 30, 2010

    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

    B
    bibach1-Visitor
    1-Visitor
    July 30, 2010
    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
    >
    > ----------
    G
    GarethOakes16-Pearl
    16-Pearl
    July 31, 2010
    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

    A
    aleslie1-VisitorAuthor
    1-Visitor
    July 31, 2010

    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

    B
    bibach1-Visitor
    1-Visitor
    July 31, 2010
    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
    >
    > ----------
    A
    aleslie1-VisitorAuthor
    1-Visitor
    August 3, 2010

    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

    Terms & ConditionsCookie settingsAccessibility statement