Im looking at some code in java, and I see lots of code using byte[], what is the equivalent to all of this in NodeJS / Javascript?
Here is the piece of code im looking at, Input is any base64 string
byte[] byteArray = Base64.decode(input, 0);
byte[] ivBytes = new byte[16];
System.arraycopy(byteArray, 0, ivBytes, 0, 16);
byte[] encryptedTextBytes = new byte[(byteArray.length - ivBytes.length)];
System.arraycopy(byteArray, 16, encryptedTextBytes, 0, encryptedTextBytes.length);
Thanks for helping me out.
byte is one of several primitive number data types in Java. Primitive data types specify the size and type of variable values. For instance, a byte takes the size of 1 byte and can store whole numbers from -128 to 127. Similarly short takes 2 bytes, int takes 4 bytes... so on and so forth. Refer this page for a complete list of data types with their respective sizes.
Unlike Java, Javascript has only one type of number and it stores numbers as double precision floating point values using 64 bits. So technically, there is no equivalent number type in JavaScript to the Java number types byte, short, int, long and float. We use var, let and const to declare variables in JavaScript and all those variables will be equivalent to double data type in Java.
Related
This may seem like an easy question, but I'm so confused.
byte[] bArray = new byte[]{(byte) (0x80 & 0xff)};
System.out.println(bArray[0]);
and my output is -128. Why?
How can I rewrite this so that the byte array contains 128?
I thought that the 0xff made it unsigned.
Thanks for your help!
I thought that the 0xff made it unsigned.
Well, it does, sort of - it promotes it to an int, and keeps just the last 8 bits.
However, you're then casting the result of that back to a byte, and a byte in Java is always signed. (It's annoying, but it's the way it is.) So you might as well just have written:
byte[] bArray = { (byte) 0x80 };
The result would be exactly the same.
You're storing the bit pattern you want to store (10000000) so if you're transmitting this elsewhere, you don't need to worry... it's just when you're viewing it as a byte in Java that it's annoying.
Value range of byte according Java Language Specification 4.2.1
For byte, from -128 to 127, inclusive
so there is no way (in Java) that a byte will hold (byte) 128.
You can cast the byte to an int and apply & 0xff to get the unsigned representation of the byte (as an int). But if you cast it back to an byte it will again be interpreted as being a signed value between -128 and 127...
If you are only concerned with printing:
System.out.println(bArray[0] & 0xff);
or, for hexadecimal
System.out.printf("0x%02x\n", bArray[0]);
My answer is attached in the big picture
I have this code in C#
byte[] t = {6, 250, 215}.
But in Java is
byte[] t = {6, -6, -41}.
How to solve this problem?
How to solve this problem
the 1st is read about how java represents data types..:
byte: The byte data type is an 8-bit signed two's complement integer.
It has a minimum value of -128 and a maximum value of 127 (inclusive).
The byte data type can be useful for saving memory in large arrays,
where the memory savings actually matters. They can also be used in
place of int where their limits help to clarify your code; the fact
that a variable's range is limited can serve as a form of
documentation.
as #bradimus statements, java's byte is an 8-bits 2 complement signed int
but in C# you will never see a negative byte value
Hint:
if you consider to make a conversion...
-6 in java can be 256+(-6) = 250 in C#
and carefully consider the max and min in a java-byte if you need to convert from C# to java....
I have the following piece of code in C++
int magic;
stream.read(&magic, sizeof(magic));
Which stores the value of magic from an array of bytes.
I want to migrate it to Java, so far I have this:
int magic = stream[0];
But it is not working. I think that it is due to the length of the ints in Java and C++. Shall I use two bytes in the Java part to retrieve the proper magic number?
byte[] stream = ...
ByteBuffer buf = ByteBuffer.wrap(stream);
buf.order(ByteOrder.LITTLE_ENDIAN);
int magic = buf.readInt();
See ByteBuffer. A java int is always 4 bytes signed, and per default java uses a BIG_ENDIAN byte order, so you might want to set a reversed order.
I am attepmting to load a .ply file into a vbo, and draw it in lwjgl + java. The file loads correctly and all the data is parsed correctly, the only problem is thatit is a model with A LOT of indices (faces). The indices are stored in a byte[] array. In java (and probably everywhere else), bytes can only go up to 128, but the indices required to draw the mesh well surpass 128 in value, so I get this error.
Exception in thread "main" java.lang.NumberFormatException: Value out of range. Value:"128" Radix:10
at java.lang.Byte.parseByte(Byte.java:151) at java.lang.Byte.parseByte(Byte.java:151)
at game_3d.ModelLoader.loadGeometry(ModelLoader.java:333)
at game_3d.Game_3D.setupGeometry(Game_3D.java:399)
at game_3d.Game_3D.<init>(Game_3D.java:81)
at game_3d.Game_3D.main(Game_3D.java:70)
When I tried to use an int[] array, the model didn't draw correctly. I don't know how or if you even can increase the max value of a byte in a byte[] array, I already tried experimenting with the radix, but the minimum was 10 (which gets me 128).
Well, a byte is a byte. It can only have 256 different values. There is a slight oddity related to the index range when using Java OpenGL bindings. Since Java does not have unsigned data types, the maximum supported value may seem to be 127. But since the arrays of byte values will be passed through to native code, which will treat them as unsigned values, the maximum number of vertices you can address with byte indices is in fact 255.
For example, say you have a value of 160 as an int, and cast it to a byte value for storage in a byte[] array. If you look at the byte value in Java, it will appear to have changed to -96 (160 - 256). But once native code sees the value, and interprets it as an unsigned byte, it will in fact be 160.
See this question for more details about casting int to byte in Java: How are integers cast to bytes in Java?.
Now, if you need more than 256 vertices, you will have to use an index type that supports a larger range. That will work just fine as long as you're consistent:
Using short as the type of your index array in Java, you can address 65,536 vertices. The matching type argument of the glDrawElements() call is GL_UNSIGNED_SHORT.
Using int as the type of your index array in Java, you can address... a lot of vertices (2 ^ 32, which is more than 4 billion). The matching type argument of the glDrawElements() call is GL_UNSIGNED_INT.
I apologies if the title of this question is not clear, but i cannot figure out the best way to describe my predicament in so few words.
I am writing a communication framework between java and C# using sockets and byte by byte transfer of information.
I have ran into an issue which has been confusing me for a good few hours now. As you hopefully know. java's byte base type is signed, meaning it can store -128 to +127 if you were to represent it in integer form. C# however, uses unsigned bytes, meaning that it store 0-255 in integer form.
This is where i am encountering the issue. If need to send some bytes of information from my c# client to my java server, i use the following code:
C#:
MemoryStream stream;
public void write(byte[] b, int off, int len) {
stream.Write(b, off, len);
}
Java:
DataInputStream in;
public int read(byte[] b, int off, int len) throws IOException{
in.read(b, off, len));
}
As you can see these are very very similar pieces of code that when used within their own languages will produce predictable results. However, due to the differences in the signing these will produce unusable data.
I.e if i send 255 from my c# client to java server, I will receive a value of -1 on the java server. This is because both of those values are represented of these 8 bits: 11111111
Preferably in order to solve this problem I would need to use the following code, using sbyte, c#'s signed byte.
C#:
MemoryStream stream;
public void write(sbyte[] b, int off, int len) {
//Code to change sbyte into a byte but keeping it in the form in which java will understand
stream.Write(b, off, len);
}
I basically need to store java's representation of a signed byte inside an unsigned C# byte in order to send that byte across to the server. I will also need to do this in reverse to get an sbyte out of a byte received from my java server.
I have tried numerous ways in which to do this with no success. If anyone has any idea as to how i can go about this i would be GREATLY appreciative.
You basically don't need to do anything except stop thinking about bytes as numbers. Think of them as 8 bits, and Java and C# are identical. It's rare that you really want to consider a byte as a magnitude - it's usually just binary data like an image, or perhaps encoded text.
If you want to send the byte 10100011 across from Java to C# or vice versa, just do it in the most natural way. The bits will be correct, even if the byte values will be different when you treat them as numbers.
It's not entirely clear what data you're actually trying to propagate, but in 99.9% of cases you can just treat the byte[] as opaque binary data, and transmit it without worrying.
If you do need to treat the bytes as magnitudes, you need to work out which range you want. It's easier to handle the Java range, as C# can support it with sbyte[]... but if you want the range 0-255, you just need to convert the byte to an int on the Java side and mask it with the bottom 8 bits:
byte b = ...;
int unsigned = b & 0xff;
If you really need to treat byte[] as sbyte[] or vice versa on C#, you can use a little secret: even though C# doesn't allow you to convert between the two, the CLR does. All you need to do is go via a conversion of the reference to object to fool the C# compiler into thinking it might be valid - otherwise it thinks it knows best. So this executes with no exceptions:
byte[] x = new byte[] { 255 };
sbyte[] y = (sbyte[]) (object) x;
Console.WriteLine(y[0]); // -1
You can convert in the other direction in exactly the same way.