xor ^ on two byte arrays

[Thomas Griffith]

Hello. If you have a minute, why does this throw a compile lossy conversion from int to byte error on the xor carrot? It's two byte arrays (1s and 0s, right?) thank you.

String string1="Hello";
String string2="World";

byte[] bytes1=string1.getBytes();
byte[] bytes2=string2.getBytes();

byte [] xor_guy=new byte[bytes1.length];
for (int i=0;i<byte1.length;i++) {
    xor_guy[i]=bytes1[i] ^ bytes2[i];
}

[Mike Simmons]

OK, I see you fixed several other errors I saw when I used the first version of code you posted.  The remaining issue is that most (I think all) binary operators upcast their result to at least int, unless one of the operands is long or double so the larger return type is required.  In this case, the operands are both bytes, but the result is an int.  I'm not sure why they did it that way, but they did.  int is basically the default type that Java uses whenever it can.  So you just have to get used to downcasting to the smaller type if that's what you need.

    xor_guy[i]=(byte) (bytes1[i] ^ bytes2[i]);

[Thomas Griffith]

I apologize, I was typing the code from one pc to the other instead of just copying/pasting so I noticed some typos initially.

yeah, I saw examples around where they cast the resultant as a byte despite the byte operands but can't figure out why. It sounds like it's just a thing they did...ill mess around with that some more.

One thing I wanted to ask about, after the XOR carrot operation, I convert the resultant byte[] xor_guy to a String...

String string1="Hello";
String string2="World";
 
byte[] bytes1=string1.getBytes();
byte[] bytes2=string2.getBytes();
 
byte [] xor_guy=new byte[bytes1.length];
for (int i=0;i<byte1.length;i++) {
xor_guy[i]=byte(bytes1[i] ^ bytes2[i]);
}

//NEW STUFF
String xor_guy_string=new String (xor_guy);
System.out.println(xor_guy_string + " and it's length - " + xor_guy_string.length());

<br /> <br /> However, xor_guy_string comes out really weird, with non standard characters, like upside down triangles, deck of cards stuff like clubs, hearts, etc and really long white space which doesn't appear to be counted in the length. Is there an encode/decode needed to get this to a "usable" string , with standard keyboard chars, in a text editor (and back)? <br /> >

[Mike Simmons]

It depends what you want to use the string for.  The byte[] array is binary data, and after these XOR operations it's no probably longer following the UTF-8 or any other standard character encoding.  Is there any reason to think that this string would mean something?  If you just want to render some sort of printable string from the byte[], you can use something like Base64 encoding:

    String encoded = Base64.getEncoder().encodeToString(xor_guy);
    System.out.println("encoded: " + encoded);

This is potentially useful if you need to pass binary data in a text-based format and decode it later.  Don't know if that's helpful for you though...

[Norm Radder]

Is there an encode/decode needed to get this to a "usable" string

Try this:

    System.out.println(Arrays.toString(xor_guy));

[Thomas Griffith]

Mike Simmons wrote:This is potentially useful if you need to pass binary data in a text-based format and decode it later.  Don't know if that's helpful for you though...

yes, it is. I've been messing around with obfuscation approaches and I actually did some base64 encoding/decoding on text before the xor carrot stuff, just throwing one on top of the other, I guess and following your adivce, I was able to encode and decode the resultant xor_guy_string in base64 (getting a UTF-8 string after the encode then the ugly queen of hears, clubs stuff again after the decode). thank you again.

Norm Radder wrote:

Is there an encode/decode needed to get this to a "usable" string

Try this:

    System.out.println(Arrays.toString(xor_guy));

that's interestng, it returns an array of ints with the number of array elements matching the xor_guy_string length. So each weird char, like the club or diamond, matches up to an int somehow?

[Norm Radder]

 So each weird char, like the club or diamond, matches up to an int somehow?

Everything stored in a computer's memory is contained in a byte (8 bits).  How those bytes are represented on the screen depends on the software presenting them.

[Mike Simmons]

The details depend on the system you're on, and what character encoding it uses by default.  Try this:

    System.out.println(Charset.defaultCharset());

That defaultCharset() is what's used implicitly by your new String(xor_guy) call.  That will determine the rules of how the bytes in the array correspond to characters.  It may be one byte per character, or it may be something more complicated.  Often it's a mix where standard Roman characters and Arabic numerals are  rendered as you would expect, but more "exotic" characters (from a US / European perspective) are one character per two or three bytes.

[Paul Clapham]

In other words, producing basically random bytes and trying to figure out what you're seeing when you pretend they are chars and display them as such, that doesn't have much point to it. Normally when you see those characters it means you have done something wrong. (Like misinterpreting bytes as chars.)

[Campbell Ritchie]

Mike Simmons wrote:. . . binary operators upcast their result to at least int. . . .

I think the idea is that you don't as a routine use bytes or chars or shorts for arithmetic. You use ints, longs, doubles, and floats. Though, if I had my way, I would consign the float datatype to some sort of cyber‑Hades.
So the JVM automatically promotes the operands to whichever of the latter four datatypes is wide enough to contain the result. [edit] This promotion (or upcast) is done before the arithmetic. I went through the JLS (=Java® Language Specification) starting here, and it appears that such promotion is applied for every operator specifically taking (primitive) numbers. There are different promotion rules for ?:.