We Keep Coding

Unpredictable behaviour of JTextField removing ASCII char

I have been working on some application which encrypts data using 3DES algorithm, but when I tried to make some UI for it I faced some really strange behaviour, after I encrypt data and represent it back again as ASCII I get:
String encryptedASCII = ;nÆ«»Ë?&]º²ÿ
and following array of bytes for it:
[-62, -118, 59, 110, -61, -122, -62, -85, -62, -69, -61, -117, 4, 7, -62, -105, 63, 38, 93, -62, -70, -62, -78, -61, -65]
But when I use:
textField.setText(encryptedASCII)
and once again get it from there to decrypt:
textField.getText()
I got:
;nÆ«»Ë?&]º²ÿ
and bytes for it:
[-62, -118, 59, 110, -61, -122, -62, -85, -62, -69, -61, -117, -62, -105, 63, 38, 93, -62, -70, -62, -78, -61, -65]
What makes it two missing bytes [4, 7] from the array of bytes which I got before I set up text field with its representation as ASCII.
Is there anything what I'm missing here ? I can't decrypt it back again having data changed over setting it up in text field.

String (bytes[] Charset) is returning results differently in Java7 and java 8

import java.io.UnsupportedEncodingException;
import java.nio.charset.StandardCharsets;
import java.util.Arrays;
public class Java87String {
public static void main(String[] args) throws UnsupportedEncodingException {
// TODO Auto-generated method stub
//byte[] b = {-101, 53, -51, -26, 24, 60, 20, -31, -6, 45, 50, 103, -66, 28, 114, -39, 92, 23, -47, 32, -5, -122, -28, 79, 22, -76, 116, -122, -54, -122};
//byte[] b = {-76, -55, 85, -50, 80, -23, 27, 62, -94, -74, 47, -123, -119, 94, 90, 61, -63, 73, 56, -48, -54, -4, 11, 79};
byte[] b = { -5, -122, -28};
System.out.println("Input Array :" + Arrays.toString(b));
System.out.println("Array Length : " + b.length);
String target = new String(b,StandardCharsets.UTF_8);
System.out.println(Arrays.toString(target.getBytes("UTF-8")));
System.out.println("Final Key :" + target);
}
}
The above code returns the following output in Java 7
Input Array :[-5, -122, -28]
Array Length : 3
[-17, -65, -67]
Final Key :�
The Same code returns the following output in Java 8
Input Array :[-5, -122, -28]
Array Length : 3
[-17, -65, -67, -17, -65, -67, -17, -65, -67]
Final Key :���
Sounds like Java8 is doing the right thing of replacing with the default sequence of [-17, -65, -67].
Why is there a difference in output and Any Known bugs in JDK 1.7 which fixes this issue?

Per the String JavaDoc:
The behavior of this constructor when the given bytes are not valid in the given charset is unspecified. The CharsetDecoder class should be used when more control over the decoding process is required.

I think (-5, -122, -28) is a invalid UTF-8 byte sequence, so the JVM may output anything in this case. If it were a valid one, maybe the different Java versions could show the same output.
Does this specific byte sequence have a meaning? just curious

How to decode a Base64 string in Scala or Java?

I have a string encoded in Base64:
eJx9xEERACAIBMBKJyKDcTzR_hEsgOxjAcBQFVVNvi3qEsrRnWXwbhHOmzWnctPHPVkPu-4vBQ==
How can I decode it in Scala language?
I tried to use:
val bytes1 = new sun.misc.BASE64Decoder().decodeBuffer(compressed_code_string)
But when I compare the byte array with the correct one that I generated in Python language, there is an error. Here is the command I used in python:
import base64
base64.urlsafe_b64decode(compressed_code_string)
The Byte Array in Scala is:
(120, -100, 125, -60, 65, 17, 0, 32, 8, 4, -64, 74, 39, 34, -125, 113, 60, -47, -2, 17, 44, -128, -20, 99, 1, -64, 80, 21, 85, 77, -66, 45, -22, 18, -54, -47, -99, 101, -16, 110, 17, -50, -101, 53, -89, 114, -45, -57, 61, 89, 15, -69, -2, 47, 5)
And the one generated in python is:
(120, -100, 125, -60, 65, 17, 0, 32, 8, 4, -64, 74, 39, 34, -125, 113, 60, -47, -2, 17, 44, -128, -20, 99, 1, -64, 80, 21, 85, 77, -66, 45, -22, 18, -54, -47, -99, 101, -16, 110, 17, -50, -101, 53, -89, 114, -45, -57, 61, 89, 15, -69, -18, 47, 5)
Note that there is a single difference in the end of the array

