Decode Base64 JKS Trust Store in Java

I have based 64 JKS trust store string which I'm trying to decode.
When I'm using this site to decode the file I'm getting a downloadable file with the following details:

This file is working when I'm using it with -Djavax.net.ssl.trustStore=path-to-file

Now I'm trying to decode the file myself using Java and write it to a file:

byte[] decoded = Base64.getDecoder().decode(data);
FileOutputStream fos = new FileOutputStream(new File(basePath));
fos.write(decoded);

This way I'm getting not readable characters like ���� .

I also try to convert the byte array to String:

StringBuilder sbHexDump = new StringBuilder();
for (byte b : decoded) {
    sbHexDump.append(String.format("%02x", b));
}

This way I'm getting the same hexdump as I downloaded from the website, but without spaces and newlines.
In both ways, I get the following error:

java.io.IOException: Invalid keystore format
	at sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:663)
	at sun.security.provider.JavaKeyStore$JKS.engineLoad(JavaKeyStore.java:56)
	at sun.security.provider.KeyStoreDelegator.engineLoad(KeyStoreDelegator.java:224)
	at sun.security.provider.JavaKeyStore$DualFormatJKS.engineLoad(JavaKeyStore.java:70)
	at java.security.KeyStore.load(KeyStore.java:1445)

I would appreciate your help

> This way I'm getting not readable characters like ���� .

Yes, so what? JKS is a binary format. Not all bytes are mapped to printable characters. As long as keytool can read it you're good.

In addition to knowing the base 64 encoding scheme (https://en.wikipedia.org/wiki/Base64), you may need to be aware of any big-endian issues as to byte placement. Encoding is just taking the first 8 bits, encodng 6 of them, concatenate the next 8 to the remaining 2 and encoding 6 of them, concatenate the next 8 to the remaining 4 and encoding 6 of them, and encode the last 6. If you hit eof in the midst of a 3 byte group, there is an = padding system to encode this.

The only trick is to take your bits from the correct end and concatenate your bits on the correct end. If you are encoding binary non-byte data like integers, you have to be big-endian aware of how they encoded it, as the low byte of the integer may be either 1st or 4th byte encoded for little or big endian, respectively.

The addition of spaces or line feeds or the like is just to make it more palatable to text editors, screen viewing, emailing, humans, etc.