Carey Brown wrote:Another way to do it where padding happens automatically. ...
Rob Spoor wrote:Another improvement is pre-allocate the size: new StringBuilder(hash.length * 2). I've also used versions that write to a char instead of a StringBuilder, but that requires keeping track of your own index.
Tim Holloway wrote:
Also, since byte is supposed to be unsigned, the "& 0x0F" on the first character is supposed to be redundant. Java should promote the unsigned byte to a positive integer before shifting. However, it's safer to do this, since some systems do consider "bytes" as signed, and in such cases, the byte 0xDC would end up as 0xFFFFFFDC before shifting, and 0xFFFFFFFD (int value -13) after the shift and that would be unfortunate.
Rob Spoor wrote:
I actually prefer Character.digit(..., 16), possibly wrapped in Character.toUpperCase. Why not use the APIs you're given?
Stephan van Hulst wrote:What do you mean? What wrong with Integer.toHexString() or String.format()?
And what is wrong with System.out.printf("%#04x%n", myByteValue)? That looks perfectly all right to me.
Matt Wong wrote:. . . Integer.toHexString: doesn't 0-pad . . . the smaller datatypes Byte, Short and Character doesn't provide it - also, the toString() with additional radix parameter is only provided by Integer and Long) . . .
. . . Have you read its documentation recently? Notice that keyboard int input is different from hexadecimal int literals in code. You are not allowed a decimal int literal larger than 2147483647, except that 2147483648 is permissible if preceded immediately by the the sign change operator (unary minus). That is exactly what you are showing. It's what the Java® Language Specification describes for decimal integer literals. It is the same behaviour as in decimal; if you look at the decimal version of Integer#parseInt(), you will find it says the same result as ...parseInt("123", 10). If "2147483648" won't parse in decimal why should its hexadecimal equivalent "80000000"? I am not familiar with this method, and there is nothing stopping you from writing your own parseInt() method.
in addition the parseInt method in my eyes lacks support for correctly parsing negative values correctly . . .
Whenever you use a new method or class, make sure to look at its documentation. We give the best explanations we can, but we cannot know what happened at Sun all those years ago, before many users of this website were born?
. . . as long year dev one might know these quirks - but for a new one . . . this doesn't seem to make sense . . . although maybe technically correct, isn't really a good explanation
Maybe when the % tags were introduced they thought that would solve the problem of not padding hex Strings with 0s.
Stephan van Hulst wrote:. . . String.format(), which does EXACTLY what one wants . . .
You got style baby! More than this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koophttps://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton