212

I need to convert an int to a byte[] one way of doing it is to use BitConverter.GetBytes(). But im unsure if that matches the following specification:

An XDR signed integer is a 32-bit datum that encodes an integer in the range [-2147483648,2147483647]. The integer is represented in two's complement notation. The most and least significant bytes are 0 and 3, respectively. Integers are declared as follows:

Source: RFC1014 3.2

How could i do a int to byte transformation that would satisfy the above specification?

Peter
  • 37,042
  • 39
  • 142
  • 198

9 Answers9

264

The RFC is just trying to say that a signed integer is a normal 4-byte integer with bytes ordered in a big-endian way.

Now, you are most probably working on a little-endian machine and BitConverter.GetBytes() will give you the byte[] reversed. So you could try:

int intValue;
byte[] intBytes = BitConverter.GetBytes(intValue);
Array.Reverse(intBytes);
byte[] result = intBytes;

For the code to be most portable, however, you can do it like this:

int intValue;
byte[] intBytes = BitConverter.GetBytes(intValue);
if (BitConverter.IsLittleEndian)
    Array.Reverse(intBytes);
byte[] result = intBytes;
Qantas 94 Heavy
  • 15,750
  • 31
  • 68
  • 83
paracycle
  • 7,665
  • 1
  • 30
  • 34
  • 9
    Or use ToArray. byte[] result = BitConverter.GetBytes(intValue).Reverse().ToArray(); – Lars Truijens Nov 20 '11 at 21:05
  • 2
    why the last line `byte[] result = intBytes;` ? isn't `intBytes` already the array you want? – derHugo Apr 15 '19 at 08:46
  • 3
    @derHugo That's correct, `result` is redundant in this code piece. However, I felt that it was more pedagogical to explicitly show the reader what the result was than assuming that they can figure out that the result is contained in some variable named `intBytes`. Besides, doing the assignment is cheap since it does not copy the memory nor allocate new memory, it just adds a new name to the already allocated array. So why not do it? – paracycle May 07 '19 at 15:54
54

Here's another way to do it: as we all know 1x byte = 8x bits and also, a "regular" integer (int32) contains 32 bits (4 bytes). We can use the >> operator to shift bits right (>> operator does not change value.)

int intValue = 566;

byte[] bytes = new byte[4];

bytes[0] = (byte)(intValue >> 24);
bytes[1] = (byte)(intValue >> 16);
bytes[2] = (byte)(intValue >> 8);
bytes[3] = (byte)intValue;

Console.WriteLine("{0} breaks down to : {1} {2} {3} {4}",
    intValue, bytes[0], bytes[1], bytes[2], bytes[3]);
Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Maciek
  • 19,435
  • 18
  • 63
  • 87
29

BitConverter.GetBytes(int) almost does what you want, except the endianness is wrong.

You can use the IPAddress.HostToNetwork method to swap the bytes within the the integer value before using BitConverter.GetBytes or use Jon Skeet's EndianBitConverter class. Both methods do the right thing(tm) regarding portability.

int value;
byte[] bytes = BitConverter.GetBytes(IPAddress.HostToNetworkOrder(value));
Community
  • 1
  • 1
dtb
  • 213,145
  • 36
  • 401
  • 431
19

The other way is to use BinaryPrimitives like so

byte[] intBytes = BitConverter.GetBytes(123); int actual = BinaryPrimitives.ReadInt32LittleEndian(intBytes);

Denis
  • 833
  • 3
  • 12
  • 22
7

Why all this code in the samples above...

A struct with explicit layout acts both ways and has no performance hit.

Update: Since there's a question on how to deal with endianness I added an interface that illustrates how to abstract that. Another implementing struct can deal with the opposite case

public interface IIntToByte
{
    Int32 Int { get; set;}

    byte B0 { get; }
    byte B1 { get; }
    byte B2 { get; }
    byte B3 { get; }
}

[StructLayout(LayoutKind.Explicit)]
public struct IntToByteLE : UserQuery.IIntToByte
{
    [FieldOffset(0)]
    public Int32 IntVal;

    [FieldOffset(0)]
    public byte b0;
    [FieldOffset(1)]
    public byte b1;
    [FieldOffset(2)]
    public byte b2;
    [FieldOffset(3)]
    public byte b3;

