Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / Languages / C# / February 2008

Tip: Looking for answers? Try searching our database.

bytes To Hex

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Analizer1 - 05 Feb 2008 18:01 GMT
Hi I have a Long Number
In a Byte[]

Im not sure how to convert this Byte[] array to a Hex
string

thanks
Peter Duniho - 05 Feb 2008 18:24 GMT
> Hi I have a Long Number
> In a Byte[]
>
> Im not sure how to convert this Byte[] array to a Hex
> string

Well, the .NET way would be to use BitConverter to get the bytes into an  
actual long value, and then use ToString("x") to convert to hex:

    byte[] rgb = { 1, 2, 3, 4, 5, 6, 7, 8 };
    string strHex = BitConverter.ToInt64(rgb, 0).ToString("x");

Pete
Analizer1 - 05 Feb 2008 18:35 GMT
Thanks alot

On Tue, 05 Feb 2008 10:04:28 -0800, Analizer1 <dvs_bis@sbcglobal.net>
wrote:

> Hi I have a Long Number
> In a Byte[]
>
> Im not sure how to convert this Byte[] array to a Hex
> string

Well, the .NET way would be to use BitConverter to get the bytes into an
actual long value, and then use ToString("x") to convert to hex:

    byte[] rgb = { 1, 2, 3, 4, 5, 6, 7, 8 };
    string strHex = BitConverter.ToInt64(rgb, 0).ToString("x");

Pete
Bjørn Brox - 05 Feb 2008 19:05 GMT
Peter Duniho skrev:

>> Hi I have a Long Number
>> In a Byte[]
[quoted text clipped - 9 lines]
>
> Pete

Or as simple as strHex = BitConverter.ToString(rgb);

It depends on how you want to present the result, - this one puts a
whitespace between each hex pair, - great when debugging.

Signature

Bjørn Brox

Peter Duniho - 05 Feb 2008 19:49 GMT
>>> Hi I have a Long Number
>>> In a Byte[]
> [...]
>
> Or as simple as strHex = BitConverter.ToString(rgb);

That's incorrect.

The OP specifically said he's got data that should be interpreted as a  
long.  Your suggestion won't treat the data as a long.

> It depends on how you want to present the result, - this one puts a
> whitespace between each hex pair, - great when debugging.

But not so good when you want to display a 64-bit integer in hexadecimal.

BTW, it also doesn't put whitespace between hex pairs.  It puts hyphens.

Pete
Analizer1 - 05 Feb 2008 19:56 GMT
My Byte[] array consists of DirectoryServices Users Sid from the domain

I needed to Convert Each Byte to a Hex String , Then Concatenate each
following byte

below is a example...is the proper way, or is there a better way of
accomplishing this

uint uDec;

for (int x = 0; x < aBytes.GetLength(0); x++)
{

uDec = Convert.ToUInt32(aBytes[x]);

sHexId.Append(String.Format("{0:x2}",uDec));

}
Console.WriteLine(sHexId);

//it matches the hex id Sql Returns

Tks

On Tue, 05 Feb 2008 10:04:28 -0800, Analizer1 <dvs_bis@sbcglobal.net>
wrote:

> Hi I have a Long Number
> In a Byte[]
>
> Im not sure how to convert this Byte[] array to a Hex
> string

Well, the .NET way would be to use BitConverter to get the bytes into an
actual long value, and then use ToString("x") to convert to hex:

    byte[] rgb = { 1, 2, 3, 4, 5, 6, 7, 8 };
    string strHex = BitConverter.ToInt64(rgb, 0).ToString("x");

Pete
Jon Skeet [C# MVP] - 05 Feb 2008 20:16 GMT
> My Byte[] array consists of DirectoryServices Users Sid from the domain
>
[quoted text clipped - 12 lines]
> }
> Console.WriteLine(sHexId);

Well, a few points to note:

1) It's better style to declare variables as close to their use as
possible, so I'd declare uDec inside the loop rather than outside

2) I'd always use the Length property of an array instead of
GetLength(0)

3) When I don't care about the index, I use foreach instead of a for
loop

4) There's no need to convert to a uint to start with - just call
ToString on the byte...

5) ... or rather than formatting it and then appending it, use
AppendFormat

So, the resulting code would look something like:

StringBuilder builder = new StringBuilder(aBytes.Length*2);
foreach (byte b in aBytes)
{
   builder.AppendFormat("{0:x2}", b);
}
Console.WriteLine (builder.ToString());

Signature

Jon Skeet - <skeet@pobox.com>
http://www.pobox.com/~skeet   Blog: http://www.msmvps.com/jon.skeet
World class .NET training in the UK: http://iterativetraining.co.uk

Peter Duniho - 05 Feb 2008 20:17 GMT
> My Byte[] array consists of DirectoryServices Users Sid from the domain
>
[quoted text clipped - 17 lines]
>
> //it matches the hex id Sql Returns

If the code you posted provides the results you expected, then the "long"  
in your byte array is big-endian (i.e. not in the same format that an  
Intel-based .NET implementation would use).  Since BitConverter only works  
with little-endian, you'd either need a different bit-conversion class (if  
I recall correctly, Jon Skeet's utility library includes one) or do it  
manually as you've done.

Assuming that's the case, then the code you posted is reasonable, though  
not what I'd write.  I would use:

    string sHexId = "";
    foreach (byte b in aBytes)
    {
        sHexId += b.ToString("x2");
    }

There's no need to convert the byte to UInt32 first, nor do you need to  
call the String class's Format() method.  Of course, you may want to  
include a check in the code to ensure that the byte array is always 8  
bytes long.  Both your example and mine assume it is, and won't produce  
correct results if it's not.

Pete
Jeroen Mostert - 05 Feb 2008 20:55 GMT
> My Byte[] array consists of DirectoryServices Users Sid from the domain
>
[quoted text clipped - 15 lines]
> }
> Console.WriteLine(sHexId);

This works, but it's horribly inefficient. Of course, as long as you don't
need to do it a few hundred times every second, it doesn't matter. And even
if you do, this function probably won't be the bottleneck. Still, if you do
need this to be fast...

    const string hexDigits = "0123456789abcdef";

    int bl = aBytes.Length;
    char[] result = new char[bl * 2];
    for (int n = 0; n != bl; ++n) {
       result[n * 2 + 0] = hexDigits[aBytes[n] / 16];
       result[n * 2 + 1] = hexDigits[aBytes[n] % 16];
    }
    Console.WriteLine(new string(result));

