Hex 00 in Stringbuilder

  • Thread starter Thread starter Richard Van Dyke
  • Start date Start date
R

Richard Van Dyke

Hi all,

I have an application in VB.Net... on input I receive data in a
stringbuilder.... on occassion this data contains a Hex"00" ... I need to be
able to convert this data to a space...

I have tried

dim sb as new stringbuilder(1920)
receive the data using CPIC call to cmrecv....
sb.replace(convert.tochar(0), " "c)

I still get receive length of 1920 from SNA and sb.length is 1920 but since
I need to send this data as sb.string the string length is only 180 which is
where the hex"00" is...

Any ideas on how to convert this to get back to the full data?

Thanks in advance for any ideas
Rick
 
Hi,

If you have a string, then use the Replace function. For example,

'VB
mystring = mystring.Replace(Chr(0), " ")
//C#
mystring = mystring.Replace("\0", " ");


Or, you could manipulate your data as an array of type Byte, not string.
Scan the array for any 0's, convert to hex 20. Then convert the array to a
string that StringBuilder can use.

Dick

--
Richard Grier (Microsoft Visual Basic MVP)

See www.hardandsoftware.net for contact information.

Author of Visual Basic Programmer's Guide to Serial Communications, 3rd
Edition ISBN 1-890422-27-4 (391 pages) published February 2002.
 
* "Richard Van Dyke said:
I have an application in VB.Net... on input I receive data in a
stringbuilder.... on occassion this data contains a Hex"00" ... I need to be
able to convert this data to a space...

I have tried

dim sb as new stringbuilder(1920)
receive the data using CPIC call to cmrecv....
sb.replace(convert.tochar(0), " "c)

I still get receive length of 1920 from SNA and sb.length is 1920 but since
I need to send this data as sb.string the string length is only 180 which is
where the hex"00" is...

Any ideas on how to convert this to get back to the full data?
Click to expand...

Notice that you can use 'ControlChars.NullChar' or 'vbNullChar' for the
null character. I am not sure if I understand your problem, but where
do you get a length of 180? Remember that most controls will refuse
displaying the part of the string after the null character because the
null character is used as string terminator for the controls.
 
The length of 180 is what I get when I display the sb.tostring.length.....
so the stringbuilder is 1920 in length (sb.length) and after conversion to
string the string is 180 in length (sb.tostring.length)

Is there any other character that could be a field terminator other then
null?

Rick
 
Dick,

* "Dick Grier said:
If you have a string, then use the Replace function. For example,

'VB
mystring = mystring.Replace(Chr(0), " ")
Click to expand...

ACK. Instead of 'Chr(0)' I prefer 'ControlChars.NullChar'.

Just my 2 Euro cents.
 
Dick,
I would use ChrW(0) or ControlChars.NullChar.

As Chr will attempt to apply the current System.Text.Encoding to the char
code, where as ChrW does not.

For ChrW(0) it probably doesn't not make a lot of difference, however for
Chr(200) vs. ChrW(200) it may make a big difference (depending on your
locale)! While Chr(300) simply isn't supported.

For example in the US Chr(128) gives the ? (euro sign) while ChrW(128) does
not as ChrW(&H20AC) is the proper code point for the Unicode ? (euro sign)
symbol.


The short of it is, ChrW is better prepared for internationalization,
especially with char code 128 & higher!

Hope this helps
Jay
 
Hi Dick,

My idea is almost the same as Jay B, only I would not use an alternative.

I find the chr(0) the most meaningfull, the more because that it is used
with every extended ascii value.

Just to show some opinions.

Cor
 
Hi Herfried,
'Chr(0)' I prefer 'ControlChars.NullChar'.
<<

Sure, I like to type extra characters too. <g> Of course, at the end of the
day, the extra typing doesn't burn enough calories to worry about.

Dick

--
Richard Grier (Microsoft Visual Basic MVP)

See www.hardandsoftware.net for contact information.

Author of Visual Basic Programmer's Guide to Serial Communications, 3rd
Edition ISBN 1-890422-27-4 (391 pages) published February 2002.
 
