I am doing a project on ISBN barcode scanning. I have tried many scanning applications but after scanning this barcode:
the app only gives me back the barcode 9780749423490.
But what I need to obtain is the ISBN code 0749423498 instead, as it is in the database of my library. Is there any method to get it?
Can anyone explain the difference between these two codes? Why is the barcode number and ISBN barcode number different? Is it the same for some books and different for some ? thanks!
It looks like the confusion is the difference between the "ISBN 10" and "ISBN 13" standards.
The ISBN Agency website FAQ says:
"Does the ISBN-13 have any meaning imbedded in the numbers?
The five parts of an ISBN are as follows:
1. The current ISBN-13 will be prefixed by "978"
2. Group or country identifier which identifies a national or geographic grouping of publishers
3. Publisher identifier which identifies a particular publisher within a group
4. Title identifier which identifies a particular title or edition of a title
5. Check digit is the single digit at the end of the ISBN which validates the ISBN"
So the 978 is clearly just filler. After that, the next 9 numbers are obviously the same in both numbers. The last digit in both numbers is a check digit, which is different in ISBN 10 and ISBN 13. See this Wikipedia article for details, but the two formulas are:
For ISBN 10 (the top one), the sum of all digits multiplied by mutlipliers 10-9-8-7-6-5-4-3-2-1 mod 11 should be 0:
0*10 + 7 *9 + 4*8 + 9*7 + 4*6 + 2*5 + 3*4 + 4*3 + 9*2 + 8*1 % 11 == 0
For ISBN 13 (the bottom one) the sum of the odd digits * 1 plus the sum of the even digits * 3 should be 0. This is including the leading 978. (this is similar to the UPC code as "user..." mentioned but a little different as noted in the Wikipedia article):
9*1 + 7*3 + 8*1 + 0*3 + 7*1 + 4*3 + 9*1 + 4*3 + 2*1 + 3*3 + 4*1 + 9*3 + 0*1 % 10 == 0
So you can get the ISBN 10 code (top) from the ISBN 13 (bottom) code as follows:
isbnBaseCode = <9780749423490 from the 4th to 12th characters>
isbn10CheckDigit = 11 - (isbnBaseCode[0]*10 + isbnBaseCode[1]*9 + ... + isbnBaseCode[8]*2) % 11
isbnCode10 = isbnBaseCode + isbn10CheckDigit
The long and short of your question is that they are in fact both ISBNs.
One is in the 10 digit format and the other is in the newer 13 digit format.
978 074942349 0
074942349 8
The 978 is a prefix and the last digit, on both, is a check digit .
The barcode on the item you are scanning only represents the 13 digit format.
According to http://www.isbn.org/standards/home/isbn/transition.asp
You can always convert from 13 digit ISBN starting with 978 to the 10 digit format
and provides a link to an online converter. It also discusses the 979 prefix.
I don't believe the 979 prefix is being used yet but its good to be aware that they may be used in future.
Having worked in the Library apps space, when searching a library catalog
item records will vary greatly in what information they contain.
Item records, specifically regarding ISBN, can contain the 10 digit ISBN, 13 digit ISBN, both, or none. So to find an item you might have to try both formats.
I believe that some systems, if your search type is set to ISBN, will actually check the submitted ISBN and search for both formats automatically.
Depending on what your trying to do.
Many library search functions allow for wild cards which may make it easier to find
the item your looking for. For example:
'if the isbn has a length of 13 and starts with 978
remove the first 3 (the 978) and last digit (the check digit)
add a wildcard character to the front and back
begin search
end if
eg 9780749423490 would become *07494234*
The downside is that it might return multiple results.
Even if that were to happen it would likely only be a couple items and the one your
looking, if there, would be easy to spot.
As provided by others the Wikipedia article on ISBN goes into more technical details on how to convert between the 10 and 13 digit formats.
http://en.wikipedia.org/wiki/International_Standard_Book_Number
The number starting 978 is a product code, specifically a UPC (Universal Product Code), that includes the ISBN but without the check digit at the end. Have a look at ISBN on wikipedia for code on generating the check digit and you'll be able to reconstruct the ISBN from the UPC.
Related
In my db i have long string with which length is not fixed
e.g.
4504065148...Leaving VENDOR on 01-01-1990;Please allow 7 - 10 days
Case escalated, pending ETA
Tentatively Leaving XYZ on 01-01-1990. Please allow 3 - 5 days.
so now I want to extract the number after allow key word i.e.7 or 3 using tablue
I had tried my work around but unable to find any solution
I'm assuming the number after allow is always a single digit.
if find([Column],'allow')>0 then mid([Column],find([Column],'allow')+6,1) end
[Column] is your column name. So if "allow" is present, then extract the next character after "allow ".
I am using yoururls with Base32 encoding to send shortened links within an sms. The URL is preceded by a message and since sms is limited to 160 characters and my messages are approximately 140 characters I need to be very careful about character count.
My question is this; How do I calculate how many URL's I can fit with a 4 character limit using base32 encoding?
I'm not sure if you are asking about permutations.
Each character in base32 encoding can have 32 values ([A - Z] and [2 - 7]). If you use the form http://yoursite.com/xxxx, where xxxx is the short URL, four digits can contain 32 4 permutations. That is, 1,048,576.
If you also include URLs with three digits (e.g. http://yoursite.com/xxx), you can have 32 3 permutations. That is, 32,768. Together with four-digit URLS, then you get a total of 1,081,344.
If you also use 2 digit URLs (e.g. http://yoursite.com/xx), you get additional 1,024 URLS, totalling 1,082,368. And including single digits (e.g. http://yoursite.com/x) will give you additional 32. totaling 1,082,400.
But you don't need to use only [A - Z] and [2 - 7]. As per RFC3986, you can use characters ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-._~:/?#[]#!$&'()*+,;=. That's 84 different characters. With this:
http://yoursite.com/xxxx 49,787,136
http://yoursite.com/xxx added 50,379,840 (+592,704)
http://yoursite.com/xx added 50,386,896 (+ 7,056)
http://yoursite.com/x added 50,386,980 (+ 84)
Even if you leave out characters -._~:/?#[]#!$&'()*+,;=, because they would really not fit in a shortened URL, you'll still get 62 characters. With that:
http://yoursite.com/xxxx 14,776,336
http://yoursite.com/xxx added 15,014,664 (+238,328)
http://yoursite.com/xx added 15,018,508 (+ 3,844)
http://yoursite.com/x added 15,018,570 (+ 62)
I've been digging into the history of BCPL due to a question I was asked about the reasoning behind using the prefix "0x" for the representation hexadecimal numbers.
In my search I stumbled upon a really good explanation of the history behind this token. (Why are hexadecimal numbers prefixed with 0x?)
From this post, however, another questions sparked:
For octal constants, did BCPL use 8 <digit> (As per specs: http://cm.bell-labs.com/cm/cs/who/dmr/bcpl.pdf) or did it use #<digit> (As per http://rabbit.eng.miami.edu/info/bcpl_reference_manual.pdf) or were both of these syntaxes valid in different implementations of the language?
I've also been able to find a second answer here that used the # syntax which further intrigued me in the subject. (Why are leading zeroes used to represent octal numbers?)
Any historical insights are greatly appreciated.
There were many slight variations on syntax in BCPL.
For example, while the one we used had 16-bit cells (so that x!y gave you the 16-bit word from a word address at x + y (a word address being half of the byte address), we also had a need to extract from byte address and byte values (since we were primarily creating OS and control software on a 6809 byte-addressable CPU).
Hence in addition to:
x!y - get word from byte address (x + y) * 2
we also had
x!%y - get byte from byte address (x * 2) + y
x%!y - get word from byte address x + (y * 2)
x%%y - get byte from byte address x + y
I'm pretty certain they were implementation-specific as I never saw them anywhere else. And BCPL was around long before language standards were as important as they are today.
The canonical language specification would have been the earlier one from Richards since he wrote the language (and your second document is for the Essex BCPL implementation about a decade later). But keep in mind that Project MAC was the earliest iteration - there were plenty of advancements after that as well.
For example, there's a 2013 revision of the BCPL User Guide (see Martin's home page) which specifies #b, #o and #x as prefixes for various non-decimal bases.
Let's say you have a system in which a fairly long key value can be accurately communicated to a user on-screen, via email or via paper; but the user needs to be able to communicate the key back to you accurately by reading it over the phone, or by reading it and typing it back into some other interface.
What is a "good" way to encode the key to make reading / hearing / typing it easy & accurate?
This could be an invoice number, a document ID, a transaction ID or some other abstract value. Let's say for the sake of this discussion the underlying key value is a big number, say 40 digits in base 10.
Some thoughts:
Shorter keys are generally better
a 40-digit base 10 value may not fit in the space given, and is easy to get lost in the middle of
the same value could be represented in base 16 in 33-34 digits
the same value could be represented in base 36 in 26 digits
the same value could be represented in base 64 in 22-23 digits
Characters that can't be visually confused with each other are better
e.g. an encoding that includes both O (oh) and 0 (zero), or S (ess) and 5 (five), could be bad
This issue depends on the font / face used to display the key, which you may be able to control in some cases (like printing on paper) but can't control in others (like web pages and email).
Also depends on whether you can control the exclusive use of upper and / or lower case -- e.g. capital D (dee) may look like O (oh) but lower case d (dee) would not; while lower case l (ell) looks like a 1 (one) while capital L (ell) would not. (With exceptions for especially exotic fonts / faces).
Characters that can't be verbally / aurally confused with each other are better
a (ay) 8 (eight)
B (bee) C (cee) D (dee) E (ee) g (gee) p (pee) t (tee) v (vee) z (zee) 3 (three)
This issue depends on the audio quality of the end-to-end channel -- bigger challenge if the expected user base could have a speech impediment, or may have to speak through a gas mask, or the communication channel could include CB radios or choppy VOIP phone systems.
Adding a check digit or two would detect errors but not help resolve errors.
An alpha - bravo - charlie - delta type dialog can help with hearing errors, but not reading errors.
Possible choices of encoding:
Base 64 -- compact, but too many hard-to-verbalize characters (underscore, dash etc.)
Base 34 -- 0-9 and A-Z but with O (oh) and I (aye) left out as the easiest to confuse with digits
Base 32 -- same as base 34 but leave out the 0 (zero) and 1 (one) as well
Is there a generally recognized encoding that is a reasonable solution for this scenario?
When I heard it first, I liked the article A Proposal for Proquints: Identifiers that are Readable, Spellable, and Pronounceable. It encodes data as a sequence of consonants and vowels. It's tied to the English language though. (Because in German, f and v sound equal, so they should not be used both.) But I like the general idea.
I was reading the specification of Unicode # Wikipedia (Arabic Unicode)
and I see that each of the Arabic digits has 2 Unicode code points.
For example 1 is defined as U+0661 and as U+06F1.
Which one should I use?
According to the code charts, U+0660 .. U+0669 are ARABIC-INDIC DIGIT values 0 through 9, while U+06F0 .. U+06F9 are EXTENDED ARABIC-INDIC DIGIT values 0 through 9.
In the Unicode 3.0 book (5.2 is the current version, but these things don't change much once set), the U+066n series of glyphs are marked 'Arabic-Indic digits' and the U+06Fn series of glyphs are marked 'Eastern Arabic-Indic digits (Persian and Urdu)'.
It also notes:
U+06F4 - 'different glyphs in Persian and Urdu'
U+06F5 - 'Persian and Urdu share glyph different from Arabic'
U+06F6 - 'Persian glyph different from Arabic'
U+06F7 - 'Urdu glyph different from Arabic'
For comparison:
U+066n: ٠١٢٣٤٥٦٧٨٩
U+06Fn: ۰۱۲۳۴۵۶۷۸۹
Or, enlarged by making the information into a title:
U+066n: ٠١٢٣٤٥٦٧٨٩
U+06Fn: ۰۱۲۳۴۵۶۷۸۹
Or:
U+066n U+06Fn
0 ٠ ۰
1 ١ ۱
2 ٢ ۲
3 ٣ ۳
4 ٤ ۴
5 ٥ ۵
6 ٦ ۶
7 ٧ ۷
8 ٨ ۸
9 ٩ ۹
(Whether you can see any of those, and how clearly they are differentiated may depend on your browser and the fonts installed on your machine as much as anything else. I can see the difference on 4 and 6 clearly; 5 looks much the same in both.)
Based on this information, if you are working with Arabic from the Middle East, use the U+066n series of digits; if you are working with Persian or Urdu, use the U+06Fn series of digits. As a Unicode application, you should accept either set of codes as valid digits (but you might look askance at a sequence that mixed the two sets of digits - or you might just leave well alone).
In general you should not hard-code such info in your application.
On Windows you can use GetLocaleInfo with LOCALE_SNATIVEDIGITS.
On Mac CFNumberFormatterCopyProperty with kCFNumberFormatterZeroSymbol.
Or use something like ICU.
There are Arabic countries that don't use the Arabic-Indic digits by default. So there is no direct mapping saying Arabic -> Arabic-Indic digits.
And the user might have changed the defaults in the Control Panel anyway.
Which code do you prefer for representing the number 4, U+0664 or U+06F4?
(٤ or ۴ )?
To be consistent, let this choice guide which codes you use for 1, 2, and the other duplicate codes.