私は次のコードを持っています...
int Val=-32768;
String Hex=Integer.toHexString(Val);
これはに相当します ffff8000
int FirstAttempt=Integer.parseInt(Hex,16); // Error "Invalid Int"
int SecondAttempt=Integer.decode("0x"+Hex); // Error "Invalid Int"
したがって、最初は、値-32768を16進文字列ffff8000に変換しますが、その後、16進文字列を整数に戻すことはできません。
では.Net、私が期待通りに動作し、returns -32768。
これを自分で変換するための独自の小さなメソッドを作成できることは知っていますが、何かが足りないのか、それとも本当にバグなのか疑問に思っています。
int firstAttempt = 5;
回答:
数値が負であるため、オーバーフローします。
これを試してみてください、それはうまくいくでしょう：
int n = (int) Long.parseLong("ffff8000", 16);
String Hex=Integer.toHexString("xyz");「xyz」として16
int val = -32768;
String hex = Integer.toHexString(val);
int parsedResult = (int) Long.parseLong(hex, 16);
System.out.println(parsedResult);
それがあなたがそれをすることができる方法です。
それがうまくいかない理由：符号付きInteger.parseInt整数を取りtoHexString、符号なし結果を生成します。したがって、より高い値を挿入する0x7FFFFFFと、エラーが自動的にスローされます。long代わりに解析すると、署名されたままになります。ただし、intにキャストして戻すと、正しい値にオーバーフローします。
BigIntegerクラスを使用してみてください。動作します。
int Val=-32768;
String Hex=Integer.toHexString(Val);
//int FirstAttempt=Integer.parseInt(Hex,16); // Error "Invalid Int"
//int SecondAttempt=Integer.decode("0x"+Hex); // Error "Invalid Int"
BigInteger i = new BigInteger(Hex,16);
System.out.println(i.intValue());
UTF-16でデコードされた文字のような符号付きバイトを変換しようとすると、Integer.toHexString（byte / integer）が機能しないため、次のように使用する必要があります。
Integer.toString(byte/integer, 16);
または
String.format("%02X", byte/integer);
逆に使用できます
Integer.parseInt(hexString, 16);
JavaのparseIntメソッドは、実際には「false」の16進数を食べるコードの集まりです。-32768を変換する場合は、絶対値を16進数に変換してから、文字列の前に「-」を付ける必要があります。
Integer.javaファイルのサンプルがあります：
public static int parseInt(String s, int radix)
説明は非常に明確です：
* Parses the string argument as a signed integer in the radix
* specified by the second argument. The characters in the string
...
...
* parseInt("0", 10) returns 0
* parseInt("473", 10) returns 473
* parseInt("-0", 10) returns 0
* parseInt("-FF", 16) returns -255
使用することInteger.toHexString(...)は良い答えです。しかし、個人的には使用することを好みますString.format(...)。
このサンプルをテストとして試してください。
byte[] values = new byte[64];
Arrays.fill(values, (byte)8); //Fills array with 8 just for test
String valuesStr = "";
for(int i = 0; i < values.length; i++)
valuesStr += String.format("0x%02x", values[i] & 0xff) + " ";
valuesStr.trim();
以下のコードは機能します：
int a=-32768;
String a1=Integer.toHexString(a);
int parsedResult=(int)Long.parseLong(a1,16);
System.out.println("Parsed Value is " +parsedResult);
ふふ、好奇心旺盛。これは、いわば「意図的なバグ」だと思います。
根本的な理由は、Integerクラスの記述方法です。基本的に、parseIntは正の数に対して「最適化」されています。文字列を解析するとき、結果は累積的に作成されますが、否定されます。次に、最終結果の符号を反転します。
例：
66 = 0x42
次のように解析されます：
4*(-1) = -4
-4 * 16 = -64 (hex 4 parsed)
-64 - 2 = -66 (hex 2 parsed)
return -66 * (-1) = 66
それでは、FFFF8000の例を見てみましょう。
16*(-1) = -16 (first F parsed)
-16*16 = -256
-256 - 16 = -272 (second F parsed)
-272 * 16 = -4352
-4352 - 16 = -4368 (third F parsed)
-4352 * 16 = -69888
-69888 - 16 = -69904 (forth F parsed)
-69904 * 16 = -1118464
-1118464 - 8 = -1118472 (8 parsed)
-1118464 * 16 = -17895552
-17895552 - 0 = -17895552 (first 0 parsed)
Here it blows up since -17895552 < -Integer.MAX_VALUE / 16 (-134217728).
Attempting to execute the next logical step in the chain (-17895552 * 16)
would cause an integer overflow error.
編集（追加）：parseInt（）が-Integer.MAX_VALUE <= n <= Integer.MAX_VALUEに対して「一貫して」機能するためには、-Integer.MAX_VALUEに到達したときに「回転」するロジックを実装する必要がありました。累積結果。整数範囲の最大値からやり直し、そこから下に向かって進みます。なぜ彼らがこれをしなかったのか、ジョシュ・ブロッホまたはそもそもそれを実装した人に尋ねなければならないでしょう。それは単なる最適化かもしれません。
しかしながら、
Hex=Integer.toHexString(Integer.MAX_VALUE);
System.out.println(Hex);
System.out.println(Integer.parseInt(Hex.toUpperCase(), 16));
この理由だけで、問題なく動作します。Integerのソースには、このコメントがあります。
// Accumulating negatively avoids surprises near MAX_VALUE
// Accumulating negatively avoids surprises near MAX_VALUE->しかし、それは驚きを