Hi Jay,
As Chr will attempt to apply the current System.Text.Encoding to the char
code, where as ChrW does not.
<<

But, the current encoding is what is being used. This IS a text stream, not
binary data.

Dick

--
Richard Grier (Microsoft Visual Basic MVP)

See www.hardandsoftware.net for contact information.

Author of Visual Basic Programmer's Guide to Serial Communications, 3rd
Edition ISBN 1-890422-27-4 (391 pages) published February 2002.
 
Hi Herfried,
Notice that you can use 'ControlChars.NullChar' or 'vbNullChar' for the
null character. I am not sure if I understand your problem, but where
do you get a length of 180?
<<

His null character is at character count 180, thus terminating the string.

Dick

--
Richard Grier (Microsoft Visual Basic MVP)

See www.hardandsoftware.net for contact information.

Author of Visual Basic Programmer's Guide to Serial Communications, 3rd
Edition ISBN 1-890422-27-4 (391 pages) published February 2002.
 
Hi Rick,

A field-terminator could be any non-printing character that is defined by
the system that you are using. Standard ASCII field terminators are FS
(Chr(28)), GS (Chr(29)), RS (Chr(30)), and US (Chr(31)). The use of a null
for this is not what one would think of as "normal."

Dick

--
Richard Grier (Microsoft Visual Basic MVP)

See www.hardandsoftware.net for contact information.

Author of Visual Basic Programmer's Guide to Serial Communications, 3rd
Edition ISBN 1-890422-27-4 (391 pages) published February 2002.
 
Hi Richard,

I saw so many answers,

but if everything fails you can take this easy solution

\\\to make a test
Dim a As String = "123456789"
Dim b As String = "abcdefg"
Dim c As String = a & Chr(0) & b
\\\
Do While c.IndexOf(Chr(0)) <> -1
c = c.Substring(0, c.IndexOf(Chr(0))) _
& " " & c.Substring(c.IndexOf(Chr(0)) + 1)
Loop
////to show the answer
MessageBox.Show(c)
///

I hope this helps,

Cor
 
Dick,
The encoding on the file may be different then the encoding that Chr uses.

Also Chr & ChrW are independent of any Stream! (in that you can use them
without having a Stream).

Further the OP was referring to a StringBuilder which means it is long past
the Stream encoding stage...

For my money I will always use ChrW over Chr, as the results are not
dependant on the current Windows code page!

Just a thought
Jay
 
Hi Jay B.

Because this is about a 00 representant I stay with the chr(0) the same as
for the Hex 0A which is for me chr(10) or LF.

I am curious, there is the character f in the 437 character set chr(159), do
you know where this code stands for. (I ask this because I do not know if it
has an US meaning).

Cor
 
Rick,
A null char (ChrW(0)) in your StringBuilder should not be terminating the
string.

Both System.String & System.Text.StringBuilder fully support having a null
char in the string.

If sb.length = 1920, then sb.tostring.length should also be 1920!

I know the debugger in VS.NET has troubles with null chars in strings as it
relies on Win32 APIs that treat the null char as a string terminator,
however it is an API problem not a String or StringBuilder problem. Also
System.Console & System.Diagnostics.Debug & Trace will have problems, as
they all rely on a Win32 API that treat the null char as a string
terminator...

Are you calling a Win32 API that is treating the null char as a string
terminator?

If you have a StringBuilder you can use its replace method to replace the
null char with a different character.

sb.Replace(ChrW(0), " "c)


Here is an example that demonstrates that null chars are allowed in both
String & StringBuilder:
Dim sb As New StringBuilder(1920)
For i As Integer = 1 To 1920
sb.Append("a"c)
Next
sb.Chars(180) = ChrW(0) ' force a null char
Debug.WriteLine(sb.Length, "sb.length")
Debug.WriteLine(sb.ToString().Length, "sb.tostring().length")

Will report:

sb.length: 1920
sb.tostring().length: 1920

What is "receive the data using CPIC call to cmrecv...." that you are
calling? Is this somehow changing lengths of strings on you?

The above is based on VS.NET 2003.

