Я, вероятно, не смог четко донести смысл текста. Дело не в Windows и не в самой утилитке. Я попытался предложить концепцию управления ресурсами строк (методы идентификации, подходы к переводу и т.д.). Ссылка на репозиторий дана только в качестве пруфа. Сам исходник не большой. Вот ссылка на него: https://github.com/papyrussolution/OpenPapyrus/blob/master/Src/PPLib/STRSTORE.CPP
Насчет примеров использования, да - я должен был это включить, но не включил. Исправляюсь:
//
// c++. Строка, идентифицируемая мнемоникой
//
PPLoadString(PPMSG_ERROR, PPERR_NMATCHBILLAMT, fmt_buf);
//
// c++. Строка, идентифицируемая символом
//
PPLoadString("appellation", temp_buf);
//
// Java (Android). Строка, идентифицируемая мнемоникой.
// Для Java мнемоники автоматически генерируются так же как и для C/C++.
//
String err_msg = app_ctx.GetString(ppstr2.PPSTR_ERROR, ppstr2.PPERR_STQ_POSTDOCUMENTFAULT);
//
// Java (Android). Строка, идентифицируемая символом
//
title_text = app_ctx.GetString("unmatchedmarks");
По поводу GNU gettext. Я долго смотрел на него и примерялся. Его популярность восхищает. Однако ж, его основное назначение - организация перевода на другие языки, а не управление текстовыми ресурсами. И еще - идентификация по тексту, примененному в исходно коде очень уж зыбкая.
Отдых - важная проблема. Я этот вопрос почти не затрагивал потому что, в силу личных особенностей и текущего момента, мне важнее забить работой и физическими нагрузками все время. Но я чувствую, что при таком режиме есть утечка сил. Кстати, о решении задач. Как только стал применять описанных подход сразу в очень многих заброшенных задачах прорыв случился. И еще, я в прошлом году это придумал. В том же году я бросил курить после почти 40-летнего стажа. Так вот, я считаю фунпацу куда большим личным достижением нежели отказ от курения.
Я брал аппроксимирующую прямую и определял угол ее наклона. Любой шум при таком подходе сглаживается. Длина плеча была большая - несколько часов (иногда больше 24).
Ничего не понял. Добротный проект, результат выглядит классно. Парень подробно и обстоятельно все описал. Кто все эти люди, кто ему минусов накидали? Мне не кажется, что проект способен принести адекватную отдачу, но это ж не технический аспект.
Мы разделяем код и текст в большом проекте openpapyrus много лет (c++). Должен признать проблема очень тяжелая и технически и организационно. Текст и код разделяются руками — автоматического разделения нет, хотя и планируем реализовать хотя бы частичное. https://github.com/papyrussolution/OpenPapyrus/tree/master/Src/Rsrc/Str
Основной файл ppstr2.txt при сборке проекта парсится, формирует идентификацию, код получает строки по специальным идентификаторам частью целочисленным, частью символьным.
Openpapyrus — исходные коды, атол, вики принт, пирит, штрих фр, чесзнак, егаис, меркурий, все оборудование и вообще все за даром кроме живых консультаций.
А у меня с первого раза в mysql принять получилось. Я, правда, волшебником импорта пользовался (начал раньше, чем ответ от вас получил). Не может быть дело в изначальных параметрах создаваемой таблицы? (я не большой спец в mysql).
Мы прогнали проверку текста и не нашли инвалидных utf-8 символов. Не могли бы вы скинуть скрипт, которым забираете в MySQL данные? Мы у себя прогоним его и исправим выявленные дефекты. Вам, естественно, сообщим.
И вам спасибо за ссылку. Если нам удастся взять из той базы полезные данные, мы их выложим там же и в открытом доступе будет больше хороших данных. Ну и благодарим за то, что прижали наше самомнение — мы были уверены, что выложили самый большой объем — ошиблись.
Весьма забавно. Дело в том, что текст действительно переведен с помощью google translate. Но вот, наряду с другими мелочами, «as gratitude» было вручную вставлено вместо предложенного google'ом «as a thank you».
Так это вы сами себе ответили. Производитель зарегистрирован, а данных о товаре нет. То есть накладки не будет, а вот информацию о том, что это за товар вы не получите. Я не к тому, что gs1 плохой, а к тому, что 1000 цветов лучше, чем 1.
Этот код принадлежит очень приличному производителю. Поищите его в google — он более чем актуален (по крайней мере де-факто).
Тема регистрации штрихкодов у разных организаций относительно недавно обсуждалась на хабре. Мне к этому нечего добавить. В этой идентификации важен не столько официальный регистратор, сколько фактическое принятие операторами рынка.
GS1 — только EAN.
И ean'ы не все (4041485044338 например — вполне популярный товар).
Весь список вы скорее всего не получите, соответственно, к примеру, сложный анализ большой выборки наименований провести будет не просто (или невозможно).
Можно продолжить.
Но самое главное, мы просто дарим справочник тем, кому он нужен. Кому — нет, тот ничего не теряет.
Это почти невозможно. Вероятно, есть проблема с теми наименованиями, в которых встречаются упомянутые вами проблемы с utf-8. Мы в функцию формирования данных добавим валидацию и корректировку таких символов.
Ух. Это - скорее будет документация, а не ознакомительный текст. todo мне.
Я, вероятно, не смог четко донести смысл текста. Дело не в Windows и не в самой утилитке. Я попытался предложить концепцию управления ресурсами строк (методы идентификации, подходы к переводу и т.д.).
Ссылка на репозиторий дана только в качестве пруфа.
Сам исходник не большой. Вот ссылка на него: https://github.com/papyrussolution/OpenPapyrus/blob/master/Src/PPLib/STRSTORE.CPP
Насчет примеров использования, да - я должен был это включить, но не включил. Исправляюсь:
По поводу GNU gettext. Я долго смотрел на него и примерялся. Его популярность восхищает. Однако ж, его основное назначение - организация перевода на другие языки, а не управление текстовыми ресурсами. И еще - идентификация по тексту, примененному в исходно коде очень уж зыбкая.
Так последний абзац же.
Отдых - важная проблема. Я этот вопрос почти не затрагивал потому что, в силу личных особенностей и текущего момента, мне важнее забить работой и физическими нагрузками все время. Но я чувствую, что при таком режиме есть утечка сил.
Кстати, о решении задач. Как только стал применять описанных подход сразу в очень многих заброшенных задачах прорыв случился.
И еще, я в прошлом году это придумал. В том же году я бросил курить после почти 40-летнего стажа. Так вот, я считаю фунпацу куда большим личным достижением нежели отказ от курения.
Я брал аппроксимирующую прямую и определял угол ее наклона. Любой шум при таком подходе сглаживается. Длина плеча была большая - несколько часов (иногда больше 24).
Ничего не понял. Добротный проект, результат выглядит классно. Парень подробно и обстоятельно все описал. Кто все эти люди, кто ему минусов накидали?
Мне не кажется, что проект способен принести адекватную отдачу, но это ж не технический аспект.
Вы правда полагаете, что серийные номера и микродоработки решают проблему егаис и чз маркировки?
Мы разделяем код и текст в большом проекте openpapyrus много лет (c++). Должен признать проблема очень тяжелая и технически и организационно. Текст и код разделяются руками — автоматического разделения нет, хотя и планируем реализовать хотя бы частичное.
https://github.com/papyrussolution/OpenPapyrus/tree/master/Src/Rsrc/Str
Основной файл ppstr2.txt при сборке проекта парсится, формирует идентификацию, код получает строки по специальным идентификаторам частью целочисленным, частью символьным.
Openpapyrus — исходные коды, атол, вики принт, пирит, штрих фр, чесзнак, егаис, меркурий, все оборудование и вообще все за даром кроме живых консультаций.
Тема регистрации штрихкодов у разных организаций относительно недавно обсуждалась на хабре. Мне к этому нечего добавить. В этой идентификации важен не столько официальный регистратор, сколько фактическое принятие операторами рынка.
И ean'ы не все (4041485044338 например — вполне популярный товар).
Весь список вы скорее всего не получите, соответственно, к примеру, сложный анализ большой выборки наименований провести будет не просто (или невозможно).
Можно продолжить.
Но самое главное, мы просто дарим справочник тем, кому он нужен. Кому — нет, тот ничего не теряет.