Знатокам штрихкодов : Кодирования русских букв в Code-128 #760546

Первый вопрос можно ли в нем вообще кодировать русский алфавит я закодировал номер документа 361д-15 у меня получилось 361l-15 Можно ли его нормально закодировать и если как до где копать ?

Не проще использовать УИД?

Клиент требует палетную этикетку с номером накладной в Code-128

Глобальный контекст (Global context) Base64Строка (Base64String) Синтаксис: Base64Строка(<Значение>) Параметры: Тип: ДвоичныеДанные. Двоичные данные, которые необходимо закодировать по алгоритму base64. Возвращаемое значение: Тип: Строка. Описание: Получает строку, закодированную по алгоритму base64. Доступность: Тонкий клиент, веб-клиент, сервер, толстый клиент, внешнее соединение, мобильное приложение(клиент), мобильное приложение(сервер). См. также: Глобальный контекст, метод Base64Значение --------------------------------------------------------------------------------      Методическая информация

code 128 русских буков не знает. Исзобретай какие-то велосипеды

да и простейший это

+

строку с номером в файл, потом из этого файла двоичные данные, потом из них базе64строка? это простейший штоле? о_0

какие в жпо двоичные данные? может иногда лучше промолчать если не в курсе да?

+

Base64Строка на вход двоичные данные требует. Автору надо в ШК поместить номер документа. Как из номера документа получить Base64Строка?

может просто напросто: м?

да куда уж проще-то...

КодироватьBase64(365l-15) ==> MzYxC0xNSAgIB//

осталось найти еще 60 строк, которые раскодируют это обратно

все правильно только латинские буквы остались и спецсимволы все что подходит для Code 128b

там внизу ссылка вообще то...

361д-15 мне кажется - так проще. Две строки, штатно, и без ссылок в какой-то хрен знает куда

можно и так, а можно и вообще транслитом воспользоваться

для транслита тоже надо две функции по полста строк руками писать

там по 5 строк всего через цикл и стрзаменить

Голосую за этот вариант

ну, во-первых, для обеспечения преобразования туда-сюда без потерь всяких Ж, Ш, З и т.д. надо больше 5 строк и СтрЗаменить. Во-вторых - какая разница, сколько писать, если условия таковы, что все написано за нас?

где нибудь указание на версию платформы 1С увидел?

Платформа 8.2 Сканер считал что то типа : 361LMH Короче тема пустая ибо сканер русские символы не распознает в CODE-128

зачем выводи в штрихкод КодироватьBase64(361д-15) кодировать тебе понадобится, при обработке данных от сканера

Дык декодировать буду не я а клиент

и что клиент будет делать с номером твоего документа? Ты этот номер ему в каких-то электрических выгрузках передаешь что ли?

или это номер тебе клиент дает?

предлагаю отказаться от кириллицы в номерах документов

+ ну или запилить свой стандарт вместо всех

Я бы не заморачивался с base64, а сделал бы свою таблицу соответствия русских букв и латинских, что-то типа транслита. И ей бы кодировал. Это будет экономичнее, потому что base64 очень громоздкий

осталось понять - если в сиходном сообщении есть родные латинские буквы - при раскодировке - что делать..?

стандартно "а">"a", "a">"a", "">"\"

+ из "ТестTest" будет "TestTes "

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

Ну да. Или же, наоборот, использовать двухсимвольные последовательности для латиницы, если вероятность ее появления в сообщении ниже, чем кириллицы. А может, у автора вообще исключена латиница. Мы ж не знаем.

заметил, но дело в том что там ничего не написано по поводу стандартов. Если клиенту нужен SSCC, то я не знаю, при каком там кириллица

да и SSCC это EAN (или GS1) - 128, а не CODE128

Функция КонвертацияИзКириллицы(Знач ИсходнаяСтрока)     СтрокаЛатиницы  = "abcdefghijklmnopqrstuvwxyz""#$&',./:;<>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[]^`{|}~";

Что мешает в Штрихкод сформировать на основе УИД, а под ним вывести номер документа строкой )))

зачем столько кода? ЗЫ строки поправить замен как нуна, переделка для замен "Ш">"SH" тоже не проблема

поинтересуйся у клиента для которого стараешся, пусть приведет пример штрих-кода с кириллицей который они успешно считывают. А то сдается мне если не через URL кодирование то еще и кодовую страницу будете согласовывать, UTF, или вообще KOI-8 :)

если бы не разное количество букв в алфавитах ...

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

не вижу проблем использовать " " в кодовых строках и по 2 символа " ш ч"="shch"

в привели нормальный вариант, изобретать велосипед не нужно, уже есть - ASCII (любая другая кодировка), клиенту сказать, что закодировано по международному стандарту, пусть расшифровку делает в обратном порядке, будет возмущаться - на педивикию отправить и сказать, что он не в тренде и не пользуется общепринятыми Мировыми стандартами пс. а придумывать свою таблицу кодировки - себе дороже, потом придется объяснять расшифровщику что да как, интересно что он еще подумает

я может чего не понял... в 1с юникод Для Н = 1 По СтрДлина(Строка) Цикл если разбор не в 1с, то инструментами среды Encoding там или еще чего

в чем дело то, полсотни постов ;)

ASCII по большому счету стандарт только на первые 128 символов. Есть несколько вариаций размещения в верхних 128-256 кодах ASCII национальных символов что и обозначается кодировкой. Например KOI8R, CP866 и т.д.

+ поэтому я и говорю что в таком варианте ему еще и кодировку с клиентом придется согласовывать.

интересно как будет выглядеть 361д-15 в казахском варианте, тогда надо и номенклатуру кодировать и все остальные тексты, что бы клиент, родной, не чувствовал себя ущемленным

мне кажется его клиенту для которого он старается еще не попадались документы с кириллицей в номере.