This approach is over 50 times faster than yours. If you don't like to spend
that much keystrokes on it, even this oneliner is better (better still than
doing it yourself with a StringBuilder):

    Console.WriteLine(BitConverter.ToString(aBytes).Replace("-","");

Avoid String.Format() and its relatives in tight loops. If you need to do
positional replacement or locale-dependent formatting they're well worth it
(it's much more readable than gluing strings together yourself) but for
trivial conversions like these, repeated in a loop, they're not good.

Signature

J.

Analizer1 - 05 Feb 2008 21:19 GMT
this was my 1st Run at this type of conversion...
so your remarks are welcome...

I Want The Fastest and Tightest Conversion Possible

Tks

>> My Byte[] array consists of DirectoryServices Users Sid from the domain
>>
[quoted text clipped - 41 lines]
> it (it's much more readable than gluing strings together yourself) but for
> trivial conversions like these, repeated in a loop, they're not good.
Jon Skeet [C# MVP] - 05 Feb 2008 21:21 GMT
> this was my 1st Run at this type of conversion...
> so your remarks are welcome...
>
> I Want The Fastest and Tightest Conversion Possible

Why, out of interest? Just how many of these are you doing? Do you have
specific performance goals in mind? If you're getting the data from
directory services, that's likely to be much, much slower than any of
the conversion mechanisms given here.

It's always worth working out where performance really matters - and
I'd be very surprised if the conversion here ended up being a real
bottleneck.

Signature

Jon Skeet - <skeet@pobox.com>
http://www.pobox.com/~skeet   Blog: http://www.msmvps.com/jon.skeet
World class .NET training in the UK: http://iterativetraining.co.uk

Peter Duniho - 05 Feb 2008 23:39 GMT
>> this was my 1st Run at this type of conversion...
>> so your remarks are welcome...
[quoted text clipped - 5 lines]
> directory services, that's likely to be much, much slower than any of
> the conversion mechanisms given here.

Agreed.  Jeroen's version is an interesting exercise, but it should almost  
never be the case that one would actually need code written like that.

Writing code that's comparatively difficult to understand like that is  
only something you should do once you've tried a readable version and  
found it to be _the_ bottleneck performance-wise.

Pete
Jeroen Mostert - 05 Feb 2008 23:57 GMT
>>> this was my 1st Run at this type of conversion...
>>> so your remarks are welcome...
>>>
>>> I Want The Fastest and Tightest Conversion Possible

Oh dear. I sort of figured that would happen. But really, you probably don't.

>> Why, out of interest? Just how many of these are you doing? Do you have
>> specific performance goals in mind? If you're getting the data from
[quoted text clipped - 4 lines]
> almost never be the case that one would actually need code written like
> that.

I know I was being evil by talking about fast code for that (since people
get obsessed with "the fastest code" too easily), but I couldn't help
myself. I did point out that it's highly unlikely that formatting hexstrings
would be a bottleneck for anything. For one thing, you will presumably want
to *send* those hexstrings somewhere, and then you run smack-dab into I/O,
which tends to bottleneck a lot more.

> Writing code that's comparatively difficult to understand like that is
> only something you should do once you've tried a readable version and
> found it to be _the_ bottleneck performance-wise.

Now here's where I'm slightly offended at the suggestion of producing
unreadable code. Most C programmers would agree that my version is a paragon
of readability. :-D

Also, my comment on not using String.Format() in loops if it's obvious to
avoid still stands (and in this case, using BitConverter is pretty obvious,
and fast to boot as a bonus). Extensive string manipulation *can* become a
bottleneck fairly quickly, or even just a noticeable drag, and StringBuilder
isn't a cure-all for string performance problems.

Signature

J.

Peter Duniho - 06 Feb 2008 00:24 GMT
> [...]
> I know I was being evil by talking about fast code for that (since  
> people get obsessed with "the fastest code" too easily), but I couldn't  
> help myself. I did point out that it's highly unlikely that formatting  
> hexstrings would be a bottleneck for anything.

That's true.  :)  I didn't mean to imply that you yourself were suggesting  
such code would be useful here.

> Now here's where I'm slightly offended at the suggestion of producing  
> unreadable code. Most C programmers would agree that my version is a  
> paragon of readability. :-D

Uh.  Sure.  :)

> Also, my comment on not using String.Format() in loops if it's obvious  
> to avoid still stands (and in this case, using BitConverter is pretty  
> obvious, and fast to boot as a bonus). Extensive string manipulation  
> *can* become a bottleneck fairly quickly, or even just a noticeable  
> drag, and StringBuilder isn't a cure-all for string performance problems.

I wouldn't suggest using StringBuilder in this case anyway.  You've got a  
finite well-defined string length to deal with and I doubt there's a  
significant performance difference between the two.  Just appending String  
instances eight times is probably fine, even though it does result in a  
much larger number of data copies.

I disagree that there's anything wrong with using some sort of formatting  
in a loop here.  Sure, you can make that specific section of code perform  
much better by using a lookup table to generate digits.  But that is only  
useful if that specific section of code is where you spend the bulk of  
your time.  I think we all agree that's not likely to be the case here.

Rules like "don't format strings in loops" just leads to difficult-to-read  
code (C programmers notwithstanding :) ).  It's not a good rule, because  
there are so many good exceptions to it.

Pete
Jeroen Mostert - 06 Feb 2008 00:52 GMT
>> Also, my comment on not using String.Format() in loops if it's obvious
>> to avoid still stands (and in this case, using BitConverter is pretty
[quoted text clipped - 7 lines]
> String instances eight times is probably fine, even though it does
> result in a much larger number of data copies.

Well, I thought we were talking about the general case of turning an
arbitrary array of bytes into a string. Sure, if you're limited to eight
bytes exactly, then you don't need a loop to begin with. But then my point
also vanishes.

> I disagree that there's anything wrong with using some sort of
> formatting in a loop here.

The point is that String.Format() is expensive compared to other string
operations. In most cases, it's a cost you'll want to pay, because being
able to write

    String.Format("There's {0} foozits out of {1} remaining with an average
processing time of {2} per item", remaining, total, averageTime);

is a lot more convenient and readable than doing the same with
concatenation. Especially when you combine this with locale-specific
formatting, precision modifiers and last but certainly not least localization.

And if you're doing *that* in a loop, then it's probably because it's
exactly what you need to do, and avoiding it won't buy you anything but
missed deadlines and angry customers.

> Rules like "don't format strings in loops" just leads to
> difficult-to-read code (C programmers notwithstanding :) ).  It's not a
> good rule, because there are so many good exceptions to it.

That's why I'd never suggest something like that as a general rule, it's
like saying "don't use useful things because they don't work for free", and
nothing is ever for free. And, sure, the usual caveats about "don't optimize
(yet)" apply. But a programmer should be able to understand and explain why
calling StringBuilder.AppendFormat() to repeatedly string two hex digits
together is a potentially inefficient solution, even if it's not a
bottleneck in practice (that is, it's not *too* inefficient so it doesn't
matter).

And this *particular* problem (assuming we're going back to the general case
of arbitrarily long arrays) happens to be better solved with BitConverter,
not only because it's faster, but because it absolves you from writing the
actual code! Reuse and less potential for errors, what's not to like? Hence
the "if it's obvious to avoid" clause.

Signature

J.

Ben Voigt [C++ MVP] - 06 Feb 2008 01:19 GMT
>> Writing code that's comparatively difficult to understand like that is
>> only something you should do once you've tried a readable version and
[quoted text clipped - 3 lines]
> unreadable code. Most C programmers would agree that my version is a
> paragon of readability. :-D

If we're gonna argue the point... any "real" C programmer would favor this
version:

    static const string hexDigits = "0123456789abcdef";

    int l = aBytes.Length;
    char* from = aBytes + l;
    l <<= 1;
    char[] result = new char[l];
    try {
        for (;;) {
            result[--l] = hexDigits[0x0F & *(--from)];
            result[--l] = hexDigits[*from >> 4];
        }
    }
    finally {
        Console.WriteLine(result); // no need to make a string
        // let someone who cares handle the exception
    }

as a special bonus, due to the unorthodox method of leaving the loop, it can
be unrolled by any arbitrary factor without regard for whether the input
array length is a multiple of the unrolling factor

P.S. Using the digit one and lowercase L in the same statement is mandatory
Analizer1 - 06 Feb 2008 17:56 GMT
i was able to read your sample code..
thanks again, and i agree about long loops.

if  i have a long loop ..i tend to do as little stack pops as i can

tks

>>>> this was my 1st Run at this type of conversion...
>>>> so your remarks are welcome...
[quoted text clipped - 33 lines]
> become a bottleneck fairly quickly, or even just a noticeable drag, and
> StringBuilder isn't a cure-all for string performance problems.
Analizer1 - 06 Feb 2008 17:52 GMT
probrably do between 100 and 200 thousand a day
we use the SID for Security Reasons

>> this was my 1st Run at this type of conversion...
>> so your remarks are welcome...
[quoted text clipped - 9 lines]
> I'd be very surprised if the conversion here ended up being a real
> bottleneck.
Jon Skeet [C# MVP] - 06 Feb 2008 18:43 GMT
> probrably do between 100 and 200 thousand a day

Is that all? On my laptop - hardly a server class machine - I can
convert 16 bytes 200,000 times in about 1500ms using the code I posted.
(I haven't tested other code - it may well be faster.)

In other words, this is likely to account for less than 0.002% of the
time of the app.

Do you still think you need the "fastest and tightest conversion
possible"?

Signature

Jon Skeet - <skeet@pobox.com>
http://www.pobox.com/~skeet   Blog: http://www.msmvps.com/jon.skeet
World class .NET training in the UK: http://iterativetraining.co.uk

Analizer1 - 06 Feb 2008 19:24 GMT
its not the number, hell it could be 3 million times a day...
our system..goes to sql, then domain , then back to the code to create this
hexstring....

Im just trying to get rid of some of the other hits...

it dont matter if its 1 call or 10 million calls...
i prefer the most efficient way....
Hence i asked for your advice

thanks

>> probrably do between 100 and 200 thousand a day
>
[quoted text clipped - 7 lines]
> Do you still think you need the "fastest and tightest conversion
> possible"?
Peter Duniho - 06 Feb 2008 19:31 GMT
> its not the number, hell it could be 3 million times a day...

Even if you called it 3 million times, that would only be 22 seconds out  
of the entire day spent in that part of the code.  Which brings the  
proportional cost all the way up to a whopping 0.03% of the time of the  
application.

> our system..goes to sql, then domain , then back to the code to create  
> this
> hexstring....
>
> Im just trying to get rid of some of the other hits...

Which other hits?  If you want to make your application faster, figure out  
a way to avoid having to talk to the SQL server so often.  That's likely  
to reap genuine, useful benefits.

> it dont matter if its 1 call or 10 million calls...
> i prefer the most efficient way....
> Hence i asked for your advice

And you got it.  Which is to not waste time on optimizing this part of the  
code.  Make it easy to maintain, so that it doesn't cost a _human_ a lot  
of time.  Don't worry about the time the _computer_ spends on the code,  
worry about the time the human does.

Even if you assume that you can eliminate 30 seconds a day by modifying  
this part of the code, in an entire year you've only saved three hours of  
computing time.  Now compare that to the cost of a human trying to  
maintain the code, taking into account the fact that a human costs a _lot_  
more than a computer, for a given amount of time spent on a problem.

> thanks

You're welcome.

Pete
Jon Skeet [C# MVP] - 06 Feb 2008 21:55 GMT
> its not the number, hell it could be 3 million times a day...

Ooh, a shocking 15 seconds a day (if you only use a single core on a
laptop)...

> our system..goes to sql, then domain , then back to the code to create this
> hexstring....

And you really think *this* bit will be the bottleneck?

> Im just trying to get rid of some of the other hits...
>
> it dont matter if its 1 call or 10 million calls...

Yes, it really does. *If* this section of code ends up as a bottleneck,
*that's* the time to look at the efficiency of it.

> i prefer the most efficient way....
> Hence i asked for your advice

My advice is to code for the most *readable* solution rather than the
fastest. Then you can analyse the performance of the whole system, work
out the bottlenecks, and micro-optimise them. You can do that
confidently and easily, because all the code will be reasonably easy to
understand - because you won't have optimised inappropriately.

Signature

Jon Skeet - <skeet@pobox.com>
http://www.pobox.com/~skeet   Blog: http://www.msmvps.com/jon.skeet
World class .NET training in the UK: http://iterativetraining.co.uk

Arne Vajhøj - 11 Feb 2008 02:28 GMT
> it dont matter if its 1 call or 10 million calls...
> i prefer the most efficient way....

If you are doing this on your own time because you find
it interesting as an intellectual exercise, then just
proceed.

Just don't do it on company time. Efficiency in company
world are measured in dollars. Spending many hours creating
some special fast code that will also require maintenance
programmers to spend extra hours understanding the
code to save 100 dollars worth of CPU power is bad business.

Arne
Arne Vajhøj - 11 Feb 2008 03:01 GMT
> I Want The Fastest and Tightest Conversion Possible

Try and run the code below for some ideas.

Arne

==============================================

using System;
using System.Text;

namespace E
{
    public class HexFun
    {
        private static char[] HEXDIGITS = "0123456789ABCDEF".ToCharArray();
        public delegate string ToHex(byte[] b);
        public static string ToHex1(byte[] b)
        {
            return BitConverter.ToString(b).Replace("-", "");
        }
        public static string ToHex2(byte[] b)
        {
            StringBuilder sb = new StringBuilder(2 * b.Length);
            for(int i = 0; i < b.Length; i++)
            {
                sb.Append(b[i].ToString("X2"));
            }
            return sb.ToString();
        }
        public static string ToHex3(byte[] b)
        {
            StringBuilder sb = new StringBuilder(2 * b.Length);
            for(int i = 0; i < b.Length; i++)
            {
                sb.Append(HEXDIGITS[b[i] / 16]);
                sb.Append(HEXDIGITS[b[i] % 16]);
            }
            return sb.ToString();
        }
        public static string ToHex4(byte[] b)
        {
            StringBuilder sb = new StringBuilder(2 * b.Length);
            for(int i = 0; i < b.Length; i++)
            {
                sb.Append(HEXDIGITS[b[i] >> 4]);
                sb.Append(HEXDIGITS[b[i] & 0x0F]);
            }
            return sb.ToString();
        }
        public static string ToHex5(byte[] b)
        {
            char[] res = new char[2 * b.Length];
            for(int i = 0; i < b.Length; i++)
            {
                res[2 * i] = HEXDIGITS[b[i] >> 4];
                res[2 * i + 1] = HEXDIGITS[b[i] & 0x0F];
            }
            return new string(res);
        }
        private static char[] UH;
        private static char[] LH;
        static HexFun()
        {
            UH = new char[256];
            LH = new char[256];
            for(int i = 0; i < 256; i++)
            {
                UH[i] = HEXDIGITS[i / 16];
                LH[i] = HEXDIGITS[i % 16];
            }
        }
        public static string ToHex6(byte[] b)
        {
            char[] res = new char[2 * b.Length];
            for(int i = 0; i < b.Length; i++)
            {
                res[2 * i] = UH[b[i]];
                res[2 * i + 1] = LH[b[i]];
            }
            return new string(res);
        }
        public static void Test(byte[] b, int n, ToHex th)
        {
            DateTime dt1 = DateTime.Now;
            for(int i = 0; i < n; i++)
            {
                th(b);
            }
            DateTime dt2 = DateTime.Now;
            Console.WriteLine("{0:f4}", (dt2 - dt1).TotalSeconds);
        }
        private const int NBYT = 8;
        private const int NREP = 4000000;
        private static Random rng = new Random();
        public static void Main(string[] args)
        {
            byte[] tst = { 1, 2, 3, 4, 255 };
            Console.WriteLine(ToHex1(tst));
            Console.WriteLine(ToHex2(tst));
            Console.WriteLine(ToHex3(tst));
            Console.WriteLine(ToHex4(tst));
            Console.WriteLine(ToHex5(tst));
            Console.WriteLine(ToHex6(tst));
            byte[] b = new byte[NBYT];
            rng.NextBytes(b);
            Test(b, NREP, ToHex1);
            Test(b, NREP, ToHex2);
            Test(b, NREP, ToHex3);
            Test(b, NREP, ToHex4);
            Test(b, NREP, ToHex5);
            Test(b, NREP, ToHex6);
            Console.ReadKey();
        }
    }
}
Rene - 05 Feb 2008 19:42 GMT
You can also call the ToString() directly in the byte variable:

byte[] ba = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 15, 255 };

foreach(byte b in ba)
{
   string hex = b.ToString("X");
   Console.WriteLine( (hex.Length == 1 ? "0" : "") + hex );
}

Console.Read();

--------------------------------------------

> Hi I have a Long Number
> In a Byte[]
[quoted text clipped - 3 lines]
>
> thanks
Jon Skeet [C# MVP] - 05 Feb 2008 19:46 GMT
> You can also call the ToString() directly in the byte variable:
>
[quoted text clipped - 5 lines]
>     Console.WriteLine( (hex.Length == 1 ? "0" : "") + hex );
> }

If you're going to do that, you might as well use the format specifier
to get the length right:

string hex = b.ToString("X2");
Console.WriteLine(hex);

Signature

Jon Skeet - <skeet@pobox.com>
http://www.pobox.com/~skeet   Blog: http://www.msmvps.com/jon.skeet
World class .NET training in the UK: http://iterativetraining.co.uk

Peter Duniho - 05 Feb 2008 19:55 GMT
> You can also call the ToString() directly in the byte variable:
>
[quoted text clipped - 7 lines]
>
> Console.Read();

And in addition to what Jon wrote, the above code again does not display  
an array containing a 64-bit integer.  It simply emits a series of bytes  
as hexadecimal pairs.

Heck, the sample byte array isn't even a valid 64-bit integer.  It's _two_  
64-bit integers, at best.

Pete
Rene - 05 Feb 2008 20:59 GMT
ah, I didn't paid attention to the "Hi I have a *Long *Number"..... such a
small oversight :)

I thought that all he wanted to do was to show hex of a byte array.

This is not the first time nor the last time I will make such mistakes!!

Cool info about the "X2" format.

> You can also call the ToString() directly in the byte variable:
>
[quoted text clipped - 7 lines]
>
> Console.Read();

And in addition to what Jon wrote, the above code again does not display
an array containing a 64-bit integer.  It simply emits a series of bytes
as hexadecimal pairs.

Heck, the sample byte array isn't even a valid 64-bit integer.  It's _two_
64-bit integers, at best.

Pete
Peter Duniho - 05 Feb 2008 23:40 GMT
> ah, I didn't paid attention to the "Hi I have a *Long *Number"..... such  
> a
> small oversight :)
>
> I thought that all he wanted to do was to show hex of a byte array.

Well, for what it's worth, it turns out his original question was  
inaccurate.  So you weren't actually far off after all.  :)

> This is not the first time nor the last time I will make such mistakes!!

Been there, done that.  :)

Pete
Analizer1 - 05 Feb 2008 21:22 GMT
Thanks for all your Responses
I will work with your examples

Mine was just the 1st run at converting The Directoryservices User SID to a
Hex String

Thank you very much

> Hi I have a Long Number
> In a Byte[]
[quoted text clipped - 3 lines]
>
> thanks

Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.