Hope this helps
Jay



Rick said:
The length of 180 is what I get when I display the sb.tostring.length.....
so the stringbuilder is 1920 in length (sb.length) and after conversion to
string the string is 180 in length (sb.tostring.length)

Is there any other character that could be a field terminator other then
null?

Rick
Click to expand...
 
Cor,
You mean f the "Latin Small Letter F with Hook" (as reported by Character
Map).

Unicode it is code point 402 (U+0192 where the 192 is hex)

Under the standard US code page it is Chr(131).

Chr(159) in the US is Y "Latin Capital Y with Diaeresis"


Which is (further reason) why I prefer using the Unicode characters (ChrW &
AscW) I can then simply use ChrW(&H0192) for the "Latin Small Letter F with
Hook" and ChrW(&H0178) for the "Latin Capital Y with Diaeresis" and it does
not matter what regional settings in Windows are (my local) the characters
will come out the same!


FWIW: To get the character you were after I used:

Dim encoding As Encoding = encoding.GetEncoding(437)
Dim bytes() As Byte = {159}
Dim ch() As Char = encoding.GetChars(bytes)
Debug.WriteLine(AscW(ch(0)), "ascw")
Debug.WriteLine(Asc(ch(0)), "asc")


Hope this helps
Jay
 
Jay,

I think that you and me agree almost completly about that chrW. But for a
7byte in real Ascii character I prefer the chr. For me is a chrW a unicode
(if I have that wrong or right) :-)

But that f has always got my curiosity because I do not understand why the
old Dutch guilder sign came in that characterset. So I am curious if it has
another meaning in the US than (it had) in Europe (we now have the Euro). I
mean a meaning as $, or # or something, Americans have a lot of those in my
opinion when you are comparing that with us Europeans.

Cor
 
Dick,

* "Dick Grier said:
'Chr(0)' I prefer 'ControlChars.NullChar'.
<<

Sure, I like to type extra characters too. <g> Of course, at the end of the
day, the extra typing doesn't burn enough calories to worry about.
Click to expand...

In this particular case, it doesn't matter, I only wanted to point to
OP to an alternative.

;-)
 
Cor,
I think that you and me agree almost completly about that chrW. But for a
7byte in real Ascii character I prefer the chr. For me is a chrW a unicode
(if I have that wrong or right) :-)
Click to expand...
I don't think we disagree on using Chr per se.

Unicode was designed such that 7 bit chars (0 to 127) match the ASCII char
set, which is fine for Windows, however on an EBCDIC machine this will not
hold true, as all the normal characters are in the range 128 to 255. So yes
we agree 0 to 127 Chr & ChrW will return the same characters which I believe
I stated earlier. Unless of course you are running EBCDIC as your Windows
code page... As strange as this sounds consider what happens if port .NET to
an IBM MainFrame or IBM AS/400, both run EBCDIC "natively", however they
both support other code pages & Unicode. At least I know the AS/400 supports
Unicode as I am currently in the middle of a project using Unicode on an
AS/400.

For a series of links on Unicode, Ascii, Ansi & various encodings used see:
http://www.yoda.arachsys.com/csharp/unicode.html


For info on using EBCDIC in .NET see:
http://www.yoda.arachsys.com/csharp/ebcdic/

I'm not completely following your second statement. In the US we use the $
to denote US dollars. I realize that most European countries now us the
Euro. Are you asking why is chr(159) an f w/hook in one code page & a
guilder in another? Remember that pre Unicode (ANSI) that you only have 8
bit characters, so they used code pages, where chars 128 to 255 changed
based on the code page, and each country basically have their own code page,
allowing that country to have characters specific to that country. With
Unicode Chars are now 16 bit, with support for 24 bit & 32 bit characters.

Hope this helps
Jay
 
Dick,

* "Dick Grier said:
Notice that you can use 'ControlChars.NullChar' or 'vbNullChar' for the
null character. I am not sure if I understand your problem, but where
do you get a length of 180?
<<

His null character is at character count 180, thus terminating the string.
Click to expand...

ACK. That's how I understand it too, now.
 
Back
Top