Data Matrix, GS1, код маркировки и разделители

Материал из ismp.wiki
Версия от 10:39, 1 ноября 2019; Alexey Timchenko (обсуждение | вклад)
(разн.) ← Предыдущая | Текущая версия (разн.) | Следующая → (разн.)
Перейти к: навигация, поиск

Формирование GS1 DataMatrix

Цитата из Описания АПИ СУЗ:

Для корректного формирования GS1 DataMatrix необходимо в начало получаемой строки кода маркировки добавлять признак символики – ASCII232, перед конвертацией в DataMatrix, в соответствии с требованиями GS1 General Specification, в противном случае технические средства не распознают код правильно и не смогут его корректно обработать.

Ниже приведены ссылки на спецификации:

Проверка корректности GS1 DataMatrix

Для проверки корректности штрихкода GS1 DataMatrix можно использовать Приложение для проверки кодов маркировки от компании Клеверенс.

Мысли по теме использования и неиспользования стандартов

Скомпилировано со слов Сергея Баженова и скоро будет подвергнуто редакторской правке (по материалам Главного чата маркировки от 2019-07-03)

Возможно я опять выступлю адвокатом дьявола, но действительно, по стандартам GS1 если длина поля фиксирована, то после него никаких разделителей нет. а если длина поля не фиксирована, то обязателен разделитель, кроме случая, когда дальше уже ничего нет. это касается многих кодировок, начиная от EAN-128 и ISO/IEC 15424 и заканчивая DataMatrix когда в сего пишется код GS1. это касается именно данных в штрихкоде. на печать можно выводить скобки или как-то еще изголяться.

Если разрешите я могу рассказать как должно быть и как сделано

Есть грубо три разных мира: как должно быть, как есть на практике вообще и как есть на практике в Маркировке. сразу оговорюсь, что в маркировке всё очень даже неплохо

Как должно быть: есть стандарты GS1, которые никто не читает. Они говорят, грубо, что есть информация, которая может быть зашита в штрихкод. При этом штрихкод — это никакая ни строка текста. Штрихкод — это полоски. То, что написано обычно под штрихкодом называется "человеко-читаемой формой представления" информации, зашитой в штрихкоде (а не самого штрихкода!!). у штрихкода нет никакой строки. никакая строка не соответствует никакому штрихкоду. есть информация, её можно представить в виде строки, а можно в виде штрихкода.

простая аналогия: есть яблоко, есть фото яблока и есть текстовый рассказ о яблоке. попытки получить из строки под штрихкодом сам штрихкод, если читать стандарты, примерно равны получению из рассказа про яблоко фотку этого яблока

Ну тут есть засада про скобки. Далее, есть вот это представление со скобками. Это всего-лишь рекомендованная человеко-читаемая форма представления. И с ней есть проблема, о которой тут только что говорили: порядок полей не определен никаким стандартом. У штрихкода нет двоичной записи. Есть информация, которую хотим закодировать (объект с полями), и есть стандарт как её преобразовать и закодировать. Бинарный формат есть только у EPC

Про то "как должно быть" это по сути всё. Основная сложность состоит в том, что по стандартам основанием для штрихкода служит информация, карточка товара грубо говоря, поля, значения, а никакая не строка. Но этого никто не понимает и использует строку "типа штрихкод", как идентификатор. Как есть: люди пихают в штрихкоды что хотят. Без специальных символов, со специальными символами и т.п. причем и в России и в Европе.

простой пример: есть кодировка CODE-128, которая отвечает за то, какими штрихами какие символы надо кодировать. есть штрихкод EAN-128, который использует кодировку CODE-128 для кодирования данных о товарах, паллетах, поставках и т.п. Он отличается от CODE-128 тем, что в нем должны быть префиксы, разделители, структура есть. CODE-128 ничего не говорит про структуру, только про штрихи. а EAN-128 говорит про структуру как информация должна быть подана но сплошь и рядом на товарах и паллетах можно увидеть: как бы EAN-128 распечатанный при помощи других штрихов, например CODE-39 или используют кодировку CODE-128, кодируют с её помощью строку "(01)12345..." прямо со скобками и думают, что это типа EAN-128 и прочие прелести

Как сделано в маркировке: всё очень неплохо, все стандарты соблюдены, кроме того фиксирован порядок датаайтемов (полей данных) как в самом штрихкоде, так и в строке КМ. Большое везение ребят в том, что они сами генерируют КМ (строковое представление), а не получают его с рынка "как есть"

К сожалению это не решает всех проблем неграмотного использования, особенно если компания хочет сама печатать DataMatrix, потому что "нельзя просто взять и пихнуть КМ в DataMatrix", потому что КМ - это, с натяжкой, человеко-читаемое представление, а DataMatrix - это штрихкод, из представления надо вынуть данные, разобрать его на поля, и потом эти поля правильно собрать в зависимости от используемого принтера или библиотеки кодирования штрихкодов. Нет термина никакого, как такую строку назвать, любую такую строку. Я читаю любой штрихкод, получаю строку текста - нет названия для этой строки.

Скобки не входят в AI, верно. Но AI это про штрихкоды формата GS1. А в DataMatrix можно печатать любую дичь. Нет никакого запрета.

Условно: есть русский язык и русская азбука. есть формат документа ТОРГ-12. азбука - это про DataMatrix. ТОРГ-12 - это про кодирование КМ в DataMatrix по правилам GS1. В азбуке нет скобок, но они есть в ТОРГ 12. Но никто не мешает в поле для цены пихануть скобки. Примерно такая ситуация

Скобки как символы разрешены в DataMatrix, более того туда можно кодировать например URL, как в QR код.

Вот алфавит из датаматриксов ЦРПТ: ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789!""%&'*+-./_,:;=<>?

Да, как видно они не используют скобки хотя и могли бы. И даже если под штрихкодом напечатаны скобки - это не значит, что скобки есть в штрихкоде

Есть другие причины использования кода разделителя из нечитаемой части ASCII. Причины простые - все печатаемые уже заняты для того, чтобы закодировать что-нибудь печатаемое. А всё управляющее и "для сканеров" использует непечатаемые символы

Если использовать скобки как разделители, то уже нельзя будет без танцев с бубном закодировать скобку в штрихкод. И хотя правила таких танцев давно известны и используются в XML и JSON, служебные символы можно можно экранировать, но это породит свои траблы с тем, что у экранированной строки нет префикса была она экранирована или нет, не надо ли её еще раз разэкранировать. таких багов когда что-то два раза экранировали полно в коде веб-обмена В общем у меня всё

А, нет, сорри. Одно замечание. Как мы боремся с этим адом в своём софте. У нас есть понятие сырых данных и форматированных данных. В отличие от маркировки к нам могут прилететь данные из сторонней системы, со скобками, с любой дичью. в таблице данных это всё льется в таблицу колонку сырых. и есть вычислимая колонка, которая любую дичь приводит к правильному формату