Search a string buffer with nulls (chr(0))

[!NoItAll]

I need to search a buffer for a string of characters.
The buffer is essentially a binary file (it's an image) and contains lots of chr(0) characters.
The string I need to locate also contains chr(0) characters. In fact it is the following string:
chr(100) & chr(0) & chr(0) & chr(163)

This is a marker in the image file for items I need to process.
So I though I would do the following:

Dim sFileBuffer as String  = system.io.file.readalltext("myimagefile")
Dim sLookFor as String = chr(100) & chr(0) & chr(0) & chr(163)
 
Dim iLocation as Integer = sFileBuffer.IndexOf(sLookFor)
 

The problem is that, although the characters in sLookFor definitely exist inside of sFileBuffer - IndexOf will always return -1 (not found).

I tried the following:

Dim Marker() as Byte = {100, 0, 0 , 163}
Dim sLookFor as String = System.Text.Encoding.UTF8.GetString(Marker)
Dim sFileBuffer as String  = system.io.file.readalltext("myimagefile",  Encoding.UTF8)
 
Dim iLocation as Integer = sFileBuffer.IndexOf(sLookFor)
 

But this appears to only find occurrences of Chr(100) & Chr(0) - not the full 4 character sequence I desire. It appears to see the second Chr(0) as a termination of the search string.

I think the sticking point here is the null. Yes - I can string.replace( chr(0), Chr(255)) in both the sLookFor and the sFileBuffer and adjust my search accordingly - but that seems like a mess to me.

Is there not a way to search a buffer of binary data? I've tried working with byte arrays - but there appears to be no way to easily search for a sequence of byte values - just individual elements in the array.

VB6 did this perfectly just using strings.

[!NoItAll]

Oh my - so we could ask the question:
"When is a stopwatch not a stopwatch?"
Answer: "When Microsoft builds it." cue laughter and applause...
Not being a C# person I can still appreciate the superior elegance of your approach. It does, however, look as though it will return a+b as soon as it just finds a match to the first char in TargetBytes.
Would you not need Continue For (or the C# equivalent) after WeHaveAWinner = True? Also - just return a once b = (searchbytes.le ngth-1). I don't see a need for the booleans.

in VB it would look like this:

Public Function ReturnLocationAfterFound(ByVal SearchBytes As Byte(), ByVal Targetbytes As Byte()) As Integer
        For a As Integer = 0 To (Targetbytes.Length - 1)
            ' Search the length of the target array
            If Targetbytes(a) = SearchBytes(0) Then
                ' We found a match to the first byte of our comparitor
                ' Do all the rest match?
                For b As Integer = 0 To (SearchBytes.Length - 1)
                    Dim WeHaveAWinner As Boolean = False
                    If Targetbytes(a + b) = SearchBytes(b) Then
                        If b = (SearchBytes.Length - 1) Then
                            Return a
                        End If
                        Continue For
                    Else
                        ' break out of the 'b' loop since it doesn't match
                        Exit For
                    End If
                Next
            End If
        Next
        ' If we got this far there was no match
        Return (-1)
    End Function
 

When I run the unreliable stopwatch this routine in VB now takes less time than my less elegant solution - so this looks really good.
I think I will keep this arrow in my quiver!

Des

[tlhintoq]

It does, however, look as though it will return a+b as soon as it just finds a match to the first char in TargetBytes.

Yep. That return should have been moved down to lines so it was outside the 'b' loop. Correction below

// Returns the value of the NEXT byte after the match
// Or -1 if no match
        public int ReturnLocationAfterFound(byte[] SearchBytes, byte[] Targetbytes)
        {
            for (int a = 0; a < Targetbytes.Length; a++)
            {
                // Search the length of the target array
                if (Targetbytes[a] == SearchBytes[0])
                {
                    // We found a match to the first byte of our comparitor
                    // Do all the rest match?
                    for (int b = 0; b < SearchBytes.Length; b++)
                    {
                        bool WeHaveAWinner = false;
                        if (Targetbytes[a + b] == SearchBytes[b])
                        {
                            WeHaveAWinner = true;// Keeps setting to true as long as they match
                        }
                        else
                        {
                            WeHaveAWinner = false;
                            break;// break out of the 'b' loop since it doesn't match
                        }
                    }
                       // Yep, this should have been outside of the 'for' loop construct
                        if (WeHaveAWinner) return a + b;// this is the location right after our match
                }
            }
            // If we got this far there was no match
            return -1;
        }

Would you not need Continue For (or the C# equivalent)

Nope. Everything within the curly braces is the 'for' loop. No need to specify a 'continue'. As a matter of fact your placement of the DIM Bool and Continue seem odd to me, but I'm not a VB guy. to me it looks as if the bool will get reintialized to false every loop through b, plus the continue is in the middle of the If...Then... Else... Doesn't that mean the "continue for' get's run before the 'else' clause of the 'if', and therefore the loop starts all over without ever executing the 'else' condition. Basically making the else clause unreachable?

<more studying of your VB translation>

Ok, I think I get what you've done. Ok, yeah...The way you've done it the bool is not used. Just a little difference in programming style but they both get the job done. We both have 3 'if' conditions, I just prefer to not have two inside the inner loop, because they both get evaluated on every pass through the loop. I don't think the difference in processing time of one or two 'if' checks is ever going to make a detectable difference. You'd have to be searching for a signature of a 1000 bytes, and doing it 1000 times to see much of a reduction in performance.

By returning 'a' you are returning the start position of the matching set of bytes.
By returning 'a + b' you are return the start position of the bytes *after* the matching set of bytes. I guess it just depends on what you are looking for.

I thought the goal was to process everything *after* the 'signature' you were looking for, so that's why I went with returning a+b.

Not being a C# person I can still appreciate the superior elegance of your approach.

I appreciate the kind words, but I think your take on the approach is every bit as good and clean. Keep up the good work.