FreeLSD

Не совсем так. В файл пришлось бы писать мне, если бы я хотел изменить кодировку одной строкой кода, т.к. 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С читать коды символов в чем-то кроме юникода. И вообще не представляю, как их выдает компонента. Поэтому мне бы избежать всяких преобразований вообще. Понятно, что можно взять и наваять что-то самому. Но зачем изобретать велосипед, наверняка же такая задача возникала уже в истории человечества :)

А, нет, погорячился. Со строкой все правильно, только от этого не легче. Описание протокола: приходит 5 байт. Компонента говорит, что приходит 5 байт. Показывает строку "Ђ› " Получаю коды символов: 1026 4 8250 0 0 Перевожу их в двоичный вид: 10000000010 00000100 10000000111010 00000000 00000000 Ну и какие же это байты? Длина должна быть 40 бит. Кстати, в строке не все символы отобразились как есть, браузер, похоже, не умеет.

Не, там именно двоичный и протокол описан на уровне битов. Приходят, естессно, байты. Причем и телнет, и компонента, которой я пользуют, эти байты показывает в виде строки. Вот последний пример: компонента говорит, что пришло 5 байт. И показывает мне строку из 10 символов! То есть, видимо, значение этих байтов не позволяет нормально преобразовать их в символьную строку. Само собой, если я начинаю перегонять их обратно в двоичный код, получаю фигню. Мне бы увидеть один в один что пришло. P.S. использую mswinsck.ocx.

Возникла такая вот потребность. Работаю с устройством, протокол которого описан в двоичном виде. Телнет же и все компоненты, которые я знаю, возвращают символьную строку. Если её просто перевести в двоичную форму (через коды символов), результат получается, мягко говоря, не совсем соответствующий описанию. При этом видно, что частично всё же получается то, что ожидал, частично же - какая-то пурга. Хочу увидеть, что же говорит система сразу в двоичном виде, потому что подозреваю "испорченный телефон" при преобразованиях туда-обратно. Вот только не могу найти, каким способом это сделать. Задача - подключиться на нужный адрес/порт, отправить туда определённое значение и получить двоичный ответ. Гугление дает массу вопросов на эту тему и что-то совсем не даёт ответов :unsure: То ли я не так спрашиваю, то ли действительно проблема...

На ГРЭСе, смотрю, открылись боксы и по пути туда на другой стороне тоже. Кто-то тестировал уже?

В Крым шлют нормально? Адрес как писать? Чем оплату принимают (есть только Мастер)?

Есть на одном участке М4

Христиане "рубили друг другу головы" на почве религиозных разногласий еще лет 300-400 назад (гугенотские войны, например). С той поры все б/м успокоилось. Хотя, на мой взгляд, причины были больше политические, а религия - только повод. С другой стороны, не мне, секулярному, судить, насколько остро тогда воспринимались такие нюансы, о которых нынче не всякий ревностный прихожанин имеет четкое мнение

Увы, но это так. У меня знакомая спокойно ехала со скоростью 60 км/ч по правой полосе, когда ей в машину со встречки прилетел Киа Спортейдж (про эту аварию тут много писали). Чудом все остались живы. Так что успокаивать себя вы можете. но на деле от вас ничего не зависит. Вы можете только увеличить вероятность ДТП своим поведением, но никак не уменьшить. Хотя не увеличивать то, что и так чересчур - это действительно правильный выбор

BHyK, магнит? Видел сегодня по 350 на РР. Очевидные плюсы - компактное, удобное в регулировании положения. Минусы - хз как мощное магнитное поле влияет на телефон и не уверен, что на тряской дороге не будет вибрировать :) Вообще походил, посмотрел, есть интересные варианты. Понравилась держалка от defender за 450, компактная, легко крутится во всех направлениях, держится, как уверяют, хорошо (один продавец мне сказал так: "ну вы же понимаете, на торпеду - это только двусторонний скотч или саморезы, остальное фигня" ).