How to find out which type of barcode is this in my sample ? I looked on wikipedia and there are quite many types of barcodes, most common should be Code 39 and Code 128.
Is there any lib for barcode OCR (python, java, C#, delphi) ?
On this barcode should be encoded time and date of expiration.
EDIT
I need to know how to read and decode above barcode. This barcodes were generated in legacy system and It would be nice if my app could OCR and understand them
On my barcode should be date 19.11.2010 15:43
According to this online bar code reader, it an EAN_13 code for a product with the number 5252235562500.
According to Wikipedia it's a product number for a discount coupon with manufacturer code 25223, family code 556 and coupon code 25.
If there is an expiration date encoded in the data, it's in some custom format encoded into the family code and coupon code. Otherwise you need a loopup table from the manufacturer to determine which coupon has which expiration date.
How about, http://code.google.com/p/zxing/.
There's an excellent barcode reading library named Zebra crossing (zxing) available in Java with ports/wrappers to C#, C++, Ruby, etc.
This particular one is indeed EAN-13 code, which encodes 13 decimal digits [0-9] (2..3 country digits + 9..10 product digits + 1 checksum digit).
The Wikipedia article referenced above seems to only refers to "coupon codes" only for UPC12 barcodes which are slightly different from EAN13 barcodes.
According to the offical GS1 site http://gepir.gs1.org/v31/xx/gtin.aspx?Lang=en-US this barcode is not defined as belonging to anyone (or country) so it is probably used internally by some organization for a custom application.
The GS1 site lot of information on barcode standards and formats.
Related
folk,
I'm trying to develop something for our Crystal Reports that generates an EAN barcode image from the numeric string.
I've already developed a function in our SQL database to encode the numeric string as the ones and zeroes that represent the bars and spaces but I'm at a total loss as to:
How I would store this in the DB (other than a VarChar(100))
How to translate these ones and zeroes to an actual image (even if only 1 pixel in height)
Much obliged.
You can use a library such as ZXing.
Another option, given that you are looking for an image rather than font solution, is to use a Crystal Reports UFL (User Function Library). Ken Hamady maintains a list of 3rd-party UFLs here.
At least one of those UFLs caters to many types of barcodes, including EAN.
How do I create a HTML link to an emergency number like 911 or 112?
The RFC says
The
phone number can be represented in either global or local
notation. All phone numbers MUST use the global form unless they
cannot be represented as such.
[Emergency numbers ("911", "112")] cannot be represented in global form and
need to be represented as a local number with a context.
From the local-context section I don't find it easy to understand what a "local-context" is, let alone what the correct one for this case is. It lists domain prefixes like houston.example.com or a numeric prefix like +1, and in one paragraph it says
A context consisting of the initial digits of a global number does
not imply that adding these to the local number will generate a valid
E.164 number. It might do so by coincidence, but this cannot be
relied upon. (For example, "911" should be labeled with the context
"+1", but "+1-911" is not a valid E.164 number.)
But the phrasing of this paragraph is again very confusing.
Is
112
now the correct way of doing it, and the fact that it is not a valid E.164 number is irrelevant?
Or is the fact that it is not a valid E.164 number a problem?
In some other places I see people using
112
And again other people recommend
112
But when I tap that link on Android, the dialer opens with the number
112;746632668398+49
The cited Section 5.1.5 the RFC states
A context consisting of the initial digits of a global number does
not imply that adding these to the local number will generate a valid
E.164 number. It might do so by coincidence, but this cannot be
relied upon. (For example, "911" should be labeled with the context
"+1", but "+1-911" is not a valid E.164 number.)
I interpret this that emergency numbers should be prefixed by their country-secific prefixes, i.e.
in the US, 911 should be used as 911
in Germany 112 should be used as 112
The rest of the paragraph is about this syntax not being compliant to the E.164 recommendation. As far as I understand, E.164 is irrelevant in this context though.
For an application I'm currently building I need a database to store books. The schema of the books table should contain the following attributes:
id, isbn10, isbn13, title, summary
What data types should I use for ISBN10 and ISBN13? My first thoughts where a biginteger but I've read some unsubstantiated comments that say I should use a varchar.
You'll want a CHAR/VARCHAR (CHAR is probably the best choice, as you know the length - 10 and 13 characters). Numeric types like INTEGER will remove leading zeroes in ISBNs like 0-684-84328-5.
ISBN numbers should be stored as strings, varchar(17) for instance.
You need 17 characters for ISBN13, 13 numbers plus the hyphens, and 13 characters for ISBN10, 10 numbers plus hyphens.
ISBN10
ISBN10 numbers, though called "numbers", may contain the letter X. The last number in an ISBN number is a check digit that spans from 0-10, and 10 is represented as X. Plus, they might begin with a double 0, such as 0062472100, and as a numeric format, it might get the leading 00 removed once stored.
84-7844-453-X is a valid ISBN10 number, in which 84 means Spain, 7844 is the publisher's number, 453 is the book number and X (i.e 10) is the control digit. If we remove the hyphens we mix publisher with book id. Is it really important? Depending on the use you'll give to that number. Bibliographic researchers (I've found myself in that situation) might need it for many reasons that I won't go into here, since it has nothing to do with storing data. I would advise against removing hyphens, but the truth is everyone does it.
ISBN13
ISBN13 faces the same issues regarding meaning, in that, with the hyphens you get 4 blocks of meaningful data, without them, language, publisher and book id would become lost.
Nevertheless, the control digit will only be 0-9, there will never be a letter. But should you feel tempted to only store isbn13 numbers (since ISBN10 can automatically and without fail be upgraded to ISBN13), and use int for that matter, you could run into some issues in the future. All ISBN13 numbers begin with 978 or 979, but in the future some 078 might could be added.
A light explanation about ISBN13
A deeper explanation of ISBN
numbers
I'm working with some binary waveform files from various early to mid-90's HP scopes. I am trying to do a bulk conversion (we have over 5000) of the files to CSV's and then upload them into a database. I've tried hexdump, xxd, od, strings, etc. and none of them seem to work. I did hunt down a programmers manual but it's not making a whole lot of sense.
The files have a preamble line as ascii text but then the data points are in binary and for some reason nothing I try can decode them. The preamble gives the data necessary to use the binary values and calculate the correct values. It also states that the data is in WORD format.
:WAV:PRE 2,1,32768,1,+4.000000E-08,-4.9722700001108E-06,0,+2.460630E-04,+2.500000E+00,16384;:WAV:DATA #800065536^W�^W�^W�^
I'm pretty confused.
Have a look at
http://www.naic.edu/~phil/hardware/oscilloscopes/9000A_Programmer_Reference.pdf
specifically page 1-21. After ":WAV:DATA", I think the rest of the chunk above will have 65536 8-bit data bytes (the start of which is represented above by �) . The ^W is probably a delimiter, so you would have to parse that out. Just a thought.
UPDATE: I'm new to oscilloscope data collection and am trying to figure the whole thing out from scratch. So, on further digging, it looks like the data you have provided shows this:
PREamble:
- WORD format (16-bit signed integers split into 2 8-bit bytes)
- If there is a WAV:BYT section, that would specify byte order for each pair
- RAW data
- 32768 data points
- COUNT = 1 (I'm not clear on the meaning of this)
- Next 3 should be X increment, origin, reference
- Next 3 should be Y increment, origin, reference, although the manual that I pointed you at above has many more fields than just these, so you might want to consult your specific scope manual.
DATA:
- On closer examination, I don't think the ^W is a delimiter, I think it is the first byte of the pair (0010111). The � character is apparently a standard "I don't know how to represent this character" web representation. You would need to look at that character as 8 bits also.
- 65536 byte pairs of data
I'm not finding a utility that will do this for you. I think you're going to have to write or acquire some code (Perl, C, Java, Python, VB, etc.) to get this done.
I will be storing a year in a MySQL table: Is it better to store this as a smallint or varchar? I figure that since it's not a full date, that the date format shouldn't be an answer but I'll include that as well.
Smallint? varchar(4)? date? something else?
Examples:
2008
1992
2053
I would use the YEAR(4) column type... but only if the years expected are within the range 1901 and 2155... otherwise, see Gambrinus's answer.
I'd go for small-int - as far as I know - varchar would take more space as well as date. second option would be the date.
My own experience is with Oracle, which does not have a YEAR data type, but I have always tried to avoid using numeric data types for elements just because they are comprised only of digits. (So this includes phone numbers, social security numbers, zip codes as well, as additional examples).
My own rule of thumb is to consider what the data is used for. If you will perform mathematical operations on it then store it as a number. If you will perform string functions (eg. "Take the last four characters of the SSN" or "Display the phone number as (XXX) XXX-XXXX") then it's a string.
An additional clue is the requirement to store leading zeroes as part of the number.
Furthermore, and despite being commonly referred to as a phone "number", they frequently contain letters to indicate the presence of an extension number as a suffix. Similarly, a Standard Book Number potentially ended in an "X" as a "check digit", and an International Standard Serial Number can end with an "X" (despite the ISSN International Centre repeatedly referring to it as an 8-digit code http://www.issn.org/understanding-the-issn/what-is-an-issn/).
Formatting of phone numbers in an international context is tricky, or course, and conforming to E.164 requires that country calling codes are prefixed with a "+".