FreeLSD

Отлично, по полочкам: Лебедев Артемий (не "тот самый" :) ) Кстати, при желании это можно приложить и к нынешней ситуации на Украине. Сразу становится видно, кто страну просирает, а кто "наследует землю".

Наилучшие пожелания!

С выбором объектов ремонта вечная проблема, и не только у нас. Объяснение может быть только одно: на некоторых улицах лежит проклятье :blink: Нужно сильное колдунство Впрочем, уже не раз упоминали, что активность местного населения способствует продвижению "воза". Но это в селах работает, как в городе - не знаю.

А, ну если он в юникоде такой же, то вопрос снимается. Он и так меньше 255 и в таблице искать его нужно не будет Кстати, всё работает уже, быстро и точно.

Это та самая компонента, стандарт де-факто для работы с TCP из 1С и не только ) А это хорошее решение, но пройденный этап - чтобы с ним работать, надо TCP порты сделать виртуальными COM-портами, а это дополнительная "прокладка", понижает производительность (проверено) и с определенного количества (примерно три десятка портов) начинает глючить (проверено). Поэтому сейчас ориентируемся на работу с TCP портами напрямую. Кстати, vk_rs232 написана довольно давно энтузиастом и до сих пор повсеместно используется, потому что 1) бесплатна 2) проста 3) функциональна. Пока работали с ней, горя не знал - у нее есть вариант, который как раз выдает байты в шестнадцатиричном виде.

Масса-К, описание на сайте Еще раз - так байты выдаются компонентой, которая читает порт. Других вариантов не предусмотрено, самому писать "велосипед" неохота. Фишка в том, что свой протокол у каждого производителя, иногда еще на разные модели отличаются. Стандарта никакого нет. Поэтому каждого нового приходится вносить отдельно. Чаще они достаточно просто выглядят, отличия в нюансах, но встречаются разные приколы. А конкретно этого нельзя игнорировать, это очень популярные весы.

Да, собственно, уже. Вопрос только с одним символом - который в анси = AD. Таблицы с интернетов его не включают, т.к. браузеры его не отображают (. Вот думаю, как его влепить. Остальное вроде нормально работает. Я таблицу делал в hex'е, так что шестнадцатиричные в двоичные - ну так это еще проще.

Да ради бога! Кладёшь ружжо на землю, из мишени превращаешься в гражданина, останется только отсидеть положенное и вперёд - люби и будь любим

Мне бы в последнюю очередь пришло, что для ребенка Маяковский - это конкретный человек Она же про него только что услышала ) В определённом возрасте дети часто пытаются встроить свои фантазии в реальность (или наоборот), а может, просто не делают между ними различия. Девочка обнаружила готового персонажа и обрушила на него свой креатив - что в этом необычного? :) А разговоры с настоящими мёртвыми поэтами - это из фильмов ужасов, там такое возможно

Не совсем так. В файл пришлось бы писать мне, если бы я хотел изменить кодировку одной строкой кода, т.к. 1С умеет это делать только с текстовыми файлами. Строка, которая пришла с устройства - она в памяти. Поэтому, чтобы не грузить систему медленными операциями, пришлось писать свою функцию преобразования, тем более что это не так трудно. Время реакции критично - если на мониторе вес обновляется визуально позже, чем на дисплее весов, это плохо А поиск по упорядоченной коллекции времени практически не отнимает, тем более что вызываю я его только при необходимости - если код символа вылазит за пределы байта.

Тут один общий знакомый в фейсбуке очень правильно сказал: 1. У правоохранителей задача - сохранить жизни третьих лиц и по возможности своих сотрудников; 2. Задачи сохранить жизнь "человека с ружьём" у неё НЕТ; 3. Психолог привлекается в подобных ситуациях только для одного - спасти заложников, сколько получится. Если заложников нет, полиция/спецслужбы просто выполняют задачу №1. Какие тут могут быть варианты вообще? Что тут обсуждать? Полиция выполнила свою задачу, выполнила в рамках закона. Выйти живым у "стрелка" есть только одна возможность - положить оружие на землю и поднять руки над головой повыше. И то лучше мееееедленно. А уж потом там судебные эксперты могут рассуждать про обсессивно-компульсивное и аффекты.

Я уже потерял нить, что сейчас-то обсуждаем? :) Что еще не прояснили в этой ситуации? Или уже вообще за жизнь разговор?

Ну не столько жалко диск, сколько время на файловые операции. В структуре найти буковку проще и быстрее, чем писать/читать, к тому же за кадром 1С наверняка похожую операцию выполняет Так что не поленился забить таблицу символов. Тем более что ;)

Таким путем и пошел. Учитывая, что 1С умеет менять кодировку текста только через файл (!), пришлось загнать таблицу кодов в структуру и искать в ней символы (ищу только если КодСимвола() получается больше 255). Вроде пока работает )