    public Int32 Int {
        get{ return IntVal; }
        set{ IntVal = value;}
    }

    public byte B0 => b0;
    public byte B1 => b1;
    public byte B2 => b2;
    public byte B3 => b3; 
}
Sten Petrov
  • 10,943
  • 1
  • 41
  • 61
  • 2
    How would you use this? and secondly would you get the same result even is you run this on 'big-endian' and on 'little-endian'. – Peter Mar 05 '18 at 13:37
  • @Peter here's an update. It should still perform better than shifts – Sten Petrov Mar 12 '18 at 07:08
  • yup. Basically a c++ union implemented as c# structs. This is super-fast and is good for packing and unpacking all kinds of things that don't fit nicely into the bitconverter/endian problem solutions. IIRC, NAudio uses this approach to very good effect. – Craig.Feied May 18 '18 at 18:12
  • 1
    This is the best answer and it's kinda sad that this isn't the top but just tells you something about the state of programming in 2019 – John Evans Dec 06 '19 at 12:57
3

When I look at this description, I have a feeling, that this xdr integer is just a big-endian "standard" integer, but it's expressed in the most obfuscated way. Two's complement notation is better know as U2, and it's what we are using on today's processors. The byte order indicates that it's a big-endian notation.
So, answering your question, you should inverse elements in your array (0 <--> 3, 1 <-->2), as they are encoded in little-endian. Just to make sure, you should first check BitConverter.IsLittleEndian to see on what machine you are running.

Marcin Deptuła
  • 11,789
  • 2
  • 33
  • 41
2

If you want more general information about various methods of representing numbers including Two's Complement have a look at:

Two's Complement and Signed Number Representation on Wikipedia

Eric J.
  • 147,927
  • 63
  • 340
  • 553
0
using static System.Console;

namespace IntToBits
{
    class Program
    {
        static void Main()
        {
            while (true)
            {
                string s = Console.ReadLine();
                Clear();
                uint i;
                bool b = UInt32.TryParse(s, out i);
                if (b) IntPrinter(i);
            }
        }

        static void IntPrinter(uint i)
        {
            int[] iarr = new int [32];
            Write("[");
            for (int j = 0; j < 32; j++)
            {
                uint tmp = i & (uint)Math.Pow(2, j);

                iarr[j] = (int)(tmp >> j);
            }
            for (int j = 32; j > 0; j--)
            {
                if(j%8==0 && j != 32)Write("|");
                if(j%4==0 && j%8 !=0) Write("'");
                Write(iarr[j-1]);
            }
            WriteLine("]");
        }
    }
}```
-2
byte[] Take_Byte_Arr_From_Int(Int64 Source_Num)
{
   Int64 Int64_Num = Source_Num;
   byte Byte_Num;
   byte[] Byte_Arr = new byte[8];
   for (int i = 0; i < 8; i++)
   {
      if (Source_Num > 255)
      {
         Int64_Num = Source_Num / 256;
         Byte_Num = (byte)(Source_Num - Int64_Num * 256);
      }
      else
      {
         Byte_Num = (byte)Int64_Num;
         Int64_Num = 0;
      }
      Byte_Arr[i] = Byte_Num;
      Source_Num = Int64_Num;
   }
   return (Byte_Arr);
}
  • please add more explanation – Gregor Doroschenko Feb 21 '18 at 22:51
  • Thanks for the answer, why did you choose to write a new implementation instead of using the https://stackoverflow.com/a/1318948/58553 ? (are there any pro or cons with your solution) – Peter Feb 22 '18 at 07:37
  • In case when project need to be developed with not only one language, it can be useful realize code similarity between languages in situation when identical ideas must be implemented. This way may help with mistakes catching. Sure using ‘c#’ function ‘BitConverter.GetBytes’ with ‘Endian’ checking that all what needed in most cases. And more, in some situation may happened use conversion not only to Int32(4 bytes) or Int64(8 bytes) but to other number of bytes. Thanks. – Valery Rode Feb 22 '18 at 22:52
  • This isn't really universally usable at all... it always returns an 8-byte array, which brings a lot of extra work with input values that aren't 64-bit ints. I'd logically want a 2-byte array when converting an `Int16`. – Nyerguds Apr 20 '18 at 07:24