Re: how to extend a byte[] array with a null byte?

On Thu, 17 Apr 2008 10:47:50 -0700, Rex Mottram <rexm@xxxxxxxx> wrote:

This should be simple but I'm struggling with it (and am somewhat of a Java newbie). I have a string

String foo = "abc";

and need to write it into a database file as a C-style string (meaning a trailing null is appended). The API takes a byte[] array, thus the current usage is something like

dbfile.add(foo.getBytes());

I simply need to take the byte[] array returned by String.getBytes() and add one extra byte containing 0 before passing it to the add() method. Try as I might I can't find the way. Help!

Huh? Just copy the bytes into a new array of the desired length, and set the last byte as needed.

For example:

String strFoo = "abc";
byte[] rgbString = strFoo.getBytes();
byte[] rgbDatabase = new byte[rgbString.length + 1];

for (int ib = 0; ib < rgbString.length; ib++)
{
rgbDatabase[ib] = rgbString[ib];
}
rgbDatabase[rgbString.length] = 0;

dbfile.add(rgbDatabase);

I was surprised to not be able to find a helper method in the Array or Arrays class that would do the copy. It's possible one exists elsewhere and I just haven't run across it yet. That would be nicer (and possibly perform better) than the for() loop above.

Also, your example (which I followed) assumes that the default character encoding is a single-byte-per-character encoding. This isn't at all necessarily going to be true. You should either standardize on a specific encoding, and explicitly provide that when you call getBytes(), or you should save information in the database describing the encoding, so that when the data is retrieved later, it can be properly interpreted.

Note also that the termination may depend on the specific encoding you're using. For example, a 16-bit encoding will expect two 0 bytes at the end, not just one.

Finally, you should be really sure that you need to save the terminating null. Presumably the database will keep track of the length of the data.. Whatever's reading the string out could theoretically just use the length of the data when encoding the bytes back to a string. Only if you're constrainted by some backwards-compatibility issue does it seem to me to bother with terminating the string with a null character.

Pete
.

Relevant Pages

  • Re: What could be the problem with this INSERT with ADO parameters?
    ... The only way I have found sofar is to enclose the string in single ... written to the database. ... But that gives the same problem, it actually crashes Excel. ... how do I handle a string with comma's in the parameter array? ...
    (microsoft.public.data.ado)
  • Re: What could be the problem with this INSERT with ADO parameters?
    ... The only way I have found sofar is to enclose the string in single ... written to the database. ... But that gives the same problem, it actually crashes Excel. ... how do I handle a string with comma's in the parameter array? ...
    (microsoft.public.data.ado)
  • Re: text datatype support
    ... Unicode or in the default character encoding of the database. ... True means that string parameters are sent to SQL Server in ...
    (microsoft.public.sqlserver.jdbcdriver)
  • Re: vb and msxml - encoding conversion is not working
    ... data in utf-8 format if that's your selected encoding ... I did the above some time ago using asp and msxml, ... I loaded the vb string into a vb byte array using chrb on odd ...
    (microsoft.public.vb.general.discussion)
  • Re: String parsing in VB.net
    ... refactor your code so that myDataBuffer is an array of Byte, ... than a string. ... receives a data buffer. ... encoding - it is only defined for 0-127. ...
    (microsoft.public.dotnet.languages.vb)