In Scala, Encoding a String to Base64 and decoding back to the original String using Java APIs:
import java.util.Base64
import java.nio.charset.StandardCharsets
scala> val bytes = "foo".getBytes(StandardCharsets.UTF_8)
bytes: Array[Byte] = Array(102, 111, 111)
scala> val encoded = Base64.getEncoder().encodeToString(bytes)
encoded: String = Zm9v
scala> val decoded = Base64.getDecoder().decode(encoded)
decoded: Array[Byte] = Array(102, 111, 111)
scala> val str = new String(decoded, StandardCharsets.UTF_8)
str: String = foo

There is unfortunately not just one Base64 encoding. The - character doesn't have the same representation in all encodings. For example, in the MIME encoding, it's not used at all. In the encoding for URLs, it is a value of 62--and this is the one that Python is using. The default sun.misc decoder wants + for 62. If you change the - to +, you get the correct answer (i.e. the Python answer).
In Scala, you can convert the string s to MIME format like so:
s.map{ case '-' => '+'; case '_' => '/'; case c => c }
and then the Java MIME decoder will work.

Both Python and Java are correct in terms of the decoding. They are just using a different RFC for this purpose. Python library is using RFC 3548 and the used java library is using RFC 4648 and RFC 2045.
Changing the hyphen(-) into a plus(+) from your input string will make the both decoded byte data are similar.

What does MessageDigest.update(byte[]) do?

What exactly does this do? I tried to look it up but didn't find anything.
Reason for asking is I want to incorporate a SALT byte[] into a value which is then hashed. So should it be done like this (Pseudo code):
MessageDigest.update(SALT);
MessageDigest.update(value);
digestValue = MessageDigest.digest();
// Where SALT, value and digestValue are array bytes, byte[]
Does this add both SALT and value to the final digest or should I combine both variables into one and then update it once?
I couldn't find an answer for this in any documentation, any clarification would be appreciated.
Thank you, cheers.

MessageDigest is statefull, calls of MessageDigest.update(byte[] input) accumulate digest updates until we call MessageDigest.digest. Run this test to make sure:
MessageDigest md1 = MessageDigest.getInstance("MD5");
md1.update(new byte[] {1, 2});
md1.update(new byte[] {3, 4});
System.out.println(Arrays.toString(md1.digest()));
MessageDigest md2 = MessageDigest.getInstance("MD5");
md2.update(new byte[] {1, 2, 3, 4});
System.out.println(Arrays.toString(md2.digest()));
output
[8, -42, -64, 90, 33, 81, 42, 121, -95, -33, -21, -99, 42, -113, 38, 47]
[8, -42, -64, 90, 33, 81, 42, 121, -95, -33, -21, -99, 42, -113, 38, 47]

I get different results reading the same file from the file system and from inside a jar

I have a file that my Java application takes as input which I read 6 bytes at a time. When I read it in off the file system everything works fine. If I build everything into a jar the first 4868 reads work fine, but after that it starts returning the byte arrays in the wrong order and also ends up having read more data at the end.
Here is a simplified version of my code which reproduces the problem:
InputStream inputStream = this.getClass().getResourceAsStream(filePath);
byte[] byteArray = new byte[6];
int counter = 0;
while ((inputStream.read(byteArray) != -1))
{
counter++;
System.out.println("Read #" + counter +": " + Arrays.toString(byteArray));
}
System.out.println("Done.");
This is the [abbreviated] output I get when reading off of the file system:
...
Read #4867: [5, 0, 57, 7, 113, -26]
Read #4868: [2, 0, 62, 7, 114, -26]
Read #4869: [2, 0, 68, 7, 115, -26]
Read #4870: [3, 0, 75, 7, 116, -26]
Read #4871: [2, 0, 83, 7, 117, -26]
...
Read #219687: [1, 0, 4, -8, 67, 33]
Read #219688: [1, 0, 2, -8, 68, 33]
Read #219689: [5, 0, 1, -8, 67, 33]
Done.
And here is what I get reading from a jar:
...
Read #4867: [5, 0, 57, 7, 113, -26]
Read #4868: [2, 0, 62, 7, 113, -26] //everything is fine up to this point
Read #4869: [7, 114, -26, 2, 0, 68]
Read #4870: [7, 115, -26, 3, 0, 75]
Read #4871: [7, 116, -26, 2, 0, 83]
...
Read #219687: [95, 33, 1, 0, 78, -8]
Read #219688: [94, 33, 1, 0, 76, -8]
Read #219689: [95, 33, 1, 0, 74, -8]
...
Read #219723: [67, 33, 1, 0, 2, -8]
Read #219724: [68, 33, 5, 0, 1, -8]
Read #219725: [67, 33, 5, 0, 1, -8]
Done.
I unzipped the jar and confirmed that the files being read are identical, so what could cause the reader to return different results?

Your reading loop is wrong.
inputStream.read() method returns number of bytes it really read. You have to check this number before transforming the data into string.
When you are reading from file the bytes are not arrived all together. At one of the iterations of your loop you probably read 4 of expected 6 bytes, so your transformation to string does not work.
If you are reading integers I'd recommend you to wrap your raw input string using Scanner or good old DataInputStream and read integers directly.