Is there a way to decrypt the goods? For example, if I received the product barcode then, using some libraries, find out what it is product? For example, apple juice, one liter of a particular company.
What is the way to solve this problem? Now I'm is not interested decision on some platform. I asking show me some decisions this problem.
Read this: GSDN Database which listed 11 million items as of about 18 months ago. I've no doubt you would be able to gain access to this database if required - it's managed by the world-wide authority.
Item barcodes may be 13, 12 or 8 digits long - there are formulæ to convert the shorter code to 13-digit. All systems were supposed to be converted to 13-digit many years ago so that there was no need for a product bearing a 13-digit barcode to also require a UPC-A (12-digit) code for use in the US.
The general scheme is to use the first 2, sometimes 3 digits for a country code, then allot a company code and item number (assigned by the company) and then a check digit. The actual number of digits assigned to the company code and item varies with the local GS1 office, but the total of country+company+item digits must be 12 + 1 check digit=13.
As an example, Australia uses country 93, then either 5 or 7 digits for company code (depending on expected number of products) then 5 or 3 digits for the item code.
Product barcodes (12 or 13 numbers long, depending on location) are just an item number, they do not carry any information about what the product is. There is some basic information you can get from these barcodes:
The first 3 digits tell you which country the barcode is from. you can look here
http://en.wikipedia.org/wiki/List_of_GS1_country_codes for a list.
The next 9 digits are made of 4 to 6 digits tell you which company the barcode comes from,
and then there are 3 to 5 digits which are the particular SKU's item number
and finally a check digit.
Related
I have a dictionary of words split into two lists of different lengths, adjectives and nouns. I want to be able to reversibly encode any phone number into a format where I have one or more adjectives followed by a noun.
Examples might be
"+447911123456" => "agile sassy stingray"
"07911123456" => "funky old golf club"
It should have properties like the avalanche effect, and make relatively even use of all the words in the dictionary.
I've not been able to come up with an algorithm that satisfies all the requirements. Does anyone know how to do this, or where to learn more about doing this sort of encoding?
If it helps, I've made the dictionary available on github. Any help is appreciated!
reversibly encode any phone number
How about something like this?
Given phone numbers are typically 10 - 14 digits including the international code, we can treat it as a 64 bit integer (up to 19 digits) if we ignore the international dialing code "+".
Split the segments into 3 roughly even zones = 21 bits each.
XOR each of the zones with a fixed repeating pattern - i.e. 01 for seg 1, 10 for seg 2, 11 for seg 3.
Perform a simple encryption that is 21 bits wide... a simple custom one can be developed easily.
After these transformations, you end up with 3 numbers. Use the numbers as keys to your dictionary. The 3rd block will reference a nouns dictionary.
The purpose of steps 3 and 4 are to obfuscate what you are doing.
For instance, if we had 111 111 111 as our number, without 3 and 4, we might have "happy happy dog". With 3 and 4, even though segments 1 and 2 are identical, it will result in different words such as "happy sloppy dog". Instead, we might get a totally different number result in repeated words... i.e. 111 843 111 => "happy happy cat".
Because it is only for obfuscating purposes, these do not need to be terribly "secure"...
I am building a time keeping application for a business. Their staff will carry a unique barcode (either on a lanyard or as an image on their phone) and will display it to a barcode reader. The reader will use it to identify the clock-on/clock-off activity of the staff member.
As it currently stands, each staff member already has a unique id. These are incrementing integers, starting at the digit 1. At the very most, there may be hundreds or thousands of unique staff members (throughout the duration of the lifetime of my application) but certainly not one million or more. I am planning to encode this unique ID as the barcode.
Given the above, how should I choose a bar code system?
It seems to me that EAN13 is widely supported by barcode readers, and has ample 'space' for my needs (i.e. less than 1-million unique id's). This would seem like a good choice.
I see that some other systems include 'error checking', but they include a lot more visual detail. I presume that these codes would need to be printed carefully (e.g. not on a home printer), and would only useful in well lit environments.
EAN-13 uses "registered" numbers and is primarily for consumer packaging.
If you want a linear barcode, look at code128. It has a built in check-digit and packs two digits per "character". You should plan to zero-pad the numbers to 6 or 8 digits so the barcodes are always the same size. The following shows "000101" in code128:
https://bwipjs-api.metafloor.com/?bcid=code128&text=000101&includetext&backgroundcolor=ffffff
I'd choose QR codes cos they're sick, you can stick a logo in them, and they're just nice in general.
So I know there are websites out there that do this for you, but not to the extent that I need. I want to be able to Create a 13 Digit Alpha Numeric code several times over, if possible have it spit out 1,000 codes at a time. However my problem is I only want there to be 4 numbers max(so 0-4 out of the 13 will be numbers and the rest CAPITAL letters), here is an example: CHC-RCJV-6KK-ZUA . The Hyphens are not a neccesity. I am new to coding for the most part, I'm not sure if it's possible to do this on windows If so I would prefer it, however I can use linux if needed. Thanks for any help!
You want up to 4 random digits and the rest capital letters. That gives you a five stage process:
Pick how many digits, from the range [0..4].
Pick that many random single digits and store them in a list.
Pick up to 13 random capital letters and store them in the same list.
Shuffle the contents of your list.
Insert the hyphens and print/display/return/whatever.
Try coding that for yourself. If you have problems making it work then show us your code and we will help you.
My app may be used anywhere in the USA, but will be used by local businesses serving their own areas.
As my project-in-development exists now (and I can change it) I'm storing only 10 digits. I'd like to think my software may be in use 10 years from now, although I can certainly release updates. But since the trend is for every person to have a phone instead of just one number per household, I understand the USA is running out of 10-digit phone numbers.
I know it may not seem so, but yes, I HAVE Googled and the answer I seek is still as clear as mud.
I read that there are locales within the USA (I don't know where) in which even within the same area code, a 1 and the area code must be dialed first. Other times, just the area code must be dialed, without the 1, even within the same area code.
MY QUESTION IS: To accommodate the whole USA and the foreseeable future, will I need to add an "optional 1" in front of the number, in the form of a check box or other device to distinguish those which need a 1 from those that don't? Is there another phone number schema coming in the future? Or putting it all more simply: Is 10 digits enough?
if you only want to store North american numbers you'll be fine
North American Numberin Plan
10 is the standard length in north america (includes canada)
You should allow for 15 digits including the country code. You already need 12 to 14 digits (including country code) for many countries.
Store all numbers in E.164 format including the country code, without spaces or punctuation.
This will allow easy expansion internationally to other countries and also allow manipulation of numbers in the database if the length of numbers used in any country were to ever change.
There's talk that US numbers will become a digit longer some time in the next decade or or two. You should plan for that now, not when you have tens of millions of numbers stored.
There's constant change in national number plans. If you know that area code 765 in country 980 is changing to area code 77 and all local numbers are having 88 added to the beginning it's a simple operation to make that change if all the numbers in the database include the country code.
Note: I have already read through older questions like What is the best format for a customer number, order number? , however my question is a little more specific.
Generating pseudo-random numbers encounter the "birthday problem" before long. For example, if I am using a 27-bit field for my order number, after 15000 entries, the chances of collision increase to 50%.
I am wondering whether large ecommerce businesses like Amazon generates its order number in any other way - for example :
pre-generate the entire set and pick from them randomly (a few hundred GB of database)
Use lexicographical "next_permutation" starting from a particular seed number
MD5 or SHA-1 hash of the date, user-id, etc parameters, truncated to 14 digits
etc
All I want is a non-repeating integer (doesnt need to be very random except to obfuscate total number of orders) of a certain width. Any ideas on how this can be achieved ?
Suggest starting with the date in reverse format then starting at 1, followed by a check (or random) digit. If you are likely to never exceed 100 orders per day you need add two digits plus a check/random digit.
The year need include only the final two digits, possibly only the final digit, depending on how long you keep records of orders: 7 years or so is usually enough, meaning the records from 2009 (beginning with 9) could be deleted during 2018 in preparation to use the order numbers again in 2019. You could use mmdd for the next 4 digits, or simply number the days through the year and use just 3 digits - it depends how human-friendly you want the number to be. It's also possible just to omit the day of the month and restart the sequential numbers at the start of each month, rather than every day.
Today is 2 Nov 2017, let's suppose this is order no 16 today, your order no would be 71102168 (where the 8 is a check digit or random digit). If you're likely to have up to, but not exceeding a thousand, you'll need an extra digit, thus: 711020168. To avoid limiting yourself the number of digits, you might prefer to use a hyphen: 71102-168 … you could include another hyphen before the check/random digit if you wish: 71102-16-8.
If you have several areas dealing with orders, you may wish to include a depot number, perhaps at the beginning or after the date, allowing you to use the sequence numbers at each depot - eg depot 5 might be: 5-71102-168, 71102-5-168 or 711025168. Again, if you don't use hyphens, you'll need to assess whether you need up to ten, a hundred or a thousand (etc) possible depot numbers. I hope this helps!
This problem has been solved, why
not use the UUID. See RFC 4122. These are close enough to globally unique you can easily combine many systems and never ever have a duplicate just because the number space is so massive.