According to the algorithm for ISBN10, the check digit can be X, it means, it may not be a number. But the output of google API: https://www.googleapis.com/books/v1/volumes?q=isbn:xxx uses an integer type for ISBN10 and ISBN13. Why?
P.S.: The following is part of the google API output:
industryIdentifiers = (
{
identifier = 7542637975;
type = "ISBN_10";
},
{
identifier = 9787542637970;
type = "ISBN_13";
}
);
ISBN-10 in theory should have been replaced by ISBN-13 by 2007. Obviously, this is not possible for already-sold publications, and some publishers still maintain ISBN-10 rather than changing to ISBN-13 (in the same way as some manufacturers maintain UPC-A instead of EAN-13 or GSi.)
To convert a USBN-10 to USBN-13, simply take the first 9 digits of the USBN, prefix it with 978 and then calculate the check digit using the standard EAN algorithm. Use the 13-digit result as your key to locate the item (as a 64-bit unsigned integer).
You can always extract the ISBN-10 by removing the first 3 digits and the check-digit and using the ISBN-10 algorithm to re-calculate the check character.
This way, you only need to record the 13-digit version. If you have an ISBN-10 (read by scanner) or you need to produce an ISBN-10 (for whatever purpose) it's simply a matter of applying the appropriate conversion algorithm.
Depending on your application, you may wish to consider what to do with ISMN (for music) or ISSN (periodical) numbers. Periodicals are the more problematic. The barcode extension usually yields month or week of publication, but the -13 version remains the same. That's fine for a seller or such items, as whatever-01 would be January, and these would be well out-of-date (and hence no-longer-in-stock) by the following January when the same number would be used. Not so good for an archival function like a library, though...