Компонента выдает строку. Во всяком случае, 1С получает данные уже в виде строки. Дальше проблема в том, что функция КодСимвола() работает только для unicode. Но возможности преобразовать кодировку текста вроде имеются. В крайнем случае можно нарисовать свою. Сейчас буду пробовать Писать программку (да и заменять компоненту) - это крайний случай, если уж совсем ничего не получится. Дело в том, что накопили уже разборы протоколов для почти десятка разных весов, все это при замене компоненты переделывать придется. Просто у всех значения веса передаются "as is", там неважно, в какой анси/шманси цифры идут. А тут, блин, "...в прямом коде в двоичной системе счисления ..." да еще с обратным порядком байтов (а знак там потом отдельным битом в следующем байте).

Как? :) Именно этого я и хотел бы. Но компонента отдает именно строку, а 1С сама не умеет "готовить" ТСР А вот таблицу, видимо, придется какую-то использовать, только какую, не знаю. Дело в том, что и то и то - юникод. Только, как выясняется, раскладки разные. Чтение информации с весов.

Ну тут речь-то не о визуальном представлении. Компонента передает строку, сформированную символами, полученными из определенных кодов. 1С получает эту строку и вот тут начинается интересное. Насколько я понимаю, строка передается в виде кодов символов. Символ с кодом 168, который в английской раскладке = "¨", отображается в 1С как "Ё". Но меня-то интересуют именно коды. И вот код этого символа, когда я его получаю, равен уже 1025. Более того, если я прямо в отладчике 1С пишу ALT + 0168, вижу "¨", если ALT + 1025 - "Ё". Получается, компонента виновата? Но она не знает ничего о раскладках, а 1С использует ту же системную.

Возник вопрос: а если там действительно разные таблицы кодирования? В Юникоде символ с кодом A8 - это http://www.fileformat.info/info/unicode/char/a8/index.htm. Можно ли как-то быстро определить, в какой существующей таблице этот код соответствует символу http://www.fileformat.info/info/unicode/char/0401/index.htm?

hex A8 = dec 168 Набираю ALT+168, получаю "¨". Почему-то компонента передает "Ё"

Как работает компонента, понятия не имею ) Это ActiveX бибилиотека, часть Visual Studio, насколько я знаю. Файл mswinsck.ocx. 1Сники часто его используют, посколльсу стандартный, легкодоступный и легкоприменяемый. К 1С подключается как обычный ActiveX компонент. До сих пор проблем с ней не было, это первый случай. Да и то не факт, что именно с ней проблема, возможно, проблема в разных таблицах символов. На что заменить, не знаю, вот и ищу. 1С поддерживает кучу способов обмена, вот только TCP/IP среди них почему-то и нет. Почему и приходится рассчитывать на внешние компоненты.

Пытаюсь понять логику, по которой образуется строка. Пример: Putty показывает байт A8. mswinsck передает в 1С его в виде буквы "Ё". 1С определяет, что код этого символа - 1025 (десятичный). Но это не соответствует шестнадцатиричному! Вот и возникает проблема.

Там мне строка и не нужна. Мне нужен сам байт, как есть, пусть как Putty делает, в шестнадцатиричном виде хотя бы. Вот компонента для COM порта, популярная у 1сников, это умеет. А для TCP - ничего пока не нашел.

Собственно, послушать уже получилось. Видно, что даже в шестнадцатиричном виде там все норм. Проблема начинается в том месте, когда компонента пытается сделать из этого строку. Поэтому теперь вопрос стоит так: а неужели вообще никому никогда не нужно было видеть "приход" как есть, без дурацкого перевода? Потому что найти такую компоненту пока не удалось, хоть сам садись пиши.

Ну вот то, что я знаю/понимаю: 1. Устройство (весы). Имеет IP-адрес, слушает на определенном порту. Принимает запрос и возвращает 5 байт. 2. В этих байтах имеют значение отдельные биты (так организован протокол), к тому же часть данных передается в обратном порядке (сначала второй байт, потом первый). 3. Компонента mswinsck.ocx, получив эти 5 байт, выдает их в виде строки (т.е. байты уже преобразованы в символы). Попытка преобразовать и обратно хотя бы в 16ричный код дает иногда нормальный, иногда странный результат. Putty видит все как надо, хоть и в 16ричном, а не двоичном виде. Так что проблема все-таки в преобразовании значения в символ. Вывод: с используемой компонентой вряд ли можно добиться нормального результата, хотя бы потому, что принципы "озвучивания" ею байтов не ясны.

Я понимаю, что проблема именно в этом. Но я не могу заставить 1С читать коды символов в чем-то кроме юникода. И вообще не представляю, как их выдает компонента. Поэтому мне бы избежать всяких преобразований вообще. Понятно, что можно взять и наваять что-то самому. Но зачем изобретать велосипед, наверняка же такая задача возникала уже в истории человечества :)