-5

I want to append these long variables, so I turned them into Strings first. When I return them back into a long it throws a NumberFormatException.

public long BLZ = 12345678l;
public long KNr = 1234567890l;
public String landCode = "1314";
long fedor = Long.parseLong(String.valueOf(BLZ) + String.valueOf(KNr) + 
landCode + "00"); 
  • 5
    Possible duplicate of [How to convert String to long in Java?](https://stackoverflow.com/questions/7693324/how-to-convert-string-to-long-in-java) – MC10 Sep 26 '17 at 15:15
  • Possible duplicate of [How to convert string to long](https://stackoverflow.com/questions/9936648/how-to-convert-string-to-long) – Alessandro Sep 26 '17 at 15:16
  • The resulting number is simply too big to fit into a `long`. – Henry Sep 26 '17 at 15:17
  • `123456781234567890131400` simply is too large for a `long` number. There is no way to fix that without changing your task. – Holger Sep 26 '17 at 15:17
  • 1
    Do you really try to represent a IBAN with a long? Why? – Tom Sep 26 '17 at 15:19
  • 1
    @Tom: perhaps to calculate the mod 97 for verification. But that requires a `BigInteger`, obviously. – Holger Sep 26 '17 at 15:21
  • @Tom That's not an IBAN where the country code is two-alpha-ISO at the beginning and not a four-digit numeric value in between. Also the bank code is padded with trailing zeros. – Lothar Sep 26 '17 at 15:23
  • @Holger Mhh, that might be the reason here, yes. – Tom Sep 26 '17 at 15:24
  • @Lothar Feel free to read the wiki: https://en.wikipedia.org/wiki/International_Bank_Account_Number#Validating_the_IBAN :). Then you also know why OP uses 1314 instead of DE in his IBAN. – Tom Sep 26 '17 at 15:29
  • Possible duplicate of [What is a NumberFormatException and how can I fix it?](https://stackoverflow.com/questions/39849984/what-is-a-numberformatexception-and-how-can-i-fix-it) – xenteros Sep 28 '17 at 09:21

1 Answers1

3
long BLZ = 12345678l;
long KNr = 1234567890l;
String landCode = "1314";
System.out.println(Long.MAX_VALUE);
System.out.println(String.valueOf(BLZ) + String.valueOf(KNr) + landCode + "00"); 

leads to the output

9223372036854775807

123456781234567890131400

The number you try to parse in is bigger than a long can handle.

Edit: You asked how to solve your problem. In the comments of your question there is the theory that you want to calculate the checksum of an IBAN. You can do that by using java.math.BigInteger:

System.out.println(Long.MAX_VALUE);
long BLZ = 12345678l;
long KNr = 1234567890l;
String landCode = "1314";
String val = String.valueOf(BLZ) + String.valueOf(KNr) + landCode + "00";
System.out.println(val); 
System.out.println(BigInteger.valueOf(98).subtract(new BigInteger(val).mod(BigInteger.valueOf(97))));

This leads to the following output:

9223372036854775807

123456781234567890131400

87

Alternatively you can check the IBAN Documentation (it's german but that shouldn't be problem for you I suppose ;-) where in chapter 4 there is a description of a way to calculate the checksum if you're limited (like here). You will still need longs to be able to implement that, because 9-digit numbers can exceed the range of an int.

Community
  • 1
  • 1
Lothar
  • 5,323
  • 1
  • 11
  • 27
  • Thank you, although I have no idea how to solve my problem. Do you have an idea? – Fledormaus Sep 26 '17 at 15:22
  • @Fledormaus Without knowing what exactly you want to achieve and where your problem is, that's a hard task. Your implementation simply won't work, so in order to tell you, what you need to do, we need to know more about the actual scenario here. – Lothar Sep 26 '17 at 15:24
  • @Fledormaus If you really want to parse the given number into something, `java.math.BigInteger` is your friend (already mentioned in the comments to your question). You can do the conversion by calling `new BigInteger(concatenatedString)` – Lothar Sep 26 '17 at 15:27
  • 1
    It should be noted that treating the fragments as numeric bears the risk of loosing significant zero digits. Using something along `String.format("%08d%010d", BLZ, KNr)` is strongly recommended. – Holger Sep 26 '17 at 15:48
  • @Holger Generally speaking this is true but the values in this particular example should already be the result of a conversion from the text, because (look into the PDF I linked) account numbers in other countries can contain letters as well that need to be replaced by corresponding numbers. – Lothar Sep 26 '17 at 15:51
  • 1
    @Lothar: well, a `KNr` of `1234567890` is quiet a contrived example, obviously working with this naive approach, but just consider that `123456` would be a valid `KNr` too (yes, we have smaller banks in Germany), even my own account has fewer digits, thus requires zero padding, so it doesn’t require incorporating other countries and letters to let this break. – Holger Sep 26 '17 at 16:09