new_year

Форум

Главнаяtwo_oceans

two_oceans

Форум

Дата создания

Выбрать дату в календареВыбрать дату в календаре

Тема

Сообщение

Упорядочить

Выбрать дату в календареВыбрать дату в календаре

Загрузка ЛС через шаблоны
 
[quote:gbou89ro]Плюс большинство из них - по нанимателям муниципальных квартир, т.е. можно скопом получить идентификационные данные через муниципалитет.[/quote:gbou89ro]Опять же если данные есть у муниципалитета. Если оформляли в недавние годы, то наверно есть свежие данные, а если давно, то лучше собирать (даже если есть, например, паспорт, то его могли заменить - есть случаи когда женщины меняли паспорт 5-6 раз за 3 года).

Правда, ОМСУ может запросить снилс из ПФР [URL=http://smev.gosuslugi.ru/portal/services.jsp#!/F/SPFRzaprossnils/3.00/p00smev/SID0003619]через сервис СМЭВ[/URL], но есть небольшая загвоздка - помимо ФИО нужны пол (для "неславянских" ФИО разобрать бывает не просто) и полная дата рождения (а раньше в документах часто оставляли только год), для точности запроса нужны данные разворота паспорта. Итого: какие-то данные получить конечно можно, но свести к нулю количество отсутствующих/неверных сведений только по документам из архива в общем случае не выйдет. Соответственно, лучше сохранить документ который получили откуда-то на случай вопросов в достоверности данных.
Если бы не было вопроса о достоверности, можно было забить значения снилс, предназначенные на случай, когда у человека нет снилс (примерный вид 000-000-001 ХХ, первые нули, потом 001, 002 и т.д., в конце контрольные цифры) или тот самый фиктивный паспорт "12 34 567890".
Новые требования к протоколам общих собраний МКД в 2019 году
 
[quote:jek7lkor]предпочитаю ХП и их дочку.[/quote:jek7lkor]Согласен. Однако в последнее время ХП стали делать технику, которая заточена на Windows 10 (у нового мфу Семерка принтер видит, а сканер нет) и нежная - если положить черновик, то наматывается всякая грязь на детали и появляется полоса. Зато предыдущая линейки с сетевым интерфейсом классная - можно по сети сканировать (без податчика конечно смысла немного, но пользователи, желающие сканировать без переключения мфу на их комп наконец-то замолчали).
Сканер с податчиком и двусторонним сканированием это кайф - 1 такой в фин.отдел купили, подцепили к сети. Теперь приходят сотрудники бросают пачку документов, аппарат сам пдфит и закидывает в сетевую папку. Хотя соглашусь, что сканер отдельно + принтер отдельно лучше МФУ - уже несколько раз мфушки отказывались печатать только потому что стекло сканера покрылось пылью изнутри.
Еще у нас куча canon стоит, потому что их картриджи с ХП совместимы. От самсунгов (а также  брозеров, ксероксов) планомерно отказываемся - дорого в обслуживании.
Kyocera кстати пара штук есть и впечатление пока очень благоприятное, особенно если подцепить напрямую к сети - чего там только сетевого не поддерживается. Правда отключить лишнее вроде SNMP не вышло, попутно отключилась и стандартная печать по TCP/IP, но когда-нибудь и до этого руки дойдут.
Договор с РКЦ - платежные документы в ГИСе.
 
[QUOTE]skad888 пишет:
А по теме, Вам дешевле 3 девушек нанять и посадить за компы, чтобы руками в шаблоны набивали.[/QUOTE]Похоже РКЦ именно это и сделает + накрутка.
Шаблон импорта показаний ОДПУ
 
Тут хотелось бы уточнить эти 2 прибора связаны или нет? Если не связаны - например, один считает воду на кухне, другой в санузле, то все как ответили выше, можно несколько. Хотя не принципиально присвоить кухне, к примеру, номер помещения 1, санузлу - 2.
А вот если связаны - например, на входе холодной воды в квартиру и на выходе на приусадебный участок (за холодную начисляется по ПУ на входе, за канализацию - только разница между ПУ), то нужно еще указывать их положение.
Просрочил ввод показаний счётчиков
 
Где-то на форуме кажется было пояснение, что имеются в виду начальное значение на время когда ПУ внесен в ГИС, а не на момент ввода ПУ в эксплуатацию. Что было до внесения информации в ГИС, ГИС не волнует (но возможно взволнует проверяющих почему долго не вносили), потому и ввода информации за прошлые периоды нет. Например, собрали информацию на 01.06.2017, в июне внесли ПУ, пишите "последнее известное" на 01.06.2017 в поле начальное в ГИС, потом ежемесячно вносите свежие данные.
В идеале предполагается (на будущее), как ввели в эксплуатацию - как можно скорее в вносите, чтобы не было разрыва в показаниях.
Поддержка длинных строк
 
Итак, разобрался с файлом в котором все объявления пространств идут на пространство по умолчанию. 3 подписи проверяются (были небольшие проблемы с определением какой сертификат к какой подписи - второй и третий сертификат не добавлялись). Казалось бы отлично, но проверка на наличие четвертой вываливается с ошибкой "Недостаточно памяти". В системе-то память есть, но видимо heap закончился.

Глянул сколько памяти и остался в недоумении - после третьей подписи Виндоуз показывает порядка 648 Мб (из них 112 Мб Working Set (в оперативке), остальное в подкачке), мини-менеджер памяти по суммированию выделения и освобождения - 612 Мб (разница в 30 с небольшим Мб вполне может быть на статические переменные и выдедение на иной памяти кроме компзитных строк), сумма размеров по зафиксированным в мини-менеджере адресам - 43 Мб. Как я понимаю, с такими симптомами... утечка в самом мини-менеджере, буду искать. Вчера вроде бы разобрался с неявными присвоениями, но особо ситуация не изменилась.
Поддержка длинных строк
 
Чтобы проверить на чем запинается проверка ЭП (там тоже такие умники от безопасности, которые не уточняют какая часть подписи неверна) и каноникализацию позаимствовал ответы, пришедшие по запросам через СМЭВ от федеральных сервисов (заведомо правильные). Отправил их на проверку своей каноникализацией. Как оказалось - в ответах как будто специально сделано неканоничное содержимое (нужно добавлять из контекста предков недостающие объявления пространств имен, в основном soap, wsu, ds, также поднимать или опускать объявления на 1 уровень). А еще сортировать пространства имен нужно все же по имени, а не по адресу (вот и несоответствие стандарту).

С ответом Росреестра трудность возникла с тем, что данные ответа от них в виде base64 кодированного блоба между тегами - естественно, 255 символов shortstring не хватило на такой "текстовый узел", пришлось ставить композитную строку. Налоговая порадовала кириллическими тегами, кириллическими атрибутами и кириллическими значениями, пришлось расширить список допустимых символов. Конечно, надо просто разобраться какие символы еще допустимы по стандарту (предположительно в кавычках допустимо все кроме кавычек). ПФР - просто вынос мозга: все объявления пространств идут на пространство по умолчанию (тут несколько не осилил - сложно отличить 2 пространства у которых имя из пустой строки, но разные адреса) и все по правилам: аж три ЭП. Проверка SignatureValue ответа ПФР не проходила, если убрать совсем символы с кодом 10 из SignedInfo. Поэтому все же пришлось их оставить (это по стандарту, за исключением возможного поведения XPath о котором писал вчера). Сочетания символов 13+10,10+13,13 заменяются на 10, с этим проблем не возникло.

В результате улучшений, буквально только что наконец-то получил сообщение, что ЭП-ОВ корректна на странице проверки подписи XML техпортала СМЭВ. И догадайтесь, куда закралась ошибка, после исправления которой свершилось чудо? Вместо Algorithm было написано Algorihtm. /рукалицо
Обнаружилось после введения проверки на алгоритмы (вообще с прицелом на гост-2012, но пока без него) - с проверочных ответов не было ошибки, а со своего запроса алгоритм не выбрался, пригляделся, а там такое.
Ошибки в ГИС (эмоции пост)
 
Я бы где "неоднократно" еще и перечислил номера.. хотя бы один - того обращение, что при ошибке не формируется результат и которое они якобы передали экспертам или обещали исправить в какой-то версии.
Шаблоны показаний ИПУ
 
Похоже что-то неправильно с этими счетами.. проверьте и исправьте даты сдачи показаний либо подождите 15 сентября. Во многих случаях гисовское истек означает "еще не наступил". Также, 20.08 и 20.09 - определенно есть разница.
Поддержка длинных строк
 
Разбирался выходные с переводами строк: все же, как и предполагалось можно без опасений удалить переводы строк из base64 кодированной подписи или сертификата.
Глюк с порчей сертификата при удалении символов и с кодом 10 и с кодом 13 был из-за другой редкой ситуации - при склейке композитной строки, если требуемая длина данных результата была в точности равна длине выделенного буфера, то проверка на выделение дополнительной памяти не срабатывала. А вот при копировании данных в буфер там резервировалось место на терминирующий символ с кодом 0. Таким образом, 1 символ терялся и портил сертификат. Добавил в проверку буфера учет терминирующего символа и сертификат теперь не портится, попутно выводится сообщение если при склейке сумма длин частей не равна длине результата.
Также немного прояснилось, почему кто-то говорит что только символ 13 запрещен, а кто-то советует убирать символ 10 тоже. Соль в том, что XPath при выборке определенных тегов (для фрагмента) может выбрать только теги, но не выбрать переводы строк между тегами (равно как и прочие "текстовые ноды", а в каноническом представлении внутри самих тегах тоже НЕТ никаких переводов строк). В итоге, когда результат XPath проходит каноникализацию переводов строк вообще не остается и весь текст для хэша/подписи представляет собой одну строку. Получается в каноническом фрагменте документа переводов строки нет, но в канонической форме целого документа символы 10 могут использоваться как переводы строк. Во как.

Следующее разбирательство - насчет неразрывного пробела. Так как канонический вид подразумевает приведение к UTF-8, то явно речь не о символе с кодом 160 (замена символа 160 на пробел ломает кодировку UTF-8), видимо придется смотреть стандарт для уточнения.

Вник в каноникализацию еще глубже, оказалось у моей реализации есть определенные проблемы с ancestor context (контекст предков). Если точнее: с наследованием пространств имен и атрибутов которые были объявлены ДО выбранного в каконикализацию фрагмента. Сами теги погоды не делают, а вот пространства имен и атрибуты (да, я удивился, что атрибуты специального пространства xml: также наследуются) наследуются фрагментом. Например, попробовал получить каконический вид целого тега ds:Signature со ссылкой на сертификат и потребовалось пространство wsse для wsse:Reference. Вручную-то конечно добавил, теперь смотрю как автоматизировать.

Основная проблема, конечно, в последовательности формирования документа - сначала формирую подписываемую часть, потом всю "обертку", то есть на момент подписания контекста предков вообще еще нет. Видимо придется делать некую заготовку обертки и ее передать как контекст. Но это тоже как-то извращенно: ведь для каждого фрагмента приводимого к каноническому нужен свой контекст. Жесть.

[SIZE=85px][COLOR=greenpt]Отправлено спустя 16 минуты 29 секунды:[/COLOR][/SIZE]
С Openssl сделал для доменного УЦ на алгоритме shaRSA подчиненный УЦ и из последнего выпустил сертификат сервера. По поводу указания инн и огрн как NumericString  ничего не нашел - вопросы есть, ответов нет. Однако в одном месте высказали предположение что формат никак не указывается, дескать надо вкомпилить в OpenSSL. Скорее всего, способ все же есть, потому что все равно все строки проходят через кодирование ASN1 и формат должен определяться где-то там, но это опять же надо долго разбираться в исходниках OpenSSL.
Поддержка длинных строк
 
За неделю: проверил подписанный файл на техническом портале СМЭВ - там меня обрадовали, что документ соответствует методическим рекомендациям 2.5.5, 2.5.6 и 2.6.0 (на 2.4.x не соответствует), но ЭП органа власти неверна. Подключил самописный модуль каноникализации, увидел, что действительно, был неканоничный вид. Однако и на такой все равно говорит неверная ЭП. Вот такая вот зараза.

Указание NULL (0 с учетом как перенесено на Паскаль) вместо провайдера при открытии хранилища - результат тот же, не находится.

Для разнообразия вчера разбирался с конфигурацией OpenSSL для внутреннего УЦ. Теперь сертификат УЦ гораздо больше похож на корневые сертификаты аккредитованных УЦ. Во-первых, добавил огрн и инн организации - это оказалось довольно просто (пока есть небольшое различие: по приказу ФСБ они NumericString, а у меня вышло UTF8String). Во-вторых, CN написал на русском (этого пришлось увеличить ограничение на длину, так как в UTF8 длина 34 символов вышла около 70 байт, а ограничение по RFC в 64 символа (и OpenSSL его применяет к байтам вместо символов).

В-третьих, разобрался с UTF8 и ASN1 кодированием. Раньше я говорил, что если файл конфигурации в UTF8, то ASN1 кодирование это игнорирует и кодирует второй раз (при этом кодирует как будто символы были в расширенной латинице, то есть и без изначального UTF8 текст с кириллицей портится). Сейчас я разобрался - если текст уже в UTF8, то нужно добавить модификатор формата, выглядит как [code:1kmgknpt]FORMAT:UTF8,UTF8:Строка[/code:1kmgknpt]При этом двойное перекодирование отменяется, но OpenSSL проверяет, что Строка действительно в UTF8 и если нет, то выпадает в ошибку. По этой же теме, сделал соединение целого файла конфигурации из частей, части могут быть как в UTF8, так и в 1251 кодировке. В перспективе хочу доделать HTML Application с динамическим подбором частей под генерацию конкретного сертификата и динамическим подбором параметров openssl для внутреннего УЦ.

В-четвертых, все же получилось закодировать расширение "Сведения о средстве ЭП и УЦ издателя" - для этого потребовалось использовать длинную форму расширения - когда вместо значения указывается SEQUENCE: и ссылка на секцию в файле конфигурации. При этом имена параметров в секции игнорируются, но должны быть различными. Тут заминка оказалась в возмутительном факте, что в стандартном файле конфигурации секции названы вроде [ v3_ca ] - с пробелом до и после названия, прекрасно находятся по указанию v3_ca, однако секцию для расширения нужно называть БЕЗ пробелов, в точности как указано после SEQUENCE: иначе не найдется.

В-пятых, добавил расширения по версии УЦ и хэшу прошлого сертификата. Итого: в корневом сертификате 9 расширений (по результатам сравнения корневых и кросс сертификатов составил список из 12 возможных: у меня отсутствуют ссылка на сертификат УЦ, ссылка на список отзыва и период действия закрытого ключа, так как они не имеют смысла для корневого УЦ). Пока разбирался, еще встретил про встраивание заявления УЦ о политике и встраивание логотипа. С Логотипом правда я пока сертификатов не видел, но интересно попробовать (это уже наверно на подчиненном УЦ).

Также на форме криптопро узнал, что они переписали gost_capi.dll в gostengy.dll (с поддержкой ГОСТ-2012), слепили свою версию OpenSSL 1.1.0 (отключили что еще не поддерживается криптопровайдером, включили TLS 1.2, со стандартным OpenSSL по-прежнему 1.0) и nginx для openssl 1.1.0 - все это предлагают взаимнонастроенное,  в одном архиве. Для работы еще и сам криптопро нужен.Пока не пробовал, но интригует, версию собственного УЦ с гост-2012 вероятно попробую сделать на их версии openssl. Там же они слепили версию Хрома 60 с поддержкой ГОСТ.
Поддержка длинных строк
 
Константу проверил A0000 в шестнадцатиричной записи, вроде бы все верно. Странно все это. Попробую освоить поиск сертификата по отпечатку. Для удобства наверно - получить блоб с отпечатком, преобразовать в base64, сохранить. Потом считать, преобразовать обратно и в поиск. Также нашел [URL=http://cpdn.cryptopro.ru/content/capilite/html/group___cert_func_1g60989a0e9d7e90b­3bbc4e2e5c70f9d1f.html]статью[/URL] про КриптоПро Capi Lite и там внезапно не поддерживается флаг поиска ИЛИ.
Кстати про отпечаток - у меня вот еще были сомнения какой криптопровайдер нужно указывать при открытии хранилища в CertOpenSystemStore (в пояснении к параметру указано, что он будет использован для вычисления хэша в хранилище), указал КриптоПро. Однако может надо NULL указывать и из-за этого какой-нибудь внутренний поиск по SHA1 хэшу от enhkey_usage не проходит. Сегодня пробую с NULL.

Первая математическая проверка значения самой простой подписи прошла успешно. Столкнулся с 2 моментами - 1) вместо CryptImportKey (выдало, что неверный блоб) пришлось использовать CryptImportPublicKeyInfo. 2) функция декодирования из base64 (стандартная) использовала неявно shortstring, поэтому длина входного текста была ограничена 255 байтами, хотя внутренне кодирование сделано через стримы. На декодирование хэша и подписи это не влияло, а вот сертификат в 3 Кб оказался испорчен (вернулось 189 байт). Опять же сделал переходник с композитной строки на стрим и обратно, для проверки сохранил в файл сертификат до и после. Тут выяснилось, что если из base64 удалить и символы 10 и символы 13, то открыть сертификат не удается, если оставить один из них либо оба - все нормально. Еще перепроверю с чем связано.

По составным частям пока при взятии тега по id один символ пропадает и хэш не сходится. Далее планирую поправить проверку так, чтобы после нее были выполнены приготовления для переподписания (либо замены либо добавления еще одной подписи).
Внесение информации по нежилым помещениям
 
[QUOTE]Sergey_P пишет:
могли ввести старый лицевой счет в ГИС и подключить его ...[/QUOTE]Что-то не знаю, есть ли такая возможность, может кто подсказать? Когда прошлый раз пытался подключить счет - по обычному мне показало ошибку, а ЕЛС до сих пор нет в квитанциях. Хотя вероятно, что дома тоже нет в ГИС, соответственно и ЛС ни старых ни единого. :D
Поддержка длинных строк
 
[QUOTE]Sergey Cheban пишет:
Насчёт unicode - вряд ли.[/QUOTE]И это странно, так как функция ищет в том числе и по именам субъекта или издателя, и они могут быть в utf-8 для отображения кириллицы.[QUOTE]Sergey Cheban пишет:
Про описание структуры - это какая-то паскалевская специфика, я её, увы, не знаю.[/QUOTE]Похоже что так, Паскалевская специфика, а именно "мутный" тип Pchar в который можно присвоить и строковую константу и адрес и нетипизированный указатель (аналог void*), но нельзя типизированный указатель (на какую либо структуру, даже на массив символов). Должен представлять как раз таки указатель на массив символов с нулем в конце. Все должно преобразовываться автоматически, но похоже автоматикой где-то лишний раз берется адрес.

По умолчанию LPSTR в описаниях преобразуется именно в него. Ок, переписал в явных указателях и типах предложенных в статье по ссылке, без изменения описания структуры. Сделал дополнительные функции-обертки, чтобы каждый раз не вспоминать как с ними извращаться, но.. в итоге, ничего не изменилось. Получаю enhkey_usage из cryptoapi и могу его вывести на экран, заношу свое значение и тоже вывожу на экран - все такое же. За исключением того, что для получения память выделяется одним куском (идет структура, указатель в ней указывает на память сразу за ней в которой массив указателей на строки, строки тут же сразу после массива), а в моем заполнении структура в одном куске памяти, массив в другом, строки в третьем. Не находит. Объединил структуру и массив в один кусок - не находит. Уже заполнил все назначения enhkey_usage, которые есть у этого сертификата - не находит. Поставил флаг ИЛИ - не находит. Кажется разбираться с этим - только время терять.

Остается пожалуй еще один вариант - что константа типа поиска перенесена неверно. Навскидку справочное значение не нашлось, в руководствах все по имени, как будет время - поищу значение константы в заголовочном файле для Си. Пока отложил, отрабатываю проверку подписи.
тарифы и нормативы
 
Странная ситуация. А общеобластные есть до 01.01.2018? тогда наверно по ним. Не 7 же лет область без нормативов сидела? По идее прокуратура должна была отменить/приостановить и исходное тоже либо если в законе указан предельный срок до которого могут действовать старые постановления ОМСУ, то отменить/приостановить исходное после этого срока.
тарифы и нормативы
 
[QUOTE]Шла_мимо пишет:
Подскажите - как быть в такой ситуации? Может  кого-то аналогичная ситуация в городе...[/QUOTE]Смущает фраза "при царе Горохе". Во-первых, нужно выяснить было ли отменено постановление о нормативах. Возможно его уже давно втихую отменили, а Вы и не знаете.

Если все же не отменено, то по идее это как раз компетенция Прокуратуры - в наш ОМСУ каждый месяц приходит из местной прокуратуры списочек какие законы приняты и какие муниципальные правовые акты в связи с этим надо изменить, заменить или отменить. В ответ в списочке указывается либо когда изменения приняты либо (если не успевают принять) когда изменения предполагается принять. Во втором случае они присылают еще раз - принят или нет в обещанные сроки.

Если у Вас аналогичная ситуация, то постановление могли отменить, отписаться Прокуратуре и забыть сообщить всем остальным.
Новые требования к протоколам общих собраний МКД в 2019 году
 
В техподдержке Вам посоветовали как если бы засчитали его и в за и в против. если вы не считали, то и вычитать не нужно. Однако, еще они советуют вычесть недействительные и из общей суммы, то есть в вашем примере они советуют заполнить: за 2000, против 500, воздержался 0, всего 2500 (3000 всего -500 недействительных).
Поддержка длинных строк
 
[QUOTE]Sergey Cheban пишет:
Но... А что Вы будете делать, когда у Вас заведутся несколько сертификатов с этим значением в enhanced key usage (из них парочка - устаревшие)? По-моему, правильнее по fingerprint (CERT_FIND_HASH) выбирать.[/QUOTE]Принципиально согласен, отпечаток лучше всего, но с другой стороны его и хранить/передавать очень неудобно. Еще чуть хуже - пара издатель+ серийный номер. Тут задумка была не загружать программу привязкой к сертификату (по крайней мере, пока тест). Сертификат с таким enhanced key usage один и другой не планируется пока. Согласен, что так небезопасно - либо должен явно настраиваться сертификат для автоподписания при смене либо явно подтверждаться пользователем каждый раз.

Случай с устаревшими наверно не принципиален - дальше планируется проверять не истек ли сертификат. Но не нашелся вообще ни один. Другой вопрос, что да, теоретически могут быть несколько действительных сертификатов с одним и тем же enhanced key usage. Даже если брать только enhanced key usage ЭП-ОВ (1.2.643.100.2.2, для смэв, на котором я тренируюсь), то теоретически у одной организации может быть несколько ИС, подключенных к СМЭВ, и для каждой из них нужен отдельный сертификат ЭП-ОВ. Обычно конечно разные ИС на разных серверах, но если вдруг на одном сервере сошлись, то это будет ужас их отличить.

Ситуацию усложняет и то, что ЭП-ОВ не включает персональных данных либо адреса почты и в данном случае CN = наименованию организации (к слову, с таким CN сертификатов с разной комбинацией enhanced key usage и ФИО уже 5 штук). По рекомендациям предусмотрено, что в качестве CN можно использовать наименование или мнемонику ИС, но: 1) УЦ даже не спросил нужно ли нам указывать определенное CN; 2) самый первый сертификат ИС нужно приложить к заявлению на регистрацию и получить в ответ мнемонику (то есть в нем невозможно указать мнемонику, так как она будет выдана позже). В итоге действительно кроме отпечатка либо издателя+номера не остается других способов идентифицировать нужный сертификат.[QUOTE]Sergey Cheban пишет:
RanGe of Pointers to String Zero-terminated.Вот пример на паскале: [URL=http://www.cryptopro.ru/forum2/default.aspx?g=posts&m=10354#post10354]http://www.cryptopro.ru/forum2/default. ... #post10354[/URL].[/QUOTE]Спасибо за ссылку, но этот пример скорее поможет при перечислении и проверке каждого перечисленного сертификата, чем при задании поиска. Начать можно с того, что у меня в модуле (как и в теме по ссылке) вообще не указано что это массив! Однако это не должно было повлиять на "массив" из одного элемента который в памяти расположен также как просто элемент.

Могу понять почему не указан массив - если установить массив более чем из одного элемента компилятор изменит размер структуры, а если объявить как массив из одного элемента (как обычно делается для массива неизвестной длины), то нужно отключать проверку индексов массива при работе со структурой (иначе вылетит исключение). Так что явно придется менять описание структуры.
Есть еще одна мысль, где искать ошибку - возможно в описании еще и перепутаны одноименные A и W функции и на самом деле надо передать Юникод строку (да еще с двойным нулем в качестве завершающего символа). Хотя как я понимаю должна бы возвратиться ошибка обращения к памяти в этом случае.[QUOTE]Sergey Cheban пишет:
Вроде, OpenSSL ни про какие хранилища сертификатов не знает. Ему нужен либо сам сертификат в виде блоба, либо, на худой конец, имя файла.[/QUOTE]Хранилище доверенных сертификатов по крайней мере у него точно есть, только на Windows оно обычно не работает, так как путь в большинстве сборок вкомпилирован в стиле Linux. В общем, об этом я и говорю, что при работе с OpenSSL еще и свое хранилище делать.[QUOTE]Sergey Cheban пишет:
В принципе можно и с криптоапи поступить так же, давать ему сертификат в файле, но это не очень хорошо: windows позволяет сохранить сертификат в хранилище без возможности экспорта, это снижает риск утечки приватного ключа.[/QUOTE]Как выяснилось, одно другому не мешает! Можно передавать сертификат в файле в cryptoapi и получать ссылку на ключ.

Дано: приватный сертификат установлен со ссылкой на закрытый ключ (тут ссылка имеется ввиду не адрес в памяти, а имя и параметры контейнера и криптопровайдера) и хранится в хранилище Windows (закрытый ключ тоже в хранилище либо на токене). Берем сертификат из файла или из памяти (без закрытого ключа, декодированный из base64, если в файде был кодированный), передаем в CertCreateCertificateContext  получаем pCertContext (сертификат в закодированном ASN.1 и раскодированном виде - раскодируются основные поля, не все), передаем pCertContext  в CryptAcquireCertificatePrivateKey и получаем hCryptProv (полноценный контекст криптопровайдера с ключевой парой, то есть в том числе со ссылкой на закрытый ключ! соответствующий переданному сертификату), который можем использовать для подписи. Для сопоставления есть разные параметры, наиболее удобный - по открытому ключу в сертификате в хранилище и в переданном pCertContext. Побочный положительный эффект - не нужно гадать AT_KEYEXCHANGE или AT_SIGNATURE в контейнере - определяется автоматически и возвращается. То есть даже если в контейнере 2 ключевых пары, то открытый ключ (или сертификат) идентифицирует пару однозначно, а просто имя контейнера - нет.
Если экспорт ограничен - хотя блоб закрытого ключа не получим, но в остальном все так же.
Поддержка длинных строк
 
За неделю с хвостиком есть подвижки: если кратко мини-менеджер немного усовершенствован и может восстанавливать часть данных, однако проверки по тексту еще не расставлены. Проверки в присваивании включены, но замечаний не показали.

Доработал связки по сертификатам, получилась первая рабочая версия (выдающая реальное значение подписи), перед возвращением данных производится проверка подписи - проверка проходит нормально. В процессе где-то пропала информация про сертификат (которая правильно выводилась с заглушкой значения подписи хэшем), но можно считать ма-а-а-аленькой победой.   qws  Для получения доступа к контейнеру соответствующему сертификату используется CryptAcquireCertificatePrivateKey - возвращает контекст криптопровайдера с контейнером и закрытым ключом. Тут плохая новость в том, хотя возвращает Истина (ошибок нет) и пригодный для работы контекст, но в GetLastError() появляется код ошибки 127 (не найден адрес процедуры) и как обычно он может всплыть только после нескольких операций и разрушить логику работы приложения.

Еще выяснился минус - функция преобразования в base64 из набора cryptoapi вставляет переводы строки (символы 13 и 10), хотя символа 13 вообще не должно быть в каноническом виде, да и обычно значение подписи пишется в одну строчку даже без  символа 10. Это не смертельно, так как значение подписи не попадает в "каноничные области" (те места, которые обязаны быть каноничными), но выглядит в итоге не очень хорошо, так что придется переводы строк убрать. Ранее это же было со значением хэша, там значение входило в "каноничную область", но перевод строки был только в конце и его пришлось отрезать. Теперь планирую найти где теряется сертификат и отработать проверку полученного подписанного xml, убирая по пути различные заглушки. Далее останется проверка каноникализации и тестирование на межведе.

Про каноникализацию нашел хорошую статью с примерами как и что делать вручную и под ее вдохновением набросал (но никак не тестировал еще) реализацию, за исключением 2 моментов - обработки атрибутов по умолчанию и замены символьных ссылок. С ними проблема в том, что они указываются в !DOCTYPE и могут быть не включены в документ, а указаны по внешней ссылке, то есть надо загружать документ откуда-то и его обрабатывать, а он может указывать на другой документ и т.д. Есть большие сомнения, что это когда-нибудь встретится в запросах между ИС, тем не менее без этого текст считается не каноничным. В общем, каноникализация оставлена "на сладкое".

Вчера весь день пытался заставить cryptoapi выдать подпись конкретным сертификатом. Идея была в использовании функции поиска сертификата CertFindCertificateInStore с определенным значением в расширенном использовании ключа. Вот только я видимо не понимаю как она работает, потому что она ничего не находит, хотя сертификат с указанным использованием есть и функцией перечисления всех сертификатов находится. В функцию поиска по расширенному использованию передается структура из количества строк и массива pchar значений (rgpszUsageIdentifier - в префиксах Си я не очень разбираюсь, первый раз такой rgpsz вижу, но комментарий стоит array of psz). Уже ее заполнял и как массив указателей на буферы и как указатель на массив указателей на буферы - результат один.

Еще посмотрю MSDN, возможно тут некая заморочка при переносе описания струтуры на Паскаль и придется менять описание. Хранилище используется "Личные" , и при перечислении и при поиске один и тот же дескриптор хранилища. Конечно можно и перечислять все потом проверять критерии, но если есть функция поиска по нужному параметру, зачем такое извращенство. Хотя наверняка при реализации этого будет быстрее понять, что нужно затолкать в структуру. Тут я понял почему некоторые программы идут с рекомендацией устанавливать только один сертификат: снес все остальные сертификаты и сделал через перечисление. Однако не теряю надежды добить поиск сертификата.

Соответственно придется хорошенько подумать относительно аналогичных функций для OpenSSL - поиска и перечисления сертификатов.
Проблема с загрузкой показаний ОДПУ
 
Совсем запутали с вольным употреблением "подогрева" и "горячей воды", а на скрине еще и холодная вода до кучи.
Смотрите если РСО - если предоставляете горячее водоснабжение (то есть потребитель считает по кубометрам и расходует горячую воду), то неважно из каких компонентов Вы их составили - есть определенный норматив сколько Гкал нужно затратить на подогрев. Умножаете норматив на стоимость 1 Гкал и складываете со стоимостью теплоносителя, получаете тариф. Все, внутренняя кухня что была холодная, ее нагрели на ГИС не отражается. Соответственно ПУ по тепловой энергии тоже по идее не отражается.
Если горячая вода не расходуется (в сферическом вакууме), а отдает тепловую энергию в квартирах и возвращается на подогрев, то как бы Вы его не переименовали - это именно отопление. Вот тут уже можно ПУ по тепловой энергии занести.
Если все же не РСО, а УК, то немного сложнее - с учетом кто исполнитель КУ, в чьей собственности бойлеры и т.д. Чтобы не повторятся во всех возможных сценариях - это уже обсуждалось в несколько непрофильном разделе и ни к чему не пришли, остались при своих мнениях, [URL=http://forum.burmistr.ru/viewtopic.php?f=147&t=5514]ссылка[/URL]. Там тоже везде писали, везде обращались, но... с точки зрения ГИС (и похоже Минстроя) это отопление, а никак не подогрев. И пока нормативка не изменится, ничего с этим не поделать.
И снова вопрос о регистрации в ГИС ЖКХ
 
Возможно несколько вариантов:
1) буквально несколько дней назад некоторые идентификаторы поменяли - проверьте по сообщениям в ГИС, нет ли идентификатора в списке;
2) данные объекта как-либо испорчены другими поставщиками информации - проверьте данные объекта;
3) объект выпал из ОЖФ, например ГЖИ засомневалась в лицензии - проверьте есть ли объект и в каком он состоянии.
Ну и вообще с ГИС ничему не удивишься.
Проблема с загрузкой показаний ОДПУ
 
Вопрос конечно интересный, но, кажется, у Вас что-то напутано с заполнением. Вам нужно четко определится, что вы предоставляете. Если это только подогрев, то вроде бы не нужно его делить на части, а если 2 пункта, то их нужно оба прицепить к договору. (Пусть меня поправят, у кого есть опыт по такому).
И снова вопрос о регистрации в ГИС ЖКХ
 
Не хочу обидеть, но о какой защите персональных данных Вы в принципе говорите. Ваши данные светятся везде - тот же председатель наверняка получает некий доход, который проходит через банк. А банки с готовностью сливают данные друг другу, через какое-нибудь бюро кредитных историй. А если есть доход, то и в налоговую капает информация. Налоговая немного сопротивляется, но тоже предоставит данные любому уполномоченному органу, если тот найдет ссылку на закон, по которому должен знать о доходах определенного гражданина. В больницу председатель ходит? В регистратуре хранится карточка. На поезде ездит? РЖД накапливает данные. Мобильником пользуется? Оператор накапливает данные. Паспорт у него есть? СНИЛС есть? Список можно продолжить. Так отчего ж внезапно фобия относительно сайта госуслуг?

Кроме того, хотя организациям действительно можно зарегистрировать другое уполномоченное лицо, НО! фактически все равно нужно регистрировать руководителя, потому что только руководитель сможет принять пользовательское соглашение от организации, заключать сделки по ГИС и  (он может назначить это другому лицу, но после того как  сам зарегистрируется). То есть он сначала должен сам зарегистрироваться.. причем по ЭЦП, а ФИО и ИНН должны быть указаны в ЕГРЮЛ, проставить права, а потом может не работать в ГИС. Весело, да? После этого, Вы говорите что организациям легче? Как бы не так.

Так что если не хотите регистрировать председателя - вот Вам другой совет: смените председателя на того, кто не боится. Тоже вполне себе решение.
Ошибки в ГИС (эмоции пост)
 
Спору нет, интерфейс мягко говоря "нуждается в доработке".[quote:1qrh6ohn]Мы видим на полэкрана точку-маркер, индекс, зелёненький логотип домика, кадастровый номер, количество этажей.... НАХРЕНА загромождать, когда для начала работы с домом нужен тупо адрес, в одну строчку?[/quote:1qrh6ohn]Согласен на 100500%. Даже если не обрезать информацию до адреса, все можно было разместить в одну строку - по крайней мере в закрытой часть что не для жителей, а жители пусть любуются на свой домик во весь экран. В принципе, вопрос легко решается заменой таблицы стилей - например, в старой опере можно было выбрать свою таблицу стилей, это позволяет убрать все ненужное с экрана, а нужное, наоборот, выделить. Однако, есть неплохой шанс, что и все эти сообщения и всплывающие диалоги убьются вместе с ненужным, так как таблица заменяется полностью и все что должно остаться нужно добавить в новую. Посмотрите что-то подобное о замене стилей в своем браузере. Если что, со стилями могу помочь.[quote:1qrh6ohn]А когда ты пытаешься что-то разместить, ты должен нажать "разместить", а потом ответить на вопрос "ты уверен?", а потом ещё и на окей.[/quote:1qrh6ohn]Это вы еще на госзакупках или в СУФД не работали. На госзакупках реально надо три раза подтвердить - 1) что действительно собираетесь разместить, 2) что информация будет проверена; 3) что по результатам проверки найдено 100500 нарушений (по мнению сайта, на самом деле все ерунда), Вы действительно согласны разместить с нарушениями.[quote:1qrh6ohn]Для размещения информации не хватает вопроса: А вы точно уверены???" и кодового слова про девичью фамилию кошки твоей бабушки.[/quote:1qrh6ohn]Или нечитаемую капчу.[quote:1qrh6ohn]Механизм загрузки файлов также интересен. Вместо выбрать-загрузить мы видим "добавить-выбрать-загрузить" (на этом этапе разработчик, по-моему, пропустил вопрос: "вы уверены, что хотите загрузить"?"
Дальше ты должен нажать сохранить и обязательно нажать ОК. Потому что просто "сохранить" - это ты как бы не уверен, но уж если нажал "ОК" - то всё, да, стопудово сохранить.[/quote:1qrh6ohn]Тут однозначно надо дорабатывать логику интерфейса и сокращать число кликов.[quote:1qrh6ohn]Каждый раз, каждый, после каждого чиха ты будешь улетать вверх. [/quote:1qrh6ohn]Это тоже косяк интерфейса - после обновления данных стоит перелистывание вверх. Изначально это предназначается для случая, когда в многостраничном списке меняется страница. Незаметно, когда все умещается на одном экране - поэтому на куче сайтов остается всегда, ну а тут когда маркеры на полэкрана, действительно выходит убожество. Тут тоже есть нюанс - при перелистывании страницы назад, по идее должно "улетать вниз", но про это тоже часто разработчики сайтов забывают. Технически возможно сделать страницу, которая будет пролистываться к тому месту с которым работаете, а там уже отображать ссылку "вверх" или "вниз".

Кроме подтверждений, насколько вижу все вышеперечисленное не затрагивает внутреннюю работу ГИС и можно сделать за половину человеко-дня. Ну ладно, пусть неделю, если у них замороченная система разработки. Поэтому сухой остаток (уже без эмоций) надо бы написать разработчикам - вдруг прислушаются
Шаблон ПД (платежных документов)
 
[QUOTE]BatalinVA пишет:
10/3*3 =3.3333*3=9.999 и совсем другой правильный результат 10*3/3=10 т.е. не 9,999, а 10..[/QUOTE]Естественно, умножение целых чисел нужно делать вперед, это даже не вопрос. Однако, к сожалению, не всё так просто. Достаточно много языков программирования в которых результат деления двух целых чисел должен быть вещественным (в большинстве - double), целочисленного просто не предусмотрено, даже если остаток целочисленного деления ноль. И, хоть вы и делите 30/3, а выйдет (не проверял, что-то вроде) 10,00000000000001 за счет ошибки вещественного представления числа.[QUOTE]BatalinVA пишет:
ненавижу  программы писаные не мной[/QUOTE]Частично соглашусь, я не люблю программы в исходники которых не могу заглянуть. Хотя не факт, что буду править или пересобирать.[QUOTE]BatalinVA пишет:
не уверен в его правильности и в том что стоит ли вообще подобный способ обсуждать[/QUOTE]Ничего не мешает завести тему про округления в разделе программного ПО, там всем миром и выявим сильные/слабые места способа. Если конечно захотите.[QUOTE]Форест пишет:
Да не отменят никогда загрузку данных через шаблоны.[/QUOTE]Я не утверждаю, что это будет ближайшее время. Просто в один прекрасный день, когда большинство перейдет на СОАП (это явно будет нескоро), могут не выложить новую версию шаблона. Да чего спорить - поживем, увидим.[QUOTE]Форест пишет:
писать различные прокладки на .NETе[/QUOTE]Это да, я тоже пишу без дотнета. Как допилю - поделюсь результатами, вдруг кому пригодится.
Поддержка длинных строк
 
За вчерашний день проверил остальные модули и оказалось еще интереснее: похоже секция initialization вызывается только в модулях напрямую указанных в основной программе. Причем порядок автоматически выстраивается, а если указанный модуль в программе не используется, то он может исключаться. То есть если модуль 1 использует модуле 2, а основная программа использует модуль 1, то сработает инициализация модуля 1, но не модуля 2. Определенная логика прослеживается. В этот раз у меня вышло что в основной программе указаны 2 модуля, а из них еще тянутся 7 штук. Переписал все кроме мини-менеджера на отдельные процедуры инициализации.

Загрузил эталонные примеры хэша в Base64 кодированном виде (для проверки нужен ли переворот хэша для данного криптопровайдера). Мини-менеджер все же определенно нужная вещь! В одном из вызовов перевода хэша в Base64 пропустил взятие адреса буфера и композитный тип перезаписался строкой-результатом. Данные испортились, в том числе указатель на буфер (но длина хэша мала, пострадали соседние переменных, но критического сбоя не произошло). И тут проявил себя мини-менеджер: 1) не дал освободить незарегистрированный адрес буфера (что привело бы к вылету) и вывел об этом сообщение, по которому я нашел ошибку; 2) когда программа закончилась, освободил все неосвобожденные буферы по своим данным. То есть несмотря на переполнение буфера и временную утечку памяти все закончилось хорошо.

Еще бы восстанавливать такие испорченные адреса буфера - вообще будет замечательно. Теоретически - надо еще фиксировать адреса самих записей и их флаги, но практически - все неявные присвоения пролетают стороной (неявные преобразования уже должны ловиться мини-менеджером, можно допилить). Некоторые мысли как это обойти есть: например, при обнулении композитного типа проверять "а был ли такой адрес переменной композитного типа" и вставить проверки переданных композитных строк (если обнуление не нужно) в каждой функции. За одно можно выводить сообщения о неявных присвоениях/преобразованиях. Минус - придется наверно написать вспомогательную программу просматривающую код и сообщающую куда вставить проверки.

С присвоениями, кстати, оказалось, что не только композитный тип, но и все структуры, содержащие его, нужно присваивать очень аккуратно - иначе в них будет совсем не то.
Шаблон ПД (платежных документов)
 
[QUOTE]BatalinVA пишет:
так как числа достаточно случайны, то появление четных и нечетных цифр перед пятеркой равновероятно[/QUOTE]Спасибо, что напомнили. Не спорю, что есть такое округление, но нужно понимать область применимости каждого алгоритма. Вот из-за такого округления и получается в 1С расхождение на 2 копейки в зарплате или сумме налога, отнимающее немало нервов. Крепко сомневаюсь в его целесообразности в случае ПД ГИС, вот несколько соображений:
1) Ровно половина _копейки_ - сомневаюсь, что это встречается очень часто. С учетом индексации на разное количество процентов, вероятность еще больше падает. От остального "задирания" суммы должно спасать правило, запрещающее _дважды и более раз_ округлять одно и то же число - имеется в виду до разного разряда - можно округлять только ранее не округленное "исходное" число. Иначе арифметически округлив 349 до десятков получите 350, округлив 350 до сотен = 400, а напрямую округлив 349 до сотен = 300. Бухгалтерское попадает на те же грабли, 349 до десятков - 350, 350 до сотен - 400, 349 до сотен - 300, то есть недопустимость повторного округления справедлива и для него. Хотя в половине случае погрешность поглощается, этого недостаточно для отмены правила.
2) Ага, очень "равновероятен" оклад одного человека в разные месяцы или его площадь квартиры в разные месяцы. Не спорю, что подход с бухгалтерским округлением позволяет свести _общую_ сумму по зарплате месяца (по временному разрезу), перераспределив доли копейки между строками. Однако это, например, проваливается, если в ведомости только 1 человек (аванс попросил 1 человек). В разрезе услуг в квитанции - тоже нецелесообразно, так как разные услуги могут идти к разным организациям, поэтому "перераспределять доли копейки" между ними неверно.
Если же принимаете все платежи к себе, то есть перераспределяете каждую услугу по отдельному списку потребителей и округляете в нем, рассчитываетесь по общей сумме с РСО. Потом _бухгалтерски округленные_ суммы из разных списков вставляете в ПД одного человека, то в подходе есть смысл. Естественно "равновероятности" никакой нет, не нужно об этом говорить, но потребители обычно закрывают глаза на доли копейки, если видят одну сумму каждый месяц.
3) В разрезе одного человека/услуги есть и другой подход: суммировать в начисленное в этом месяце разницу прошлого месяца между начисленным (без округления) и округленным к оплате и не допускать разницу в 1 копейку и более. При арифметическом округлении или округлении отбрасыванием дробной части копейки, это как раз должно давать эффект округления то вверх, то вниз, причем не с 1/2, а с реальной вероятностью равной дробной части копейки (начисленной за месяц). Хотя при таком подходе вообще не важно, какое округление было, сойдет даже не взятие определенной цифры из числа, а подбрасывание монетки - в следующем периоде целая копейка все равно выровняется. Вопрос только в том, кто кому будет должен по итогам месяца.[QUOTE]Сергей_ пишет:
Странно, что имея интерфейс для ввода информации ручным способом в ГИС нужны какие-то еще эксельки для того же самого ручного ввода.[/QUOTE]Увы, разработчики ГИС воспринимают только SOAP в качестве автоматического ввода. Эксель они ввели по многочисленным просьбам и мечтают когда-либо отменить. Хотя пока неизвестно когда, но если большинство перейдет на SOAP, то срок замаячит на горизонте. Для автоматизации среднему программисту было бы более удобно загружать неподписанный xml или csv, чем SOAP. Обсуждение - в разделе программного обеспечения, [URL=http://forum.burmistr.ru/viewtopic.php?f=147&t=5481]тут[/URL] и [URL=http://forum.burmistr.ru/viewtopic.php?f=147&t=5540]тут[/URL]. Однако подвижек к этим форматам нет. "Не по силам SOAP" воспринимается разработчиками только как временная мера и когда-нибудь придется осваивать SOAP. Я уже потихоньку начал, но с другой ГИС.
Начал с другой - как я понял по ответам экспертов (пусть меня поправят, если не так), ГИС ЖКХ вроде как не дает править данные, внесенные по SOAP внесением правок из личного кабинета - кнопки становятся неактивны (хотя вносить новые данные можно). Вообще, это логично (иначе есть большой шанс, что очередной SOAP запрос перезапишет внесенное вручную - данные нужно исправить в ИС, работающей с SOAP), но крайне неудобно (нельзя ввести некий переходный период: разрешили вводить определенные данные через SOAP - всё, пока разрешение действует, личный кабинет бесполезен по данным типам данных). Определенную гибкость дает выбор какие данные разрешено вносить ИС (то есть можно сначала разрешить один тип данных, через какое-то время разрешить другой b т.д.), но и только. Следовательно, после перехода на SOAP, Эксель тоже отпадет.
Поэтому я пока собираюсь отработать технологию на ГИС ГМП, потом внести ряд правок под ГИС ЖКХ. [URL=http://forum.burmistr.ru/viewtopic.php?f=147&t=5835]Список "достижений"[/URL]
Шаблон ПД (платежных документов)
 
[quote:1svz4tqw]Правда, может получиться строка с одним нулем после точки (если R2 равно 0, то inttostr вернет один ноль): '17.0'. Дорисовывать ноль в разряды сотых рубля? Выводить в этом случае '17'?[/quote:1svz4tqw]Можно конечно и так, но и правда как-то сложно - анализировать, увеличивать другую переменную, тратить 4 байта на число до сотни. Именно поэтому проще умножить на 100 (знаю, умножать не айс, но что поделать) и сделать округление в один integer (longint, int64 нужное подчеркнуть - целое знаковое, до 21 миллиона рублей будет достаточно длины 4 байта). Тогда после преобразования в строку целого рубля получим ровно два нуля в конце. От умножения на 100 наверно даже можно уйти если преобразовывать на ассемблере на уровне битов, с учетом распределения битов мантиссы и порядка в double.[quote:1svz4tqw]Только почему мы должны заниматься такими извращениями???[/quote:1svz4tqw]С этим согласен. Вот только если мы в итоге округлим в одну сторону, а гис в другую - будет "неудобняк". Значит нужно договориться о форматах. И тут можно отметить, что разработчики ГИС не раз подчеркивали, что шаблоны Экселя для ручного заполнения, а при ручном заполнении проблемы не возникает - значит ее и не исправят, поэтому автоматизация сопряжена с такими танцами с бубном.
Шаблон ПД (платежных документов)
 
[QUOTE]Сергей_ пишет:
Я попробовал без переименования на файле нажать на этом файле правую кнопку мыши и в контекстном меню выбрать 7-Zip->Открыть архив.[/QUOTE]Да, есть такое. 7-zip добавляет меню открытия для любых расширений, как по мне это удобно для одной программы и не очень удобно в целом. В том плане, что таких же "умных" программ накапливается просто вагон и маленькая тележка - и меню постепенно превращается в "кабину современного авиалайнера" - куча неиспользуемых строк.[QUOTE]Сергей_ пишет:
один финт - запись макросов в Excel.[/QUOTE]Сами в начале пробовали? В записанных макросах Эксель и Ворд все делают через объект Selection, в который можно затолкать что угодно и поэтому новичкам ни разу не понятно. В обычных же "рабочих" макросах крайне редко использую Selection. Поэтому для изучения объектной модели с нуля это категорически не подходит. Максимум уточнить новые для себя детали. Про документацию можно сказать то же - просто бесит когда в справке Майкрософт пишет, что метод или свойство (тот же Cells(x,y)) возвращает Object а какого он типа этот объект? им лениво было уточнить что это Range? Ну я конечно понимаю, что теоретически наверно может быть что-то другое, но в 99,9% это Range. Поэтому изначально только копирование чужого работающего кода, а уж потом запись макросов.[QUOTE]Programmer пишет:
Округление может не всегда помочь.[/QUOTE]Конечно, double и float округлять несколько бесполезно из-за двоичного представления дробной части, более перспективно умножение на 100, округление/отбрасывание дробной части (перевод в целое число, при этом и занимаемый размер уменьшится с 8 байт до 4 байт и "помехи" двоичного представления исчезнут) и перевод [B][U]целого числа[/U][/B] в строку. А там уже строкой можно рулить как угодно - например, вставить точку отступив справа 2 символа.
[QUOTE]Programmer пишет:
Тогда часть строки '1234.5600012' скопируется с первого символа по седьмой (точка в пятой позиции). В результате c1 будет равна: '1234,56', ее то и выводим. Должно помочь, надеюсь.[/QUOTE]Замечательно, только это может быть не '1234.5600012', а '1234.559998' и тогда программа исказит копейки.
Поддержка длинных строк
 
Спасибо. Действительно менеджер паскаля использует что-то подобное, хотя в подробности не вдавался: в начале блока точно пишется скрытая служебная структура, в том числе в ней указан размер блока, что позволяет освобождать память не указывая размер - менеджер сам его считает. И между блоками расстояние достаточное, скорее всего в конце тоже есть служебные маркеры. heaptrc вообще прямо в яблочко, как раз на FreePascal компилирую. Раньше о нем читал, что утечки памяти выявлять удобно, а тут не вспомнил.

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

Однако, похоже разгадка оказалась вообще совсем в другом (хотя обломы с памятью не исключаю до конца) - компилятор Фрипаскаля понимает разные "диалекты" Паскаля и некоторые управляющие конструкции не работают в одних, но работают в других. Обычно диалект распространяется только на один модуль и смешивание неудобств не доставляет. В частности, в диалекте Дельфи работает обработка исключений try.. except..end; try..finally..end; но не работает объявление операторов. На диалекте Фрипаскаля наоборот. Поэтому модуль длинных строк на одном диалекте, а httpclient на другом. О несоответствии этих конструкций текущему диалекту модуля компилятор должным образом ругается.

Однако, также есть отличия в синтаксисе инициализации/выгрузки модуля от классического BEGIN END (аналог main в си) и специальных ExitProc (каждый модуль сохраняет указатель ExitProc при загрузке, потом восстанавливает при выгрузке и если не NULL вызывает функцию по этому адресу - выходит нечто похожее на стек модулей). Уже давненько привык к варианту секций initialization .. finalization .. end. В этот раз тоже было так записано, модуль работал, когда более-менее отладил его - перешел к следующему, который его использует. И где-то в этот момент видимо изменился диалект, секции initialization и finalization просто стали игнорироваться без каких-либо сообщений об ошибке.
[SIZE=85px][COLOR=greenpt]Отправлено спустя 27 минуты 31 секунды:[/COLOR][/SIZE]
Фактически, уже чудо что хотя бы что-то работало на непроинициализированном модуле. После очередной отладки обратил внимание, что помимо ошибок доступа еще не читается кэш ответов портала (при чудесах с памятью не удивительно) и вываливаются обращения к EnterCriticalSection (пока отлаживал просто их комментировал - в тестовой программе все равно только одна thread). А InitializeCriticalSection и чтение файла как раз были в inialization. Сложил 2 и 2, вставил туда еще вывод строки на консоль - не выводит, перенес код инициализации и выгрузки в отдельные процедуры, вручную их вызвал - заработало, хотя наверно теперь надо все модули проверить. И уже не знаю на кого злиться - на авторов компилятора, который не предупреждает, что часть кода просто игнорируется или на себя что не использую классику, которая точно реализована в компиляторе.
#
[quote:gbou89ro]Плюс большинство из них - по нанимателям муниципальных квартир, т.е. можно скопом получить идентификационные данные через муниципалитет.[/quote:gbou89ro]Опять же если данные есть у муниципалитета. Если оформляли в недавние годы, то наверно есть свежие данные, а если давно, то лучше собирать (даже если есть, например, паспорт, то его могли заменить - есть случаи когда женщины меняли паспорт 5-6 раз за 3 года).

Правда, ОМСУ может запросить снилс из ПФР [URL=http://smev.gosuslugi.ru/portal/services.jsp#!/F/SPFRzaprossnils/3.00/p00smev/SID0003619]через сервис СМЭВ[/URL], но есть небольшая загвоздка - помимо ФИО нужны пол (для "неславянских" ФИО разобрать бывает не просто) и полная дата рождения (а раньше в документах часто оставляли только год), для точности запроса нужны данные разворота паспорта. Итого: какие-то данные получить конечно можно, но свести к нулю количество отсутствующих/неверных сведений только по документам из архива в общем случае не выйдет. Соответственно, лучше сохранить документ который получили откуда-то на случай вопросов в достоверности данных.
Если бы не было вопроса о достоверности, можно было забить значения снилс, предназначенные на случай, когда у человека нет снилс (примерный вид 000-000-001 ХХ, первые нули, потом 001, 002 и т.д., в конце контрольные цифры) или тот самый фиктивный паспорт "12 34 567890".
#
[quote:jek7lkor]предпочитаю ХП и их дочку.[/quote:jek7lkor]Согласен. Однако в последнее время ХП стали делать технику, которая заточена на Windows 10 (у нового мфу Семерка принтер видит, а сканер нет) и нежная - если положить черновик, то наматывается всякая грязь на детали и появляется полоса. Зато предыдущая линейки с сетевым интерфейсом классная - можно по сети сканировать (без податчика конечно смысла немного, но пользователи, желающие сканировать без переключения мфу на их комп наконец-то замолчали).
Сканер с податчиком и двусторонним сканированием это кайф - 1 такой в фин.отдел купили, подцепили к сети. Теперь приходят сотрудники бросают пачку документов, аппарат сам пдфит и закидывает в сетевую папку. Хотя соглашусь, что сканер отдельно + принтер отдельно лучше МФУ - уже несколько раз мфушки отказывались печатать только потому что стекло сканера покрылось пылью изнутри.
Еще у нас куча canon стоит, потому что их картриджи с ХП совместимы. От самсунгов (а также  брозеров, ксероксов) планомерно отказываемся - дорого в обслуживании.
Kyocera кстати пара штук есть и впечатление пока очень благоприятное, особенно если подцепить напрямую к сети - чего там только сетевого не поддерживается. Правда отключить лишнее вроде SNMP не вышло, попутно отключилась и стандартная печать по TCP/IP, но когда-нибудь и до этого руки дойдут.
#
[QUOTE]skad888 пишет:
А по теме, Вам дешевле 3 девушек нанять и посадить за компы, чтобы руками в шаблоны набивали.[/QUOTE]Похоже РКЦ именно это и сделает + накрутка.
#
Тут хотелось бы уточнить эти 2 прибора связаны или нет? Если не связаны - например, один считает воду на кухне, другой в санузле, то все как ответили выше, можно несколько. Хотя не принципиально присвоить кухне, к примеру, номер помещения 1, санузлу - 2.
А вот если связаны - например, на входе холодной воды в квартиру и на выходе на приусадебный участок (за холодную начисляется по ПУ на входе, за канализацию - только разница между ПУ), то нужно еще указывать их положение.
#
Где-то на форуме кажется было пояснение, что имеются в виду начальное значение на время когда ПУ внесен в ГИС, а не на момент ввода ПУ в эксплуатацию. Что было до внесения информации в ГИС, ГИС не волнует (но возможно взволнует проверяющих почему долго не вносили), потому и ввода информации за прошлые периоды нет. Например, собрали информацию на 01.06.2017, в июне внесли ПУ, пишите "последнее известное" на 01.06.2017 в поле начальное в ГИС, потом ежемесячно вносите свежие данные.
В идеале предполагается (на будущее), как ввели в эксплуатацию - как можно скорее в вносите, чтобы не было разрыва в показаниях.
#
Итак, разобрался с файлом в котором все объявления пространств идут на пространство по умолчанию. 3 подписи проверяются (были небольшие проблемы с определением какой сертификат к какой подписи - второй и третий сертификат не добавлялись). Казалось бы отлично, но проверка на наличие четвертой вываливается с ошибкой "Недостаточно памяти". В системе-то память есть, но видимо heap закончился.

Глянул сколько памяти и остался в недоумении - после третьей подписи Виндоуз показывает порядка 648 Мб (из них 112 Мб Working Set (в оперативке), остальное в подкачке), мини-менеджер памяти по суммированию выделения и освобождения - 612 Мб (разница в 30 с небольшим Мб вполне может быть на статические переменные и выдедение на иной памяти кроме компзитных строк), сумма размеров по зафиксированным в мини-менеджере адресам - 43 Мб. Как я понимаю, с такими симптомами... утечка в самом мини-менеджере, буду искать. Вчера вроде бы разобрался с неявными присвоениями, но особо ситуация не изменилась.
#
Чтобы проверить на чем запинается проверка ЭП (там тоже такие умники от безопасности, которые не уточняют какая часть подписи неверна) и каноникализацию позаимствовал ответы, пришедшие по запросам через СМЭВ от федеральных сервисов (заведомо правильные). Отправил их на проверку своей каноникализацией. Как оказалось - в ответах как будто специально сделано неканоничное содержимое (нужно добавлять из контекста предков недостающие объявления пространств имен, в основном soap, wsu, ds, также поднимать или опускать объявления на 1 уровень). А еще сортировать пространства имен нужно все же по имени, а не по адресу (вот и несоответствие стандарту).

С ответом Росреестра трудность возникла с тем, что данные ответа от них в виде base64 кодированного блоба между тегами - естественно, 255 символов shortstring не хватило на такой "текстовый узел", пришлось ставить композитную строку. Налоговая порадовала кириллическими тегами, кириллическими атрибутами и кириллическими значениями, пришлось расширить список допустимых символов. Конечно, надо просто разобраться какие символы еще допустимы по стандарту (предположительно в кавычках допустимо все кроме кавычек). ПФР - просто вынос мозга: все объявления пространств идут на пространство по умолчанию (тут несколько не осилил - сложно отличить 2 пространства у которых имя из пустой строки, но разные адреса) и все по правилам: аж три ЭП. Проверка SignatureValue ответа ПФР не проходила, если убрать совсем символы с кодом 10 из SignedInfo. Поэтому все же пришлось их оставить (это по стандарту, за исключением возможного поведения XPath о котором писал вчера). Сочетания символов 13+10,10+13,13 заменяются на 10, с этим проблем не возникло.

В результате улучшений, буквально только что наконец-то получил сообщение, что ЭП-ОВ корректна на странице проверки подписи XML техпортала СМЭВ. И догадайтесь, куда закралась ошибка, после исправления которой свершилось чудо? Вместо Algorithm было написано Algorihtm. /рукалицо
Обнаружилось после введения проверки на алгоритмы (вообще с прицелом на гост-2012, но пока без него) - с проверочных ответов не было ошибки, а со своего запроса алгоритм не выбрался, пригляделся, а там такое.
#
Я бы где "неоднократно" еще и перечислил номера.. хотя бы один - того обращение, что при ошибке не формируется результат и которое они якобы передали экспертам или обещали исправить в какой-то версии.
#
Похоже что-то неправильно с этими счетами.. проверьте и исправьте даты сдачи показаний либо подождите 15 сентября. Во многих случаях гисовское истек означает "еще не наступил". Также, 20.08 и 20.09 - определенно есть разница.
#
Разбирался выходные с переводами строк: все же, как и предполагалось можно без опасений удалить переводы строк из base64 кодированной подписи или сертификата.
Глюк с порчей сертификата при удалении символов и с кодом 10 и с кодом 13 был из-за другой редкой ситуации - при склейке композитной строки, если требуемая длина данных результата была в точности равна длине выделенного буфера, то проверка на выделение дополнительной памяти не срабатывала. А вот при копировании данных в буфер там резервировалось место на терминирующий символ с кодом 0. Таким образом, 1 символ терялся и портил сертификат. Добавил в проверку буфера учет терминирующего символа и сертификат теперь не портится, попутно выводится сообщение если при склейке сумма длин частей не равна длине результата.
Также немного прояснилось, почему кто-то говорит что только символ 13 запрещен, а кто-то советует убирать символ 10 тоже. Соль в том, что XPath при выборке определенных тегов (для фрагмента) может выбрать только теги, но не выбрать переводы строк между тегами (равно как и прочие "текстовые ноды", а в каноническом представлении внутри самих тегах тоже НЕТ никаких переводов строк). В итоге, когда результат XPath проходит каноникализацию переводов строк вообще не остается и весь текст для хэша/подписи представляет собой одну строку. Получается в каноническом фрагменте документа переводов строки нет, но в канонической форме целого документа символы 10 могут использоваться как переводы строк. Во как.

Следующее разбирательство - насчет неразрывного пробела. Так как канонический вид подразумевает приведение к UTF-8, то явно речь не о символе с кодом 160 (замена символа 160 на пробел ломает кодировку UTF-8), видимо придется смотреть стандарт для уточнения.

Вник в каноникализацию еще глубже, оказалось у моей реализации есть определенные проблемы с ancestor context (контекст предков). Если точнее: с наследованием пространств имен и атрибутов которые были объявлены ДО выбранного в каконикализацию фрагмента. Сами теги погоды не делают, а вот пространства имен и атрибуты (да, я удивился, что атрибуты специального пространства xml: также наследуются) наследуются фрагментом. Например, попробовал получить каконический вид целого тега ds:Signature со ссылкой на сертификат и потребовалось пространство wsse для wsse:Reference. Вручную-то конечно добавил, теперь смотрю как автоматизировать.

Основная проблема, конечно, в последовательности формирования документа - сначала формирую подписываемую часть, потом всю "обертку", то есть на момент подписания контекста предков вообще еще нет. Видимо придется делать некую заготовку обертки и ее передать как контекст. Но это тоже как-то извращенно: ведь для каждого фрагмента приводимого к каноническому нужен свой контекст. Жесть.

[SIZE=85px][COLOR=greenpt]Отправлено спустя 16 минуты 29 секунды:[/COLOR][/SIZE]
С Openssl сделал для доменного УЦ на алгоритме shaRSA подчиненный УЦ и из последнего выпустил сертификат сервера. По поводу указания инн и огрн как NumericString  ничего не нашел - вопросы есть, ответов нет. Однако в одном месте высказали предположение что формат никак не указывается, дескать надо вкомпилить в OpenSSL. Скорее всего, способ все же есть, потому что все равно все строки проходят через кодирование ASN1 и формат должен определяться где-то там, но это опять же надо долго разбираться в исходниках OpenSSL.
#
За неделю: проверил подписанный файл на техническом портале СМЭВ - там меня обрадовали, что документ соответствует методическим рекомендациям 2.5.5, 2.5.6 и 2.6.0 (на 2.4.x не соответствует), но ЭП органа власти неверна. Подключил самописный модуль каноникализации, увидел, что действительно, был неканоничный вид. Однако и на такой все равно говорит неверная ЭП. Вот такая вот зараза.

Указание NULL (0 с учетом как перенесено на Паскаль) вместо провайдера при открытии хранилища - результат тот же, не находится.

Для разнообразия вчера разбирался с конфигурацией OpenSSL для внутреннего УЦ. Теперь сертификат УЦ гораздо больше похож на корневые сертификаты аккредитованных УЦ. Во-первых, добавил огрн и инн организации - это оказалось довольно просто (пока есть небольшое различие: по приказу ФСБ они NumericString, а у меня вышло UTF8String). Во-вторых, CN написал на русском (этого пришлось увеличить ограничение на длину, так как в UTF8 длина 34 символов вышла около 70 байт, а ограничение по RFC в 64 символа (и OpenSSL его применяет к байтам вместо символов).

В-третьих, разобрался с UTF8 и ASN1 кодированием. Раньше я говорил, что если файл конфигурации в UTF8, то ASN1 кодирование это игнорирует и кодирует второй раз (при этом кодирует как будто символы были в расширенной латинице, то есть и без изначального UTF8 текст с кириллицей портится). Сейчас я разобрался - если текст уже в UTF8, то нужно добавить модификатор формата, выглядит как [code:1kmgknpt]FORMAT:UTF8,UTF8:Строка[/code:1kmgknpt]При этом двойное перекодирование отменяется, но OpenSSL проверяет, что Строка действительно в UTF8 и если нет, то выпадает в ошибку. По этой же теме, сделал соединение целого файла конфигурации из частей, части могут быть как в UTF8, так и в 1251 кодировке. В перспективе хочу доделать HTML Application с динамическим подбором частей под генерацию конкретного сертификата и динамическим подбором параметров openssl для внутреннего УЦ.

В-четвертых, все же получилось закодировать расширение "Сведения о средстве ЭП и УЦ издателя" - для этого потребовалось использовать длинную форму расширения - когда вместо значения указывается SEQUENCE: и ссылка на секцию в файле конфигурации. При этом имена параметров в секции игнорируются, но должны быть различными. Тут заминка оказалась в возмутительном факте, что в стандартном файле конфигурации секции названы вроде [ v3_ca ] - с пробелом до и после названия, прекрасно находятся по указанию v3_ca, однако секцию для расширения нужно называть БЕЗ пробелов, в точности как указано после SEQUENCE: иначе не найдется.

В-пятых, добавил расширения по версии УЦ и хэшу прошлого сертификата. Итого: в корневом сертификате 9 расширений (по результатам сравнения корневых и кросс сертификатов составил список из 12 возможных: у меня отсутствуют ссылка на сертификат УЦ, ссылка на список отзыва и период действия закрытого ключа, так как они не имеют смысла для корневого УЦ). Пока разбирался, еще встретил про встраивание заявления УЦ о политике и встраивание логотипа. С Логотипом правда я пока сертификатов не видел, но интересно попробовать (это уже наверно на подчиненном УЦ).

Также на форме криптопро узнал, что они переписали gost_capi.dll в gostengy.dll (с поддержкой ГОСТ-2012), слепили свою версию OpenSSL 1.1.0 (отключили что еще не поддерживается криптопровайдером, включили TLS 1.2, со стандартным OpenSSL по-прежнему 1.0) и nginx для openssl 1.1.0 - все это предлагают взаимнонастроенное,  в одном архиве. Для работы еще и сам криптопро нужен.Пока не пробовал, но интригует, версию собственного УЦ с гост-2012 вероятно попробую сделать на их версии openssl. Там же они слепили версию Хрома 60 с поддержкой ГОСТ.
#
Константу проверил A0000 в шестнадцатиричной записи, вроде бы все верно. Странно все это. Попробую освоить поиск сертификата по отпечатку. Для удобства наверно - получить блоб с отпечатком, преобразовать в base64, сохранить. Потом считать, преобразовать обратно и в поиск. Также нашел [URL=http://cpdn.cryptopro.ru/content/capilite/html/group___cert_func_1g60989a0e9d7e90b­3bbc4e2e5c70f9d1f.html]статью[/URL] про КриптоПро Capi Lite и там внезапно не поддерживается флаг поиска ИЛИ.
Кстати про отпечаток - у меня вот еще были сомнения какой криптопровайдер нужно указывать при открытии хранилища в CertOpenSystemStore (в пояснении к параметру указано, что он будет использован для вычисления хэша в хранилище), указал КриптоПро. Однако может надо NULL указывать и из-за этого какой-нибудь внутренний поиск по SHA1 хэшу от enhkey_usage не проходит. Сегодня пробую с NULL.

Первая математическая проверка значения самой простой подписи прошла успешно. Столкнулся с 2 моментами - 1) вместо CryptImportKey (выдало, что неверный блоб) пришлось использовать CryptImportPublicKeyInfo. 2) функция декодирования из base64 (стандартная) использовала неявно shortstring, поэтому длина входного текста была ограничена 255 байтами, хотя внутренне кодирование сделано через стримы. На декодирование хэша и подписи это не влияло, а вот сертификат в 3 Кб оказался испорчен (вернулось 189 байт). Опять же сделал переходник с композитной строки на стрим и обратно, для проверки сохранил в файл сертификат до и после. Тут выяснилось, что если из base64 удалить и символы 10 и символы 13, то открыть сертификат не удается, если оставить один из них либо оба - все нормально. Еще перепроверю с чем связано.

По составным частям пока при взятии тега по id один символ пропадает и хэш не сходится. Далее планирую поправить проверку так, чтобы после нее были выполнены приготовления для переподписания (либо замены либо добавления еще одной подписи).
#
[QUOTE]Sergey_P пишет:
могли ввести старый лицевой счет в ГИС и подключить его ...[/QUOTE]Что-то не знаю, есть ли такая возможность, может кто подсказать? Когда прошлый раз пытался подключить счет - по обычному мне показало ошибку, а ЕЛС до сих пор нет в квитанциях. Хотя вероятно, что дома тоже нет в ГИС, соответственно и ЛС ни старых ни единого. :D
#
[QUOTE]Sergey Cheban пишет:
Насчёт unicode - вряд ли.[/QUOTE]И это странно, так как функция ищет в том числе и по именам субъекта или издателя, и они могут быть в utf-8 для отображения кириллицы.[QUOTE]Sergey Cheban пишет:
Про описание структуры - это какая-то паскалевская специфика, я её, увы, не знаю.[/QUOTE]Похоже что так, Паскалевская специфика, а именно "мутный" тип Pchar в который можно присвоить и строковую константу и адрес и нетипизированный указатель (аналог void*), но нельзя типизированный указатель (на какую либо структуру, даже на массив символов). Должен представлять как раз таки указатель на массив символов с нулем в конце. Все должно преобразовываться автоматически, но похоже автоматикой где-то лишний раз берется адрес.

По умолчанию LPSTR в описаниях преобразуется именно в него. Ок, переписал в явных указателях и типах предложенных в статье по ссылке, без изменения описания структуры. Сделал дополнительные функции-обертки, чтобы каждый раз не вспоминать как с ними извращаться, но.. в итоге, ничего не изменилось. Получаю enhkey_usage из cryptoapi и могу его вывести на экран, заношу свое значение и тоже вывожу на экран - все такое же. За исключением того, что для получения память выделяется одним куском (идет структура, указатель в ней указывает на память сразу за ней в которой массив указателей на строки, строки тут же сразу после массива), а в моем заполнении структура в одном куске памяти, массив в другом, строки в третьем. Не находит. Объединил структуру и массив в один кусок - не находит. Уже заполнил все назначения enhkey_usage, которые есть у этого сертификата - не находит. Поставил флаг ИЛИ - не находит. Кажется разбираться с этим - только время терять.

Остается пожалуй еще один вариант - что константа типа поиска перенесена неверно. Навскидку справочное значение не нашлось, в руководствах все по имени, как будет время - поищу значение константы в заголовочном файле для Си. Пока отложил, отрабатываю проверку подписи.
#
Странная ситуация. А общеобластные есть до 01.01.2018? тогда наверно по ним. Не 7 же лет область без нормативов сидела? По идее прокуратура должна была отменить/приостановить и исходное тоже либо если в законе указан предельный срок до которого могут действовать старые постановления ОМСУ, то отменить/приостановить исходное после этого срока.
#
[QUOTE]Шла_мимо пишет:
Подскажите - как быть в такой ситуации? Может  кого-то аналогичная ситуация в городе...[/QUOTE]Смущает фраза "при царе Горохе". Во-первых, нужно выяснить было ли отменено постановление о нормативах. Возможно его уже давно втихую отменили, а Вы и не знаете.

Если все же не отменено, то по идее это как раз компетенция Прокуратуры - в наш ОМСУ каждый месяц приходит из местной прокуратуры списочек какие законы приняты и какие муниципальные правовые акты в связи с этим надо изменить, заменить или отменить. В ответ в списочке указывается либо когда изменения приняты либо (если не успевают принять) когда изменения предполагается принять. Во втором случае они присылают еще раз - принят или нет в обещанные сроки.

Если у Вас аналогичная ситуация, то постановление могли отменить, отписаться Прокуратуре и забыть сообщить всем остальным.
#
В техподдержке Вам посоветовали как если бы засчитали его и в за и в против. если вы не считали, то и вычитать не нужно. Однако, еще они советуют вычесть недействительные и из общей суммы, то есть в вашем примере они советуют заполнить: за 2000, против 500, воздержался 0, всего 2500 (3000 всего -500 недействительных).
#
[QUOTE]Sergey Cheban пишет:
Но... А что Вы будете делать, когда у Вас заведутся несколько сертификатов с этим значением в enhanced key usage (из них парочка - устаревшие)? По-моему, правильнее по fingerprint (CERT_FIND_HASH) выбирать.[/QUOTE]Принципиально согласен, отпечаток лучше всего, но с другой стороны его и хранить/передавать очень неудобно. Еще чуть хуже - пара издатель+ серийный номер. Тут задумка была не загружать программу привязкой к сертификату (по крайней мере, пока тест). Сертификат с таким enhanced key usage один и другой не планируется пока. Согласен, что так небезопасно - либо должен явно настраиваться сертификат для автоподписания при смене либо явно подтверждаться пользователем каждый раз.

Случай с устаревшими наверно не принципиален - дальше планируется проверять не истек ли сертификат. Но не нашелся вообще ни один. Другой вопрос, что да, теоретически могут быть несколько действительных сертификатов с одним и тем же enhanced key usage. Даже если брать только enhanced key usage ЭП-ОВ (1.2.643.100.2.2, для смэв, на котором я тренируюсь), то теоретически у одной организации может быть несколько ИС, подключенных к СМЭВ, и для каждой из них нужен отдельный сертификат ЭП-ОВ. Обычно конечно разные ИС на разных серверах, но если вдруг на одном сервере сошлись, то это будет ужас их отличить.

Ситуацию усложняет и то, что ЭП-ОВ не включает персональных данных либо адреса почты и в данном случае CN = наименованию организации (к слову, с таким CN сертификатов с разной комбинацией enhanced key usage и ФИО уже 5 штук). По рекомендациям предусмотрено, что в качестве CN можно использовать наименование или мнемонику ИС, но: 1) УЦ даже не спросил нужно ли нам указывать определенное CN; 2) самый первый сертификат ИС нужно приложить к заявлению на регистрацию и получить в ответ мнемонику (то есть в нем невозможно указать мнемонику, так как она будет выдана позже). В итоге действительно кроме отпечатка либо издателя+номера не остается других способов идентифицировать нужный сертификат.[QUOTE]Sergey Cheban пишет:
RanGe of Pointers to String Zero-terminated.Вот пример на паскале: [URL=http://www.cryptopro.ru/forum2/default.aspx?g=posts&m=10354#post10354]http://www.cryptopro.ru/forum2/default. ... #post10354[/URL].[/QUOTE]Спасибо за ссылку, но этот пример скорее поможет при перечислении и проверке каждого перечисленного сертификата, чем при задании поиска. Начать можно с того, что у меня в модуле (как и в теме по ссылке) вообще не указано что это массив! Однако это не должно было повлиять на "массив" из одного элемента который в памяти расположен также как просто элемент.

Могу понять почему не указан массив - если установить массив более чем из одного элемента компилятор изменит размер структуры, а если объявить как массив из одного элемента (как обычно делается для массива неизвестной длины), то нужно отключать проверку индексов массива при работе со структурой (иначе вылетит исключение). Так что явно придется менять описание структуры.
Есть еще одна мысль, где искать ошибку - возможно в описании еще и перепутаны одноименные A и W функции и на самом деле надо передать Юникод строку (да еще с двойным нулем в качестве завершающего символа). Хотя как я понимаю должна бы возвратиться ошибка обращения к памяти в этом случае.[QUOTE]Sergey Cheban пишет:
Вроде, OpenSSL ни про какие хранилища сертификатов не знает. Ему нужен либо сам сертификат в виде блоба, либо, на худой конец, имя файла.[/QUOTE]Хранилище доверенных сертификатов по крайней мере у него точно есть, только на Windows оно обычно не работает, так как путь в большинстве сборок вкомпилирован в стиле Linux. В общем, об этом я и говорю, что при работе с OpenSSL еще и свое хранилище делать.[QUOTE]Sergey Cheban пишет:
В принципе можно и с криптоапи поступить так же, давать ему сертификат в файле, но это не очень хорошо: windows позволяет сохранить сертификат в хранилище без возможности экспорта, это снижает риск утечки приватного ключа.[/QUOTE]Как выяснилось, одно другому не мешает! Можно передавать сертификат в файле в cryptoapi и получать ссылку на ключ.

Дано: приватный сертификат установлен со ссылкой на закрытый ключ (тут ссылка имеется ввиду не адрес в памяти, а имя и параметры контейнера и криптопровайдера) и хранится в хранилище Windows (закрытый ключ тоже в хранилище либо на токене). Берем сертификат из файла или из памяти (без закрытого ключа, декодированный из base64, если в файде был кодированный), передаем в CertCreateCertificateContext  получаем pCertContext (сертификат в закодированном ASN.1 и раскодированном виде - раскодируются основные поля, не все), передаем pCertContext  в CryptAcquireCertificatePrivateKey и получаем hCryptProv (полноценный контекст криптопровайдера с ключевой парой, то есть в том числе со ссылкой на закрытый ключ! соответствующий переданному сертификату), который можем использовать для подписи. Для сопоставления есть разные параметры, наиболее удобный - по открытому ключу в сертификате в хранилище и в переданном pCertContext. Побочный положительный эффект - не нужно гадать AT_KEYEXCHANGE или AT_SIGNATURE в контейнере - определяется автоматически и возвращается. То есть даже если в контейнере 2 ключевых пары, то открытый ключ (или сертификат) идентифицирует пару однозначно, а просто имя контейнера - нет.
Если экспорт ограничен - хотя блоб закрытого ключа не получим, но в остальном все так же.
#
За неделю с хвостиком есть подвижки: если кратко мини-менеджер немного усовершенствован и может восстанавливать часть данных, однако проверки по тексту еще не расставлены. Проверки в присваивании включены, но замечаний не показали.

Доработал связки по сертификатам, получилась первая рабочая версия (выдающая реальное значение подписи), перед возвращением данных производится проверка подписи - проверка проходит нормально. В процессе где-то пропала информация про сертификат (которая правильно выводилась с заглушкой значения подписи хэшем), но можно считать ма-а-а-аленькой победой.   qws  Для получения доступа к контейнеру соответствующему сертификату используется CryptAcquireCertificatePrivateKey - возвращает контекст криптопровайдера с контейнером и закрытым ключом. Тут плохая новость в том, хотя возвращает Истина (ошибок нет) и пригодный для работы контекст, но в GetLastError() появляется код ошибки 127 (не найден адрес процедуры) и как обычно он может всплыть только после нескольких операций и разрушить логику работы приложения.

Еще выяснился минус - функция преобразования в base64 из набора cryptoapi вставляет переводы строки (символы 13 и 10), хотя символа 13 вообще не должно быть в каноническом виде, да и обычно значение подписи пишется в одну строчку даже без  символа 10. Это не смертельно, так как значение подписи не попадает в "каноничные области" (те места, которые обязаны быть каноничными), но выглядит в итоге не очень хорошо, так что придется переводы строк убрать. Ранее это же было со значением хэша, там значение входило в "каноничную область", но перевод строки был только в конце и его пришлось отрезать. Теперь планирую найти где теряется сертификат и отработать проверку полученного подписанного xml, убирая по пути различные заглушки. Далее останется проверка каноникализации и тестирование на межведе.

Про каноникализацию нашел хорошую статью с примерами как и что делать вручную и под ее вдохновением набросал (но никак не тестировал еще) реализацию, за исключением 2 моментов - обработки атрибутов по умолчанию и замены символьных ссылок. С ними проблема в том, что они указываются в !DOCTYPE и могут быть не включены в документ, а указаны по внешней ссылке, то есть надо загружать документ откуда-то и его обрабатывать, а он может указывать на другой документ и т.д. Есть большие сомнения, что это когда-нибудь встретится в запросах между ИС, тем не менее без этого текст считается не каноничным. В общем, каноникализация оставлена "на сладкое".

Вчера весь день пытался заставить cryptoapi выдать подпись конкретным сертификатом. Идея была в использовании функции поиска сертификата CertFindCertificateInStore с определенным значением в расширенном использовании ключа. Вот только я видимо не понимаю как она работает, потому что она ничего не находит, хотя сертификат с указанным использованием есть и функцией перечисления всех сертификатов находится. В функцию поиска по расширенному использованию передается структура из количества строк и массива pchar значений (rgpszUsageIdentifier - в префиксах Си я не очень разбираюсь, первый раз такой rgpsz вижу, но комментарий стоит array of psz). Уже ее заполнял и как массив указателей на буферы и как указатель на массив указателей на буферы - результат один.

Еще посмотрю MSDN, возможно тут некая заморочка при переносе описания струтуры на Паскаль и придется менять описание. Хранилище используется "Личные" , и при перечислении и при поиске один и тот же дескриптор хранилища. Конечно можно и перечислять все потом проверять критерии, но если есть функция поиска по нужному параметру, зачем такое извращенство. Хотя наверняка при реализации этого будет быстрее понять, что нужно затолкать в структуру. Тут я понял почему некоторые программы идут с рекомендацией устанавливать только один сертификат: снес все остальные сертификаты и сделал через перечисление. Однако не теряю надежды добить поиск сертификата.

Соответственно придется хорошенько подумать относительно аналогичных функций для OpenSSL - поиска и перечисления сертификатов.
#
Совсем запутали с вольным употреблением "подогрева" и "горячей воды", а на скрине еще и холодная вода до кучи.
Смотрите если РСО - если предоставляете горячее водоснабжение (то есть потребитель считает по кубометрам и расходует горячую воду), то неважно из каких компонентов Вы их составили - есть определенный норматив сколько Гкал нужно затратить на подогрев. Умножаете норматив на стоимость 1 Гкал и складываете со стоимостью теплоносителя, получаете тариф. Все, внутренняя кухня что была холодная, ее нагрели на ГИС не отражается. Соответственно ПУ по тепловой энергии тоже по идее не отражается.
Если горячая вода не расходуется (в сферическом вакууме), а отдает тепловую энергию в квартирах и возвращается на подогрев, то как бы Вы его не переименовали - это именно отопление. Вот тут уже можно ПУ по тепловой энергии занести.
Если все же не РСО, а УК, то немного сложнее - с учетом кто исполнитель КУ, в чьей собственности бойлеры и т.д. Чтобы не повторятся во всех возможных сценариях - это уже обсуждалось в несколько непрофильном разделе и ни к чему не пришли, остались при своих мнениях, [URL=http://forum.burmistr.ru/viewtopic.php?f=147&t=5514]ссылка[/URL]. Там тоже везде писали, везде обращались, но... с точки зрения ГИС (и похоже Минстроя) это отопление, а никак не подогрев. И пока нормативка не изменится, ничего с этим не поделать.
#
Возможно несколько вариантов:
1) буквально несколько дней назад некоторые идентификаторы поменяли - проверьте по сообщениям в ГИС, нет ли идентификатора в списке;
2) данные объекта как-либо испорчены другими поставщиками информации - проверьте данные объекта;
3) объект выпал из ОЖФ, например ГЖИ засомневалась в лицензии - проверьте есть ли объект и в каком он состоянии.
Ну и вообще с ГИС ничему не удивишься.
#
Вопрос конечно интересный, но, кажется, у Вас что-то напутано с заполнением. Вам нужно четко определится, что вы предоставляете. Если это только подогрев, то вроде бы не нужно его делить на части, а если 2 пункта, то их нужно оба прицепить к договору. (Пусть меня поправят, у кого есть опыт по такому).
#
Не хочу обидеть, но о какой защите персональных данных Вы в принципе говорите. Ваши данные светятся везде - тот же председатель наверняка получает некий доход, который проходит через банк. А банки с готовностью сливают данные друг другу, через какое-нибудь бюро кредитных историй. А если есть доход, то и в налоговую капает информация. Налоговая немного сопротивляется, но тоже предоставит данные любому уполномоченному органу, если тот найдет ссылку на закон, по которому должен знать о доходах определенного гражданина. В больницу председатель ходит? В регистратуре хранится карточка. На поезде ездит? РЖД накапливает данные. Мобильником пользуется? Оператор накапливает данные. Паспорт у него есть? СНИЛС есть? Список можно продолжить. Так отчего ж внезапно фобия относительно сайта госуслуг?

Кроме того, хотя организациям действительно можно зарегистрировать другое уполномоченное лицо, НО! фактически все равно нужно регистрировать руководителя, потому что только руководитель сможет принять пользовательское соглашение от организации, заключать сделки по ГИС и  (он может назначить это другому лицу, но после того как  сам зарегистрируется). То есть он сначала должен сам зарегистрироваться.. причем по ЭЦП, а ФИО и ИНН должны быть указаны в ЕГРЮЛ, проставить права, а потом может не работать в ГИС. Весело, да? После этого, Вы говорите что организациям легче? Как бы не так.

Так что если не хотите регистрировать председателя - вот Вам другой совет: смените председателя на того, кто не боится. Тоже вполне себе решение.
#
Спору нет, интерфейс мягко говоря "нуждается в доработке".[quote:1qrh6ohn]Мы видим на полэкрана точку-маркер, индекс, зелёненький логотип домика, кадастровый номер, количество этажей.... НАХРЕНА загромождать, когда для начала работы с домом нужен тупо адрес, в одну строчку?[/quote:1qrh6ohn]Согласен на 100500%. Даже если не обрезать информацию до адреса, все можно было разместить в одну строку - по крайней мере в закрытой часть что не для жителей, а жители пусть любуются на свой домик во весь экран. В принципе, вопрос легко решается заменой таблицы стилей - например, в старой опере можно было выбрать свою таблицу стилей, это позволяет убрать все ненужное с экрана, а нужное, наоборот, выделить. Однако, есть неплохой шанс, что и все эти сообщения и всплывающие диалоги убьются вместе с ненужным, так как таблица заменяется полностью и все что должно остаться нужно добавить в новую. Посмотрите что-то подобное о замене стилей в своем браузере. Если что, со стилями могу помочь.[quote:1qrh6ohn]А когда ты пытаешься что-то разместить, ты должен нажать "разместить", а потом ответить на вопрос "ты уверен?", а потом ещё и на окей.[/quote:1qrh6ohn]Это вы еще на госзакупках или в СУФД не работали. На госзакупках реально надо три раза подтвердить - 1) что действительно собираетесь разместить, 2) что информация будет проверена; 3) что по результатам проверки найдено 100500 нарушений (по мнению сайта, на самом деле все ерунда), Вы действительно согласны разместить с нарушениями.[quote:1qrh6ohn]Для размещения информации не хватает вопроса: А вы точно уверены???" и кодового слова про девичью фамилию кошки твоей бабушки.[/quote:1qrh6ohn]Или нечитаемую капчу.[quote:1qrh6ohn]Механизм загрузки файлов также интересен. Вместо выбрать-загрузить мы видим "добавить-выбрать-загрузить" (на этом этапе разработчик, по-моему, пропустил вопрос: "вы уверены, что хотите загрузить"?"
Дальше ты должен нажать сохранить и обязательно нажать ОК. Потому что просто "сохранить" - это ты как бы не уверен, но уж если нажал "ОК" - то всё, да, стопудово сохранить.[/quote:1qrh6ohn]Тут однозначно надо дорабатывать логику интерфейса и сокращать число кликов.[quote:1qrh6ohn]Каждый раз, каждый, после каждого чиха ты будешь улетать вверх. [/quote:1qrh6ohn]Это тоже косяк интерфейса - после обновления данных стоит перелистывание вверх. Изначально это предназначается для случая, когда в многостраничном списке меняется страница. Незаметно, когда все умещается на одном экране - поэтому на куче сайтов остается всегда, ну а тут когда маркеры на полэкрана, действительно выходит убожество. Тут тоже есть нюанс - при перелистывании страницы назад, по идее должно "улетать вниз", но про это тоже часто разработчики сайтов забывают. Технически возможно сделать страницу, которая будет пролистываться к тому месту с которым работаете, а там уже отображать ссылку "вверх" или "вниз".

Кроме подтверждений, насколько вижу все вышеперечисленное не затрагивает внутреннюю работу ГИС и можно сделать за половину человеко-дня. Ну ладно, пусть неделю, если у них замороченная система разработки. Поэтому сухой остаток (уже без эмоций) надо бы написать разработчикам - вдруг прислушаются
#
[QUOTE]BatalinVA пишет:
10/3*3 =3.3333*3=9.999 и совсем другой правильный результат 10*3/3=10 т.е. не 9,999, а 10..[/QUOTE]Естественно, умножение целых чисел нужно делать вперед, это даже не вопрос. Однако, к сожалению, не всё так просто. Достаточно много языков программирования в которых результат деления двух целых чисел должен быть вещественным (в большинстве - double), целочисленного просто не предусмотрено, даже если остаток целочисленного деления ноль. И, хоть вы и делите 30/3, а выйдет (не проверял, что-то вроде) 10,00000000000001 за счет ошибки вещественного представления числа.[QUOTE]BatalinVA пишет:
ненавижу  программы писаные не мной[/QUOTE]Частично соглашусь, я не люблю программы в исходники которых не могу заглянуть. Хотя не факт, что буду править или пересобирать.[QUOTE]BatalinVA пишет:
не уверен в его правильности и в том что стоит ли вообще подобный способ обсуждать[/QUOTE]Ничего не мешает завести тему про округления в разделе программного ПО, там всем миром и выявим сильные/слабые места способа. Если конечно захотите.[QUOTE]Форест пишет:
Да не отменят никогда загрузку данных через шаблоны.[/QUOTE]Я не утверждаю, что это будет ближайшее время. Просто в один прекрасный день, когда большинство перейдет на СОАП (это явно будет нескоро), могут не выложить новую версию шаблона. Да чего спорить - поживем, увидим.[QUOTE]Форест пишет:
писать различные прокладки на .NETе[/QUOTE]Это да, я тоже пишу без дотнета. Как допилю - поделюсь результатами, вдруг кому пригодится.
#
За вчерашний день проверил остальные модули и оказалось еще интереснее: похоже секция initialization вызывается только в модулях напрямую указанных в основной программе. Причем порядок автоматически выстраивается, а если указанный модуль в программе не используется, то он может исключаться. То есть если модуль 1 использует модуле 2, а основная программа использует модуль 1, то сработает инициализация модуля 1, но не модуля 2. Определенная логика прослеживается. В этот раз у меня вышло что в основной программе указаны 2 модуля, а из них еще тянутся 7 штук. Переписал все кроме мини-менеджера на отдельные процедуры инициализации.

Загрузил эталонные примеры хэша в Base64 кодированном виде (для проверки нужен ли переворот хэша для данного криптопровайдера). Мини-менеджер все же определенно нужная вещь! В одном из вызовов перевода хэша в Base64 пропустил взятие адреса буфера и композитный тип перезаписался строкой-результатом. Данные испортились, в том числе указатель на буфер (но длина хэша мала, пострадали соседние переменных, но критического сбоя не произошло). И тут проявил себя мини-менеджер: 1) не дал освободить незарегистрированный адрес буфера (что привело бы к вылету) и вывел об этом сообщение, по которому я нашел ошибку; 2) когда программа закончилась, освободил все неосвобожденные буферы по своим данным. То есть несмотря на переполнение буфера и временную утечку памяти все закончилось хорошо.

Еще бы восстанавливать такие испорченные адреса буфера - вообще будет замечательно. Теоретически - надо еще фиксировать адреса самих записей и их флаги, но практически - все неявные присвоения пролетают стороной (неявные преобразования уже должны ловиться мини-менеджером, можно допилить). Некоторые мысли как это обойти есть: например, при обнулении композитного типа проверять "а был ли такой адрес переменной композитного типа" и вставить проверки переданных композитных строк (если обнуление не нужно) в каждой функции. За одно можно выводить сообщения о неявных присвоениях/преобразованиях. Минус - придется наверно написать вспомогательную программу просматривающую код и сообщающую куда вставить проверки.

С присвоениями, кстати, оказалось, что не только композитный тип, но и все структуры, содержащие его, нужно присваивать очень аккуратно - иначе в них будет совсем не то.
#
[QUOTE]BatalinVA пишет:
так как числа достаточно случайны, то появление четных и нечетных цифр перед пятеркой равновероятно[/QUOTE]Спасибо, что напомнили. Не спорю, что есть такое округление, но нужно понимать область применимости каждого алгоритма. Вот из-за такого округления и получается в 1С расхождение на 2 копейки в зарплате или сумме налога, отнимающее немало нервов. Крепко сомневаюсь в его целесообразности в случае ПД ГИС, вот несколько соображений:
1) Ровно половина _копейки_ - сомневаюсь, что это встречается очень часто. С учетом индексации на разное количество процентов, вероятность еще больше падает. От остального "задирания" суммы должно спасать правило, запрещающее _дважды и более раз_ округлять одно и то же число - имеется в виду до разного разряда - можно округлять только ранее не округленное "исходное" число. Иначе арифметически округлив 349 до десятков получите 350, округлив 350 до сотен = 400, а напрямую округлив 349 до сотен = 300. Бухгалтерское попадает на те же грабли, 349 до десятков - 350, 350 до сотен - 400, 349 до сотен - 300, то есть недопустимость повторного округления справедлива и для него. Хотя в половине случае погрешность поглощается, этого недостаточно для отмены правила.
2) Ага, очень "равновероятен" оклад одного человека в разные месяцы или его площадь квартиры в разные месяцы. Не спорю, что подход с бухгалтерским округлением позволяет свести _общую_ сумму по зарплате месяца (по временному разрезу), перераспределив доли копейки между строками. Однако это, например, проваливается, если в ведомости только 1 человек (аванс попросил 1 человек). В разрезе услуг в квитанции - тоже нецелесообразно, так как разные услуги могут идти к разным организациям, поэтому "перераспределять доли копейки" между ними неверно.
Если же принимаете все платежи к себе, то есть перераспределяете каждую услугу по отдельному списку потребителей и округляете в нем, рассчитываетесь по общей сумме с РСО. Потом _бухгалтерски округленные_ суммы из разных списков вставляете в ПД одного человека, то в подходе есть смысл. Естественно "равновероятности" никакой нет, не нужно об этом говорить, но потребители обычно закрывают глаза на доли копейки, если видят одну сумму каждый месяц.
3) В разрезе одного человека/услуги есть и другой подход: суммировать в начисленное в этом месяце разницу прошлого месяца между начисленным (без округления) и округленным к оплате и не допускать разницу в 1 копейку и более. При арифметическом округлении или округлении отбрасыванием дробной части копейки, это как раз должно давать эффект округления то вверх, то вниз, причем не с 1/2, а с реальной вероятностью равной дробной части копейки (начисленной за месяц). Хотя при таком подходе вообще не важно, какое округление было, сойдет даже не взятие определенной цифры из числа, а подбрасывание монетки - в следующем периоде целая копейка все равно выровняется. Вопрос только в том, кто кому будет должен по итогам месяца.[QUOTE]Сергей_ пишет:
Странно, что имея интерфейс для ввода информации ручным способом в ГИС нужны какие-то еще эксельки для того же самого ручного ввода.[/QUOTE]Увы, разработчики ГИС воспринимают только SOAP в качестве автоматического ввода. Эксель они ввели по многочисленным просьбам и мечтают когда-либо отменить. Хотя пока неизвестно когда, но если большинство перейдет на SOAP, то срок замаячит на горизонте. Для автоматизации среднему программисту было бы более удобно загружать неподписанный xml или csv, чем SOAP. Обсуждение - в разделе программного обеспечения, [URL=http://forum.burmistr.ru/viewtopic.php?f=147&t=5481]тут[/URL] и [URL=http://forum.burmistr.ru/viewtopic.php?f=147&t=5540]тут[/URL]. Однако подвижек к этим форматам нет. "Не по силам SOAP" воспринимается разработчиками только как временная мера и когда-нибудь придется осваивать SOAP. Я уже потихоньку начал, но с другой ГИС.
Начал с другой - как я понял по ответам экспертов (пусть меня поправят, если не так), ГИС ЖКХ вроде как не дает править данные, внесенные по SOAP внесением правок из личного кабинета - кнопки становятся неактивны (хотя вносить новые данные можно). Вообще, это логично (иначе есть большой шанс, что очередной SOAP запрос перезапишет внесенное вручную - данные нужно исправить в ИС, работающей с SOAP), но крайне неудобно (нельзя ввести некий переходный период: разрешили вводить определенные данные через SOAP - всё, пока разрешение действует, личный кабинет бесполезен по данным типам данных). Определенную гибкость дает выбор какие данные разрешено вносить ИС (то есть можно сначала разрешить один тип данных, через какое-то время разрешить другой b т.д.), но и только. Следовательно, после перехода на SOAP, Эксель тоже отпадет.
Поэтому я пока собираюсь отработать технологию на ГИС ГМП, потом внести ряд правок под ГИС ЖКХ. [URL=http://forum.burmistr.ru/viewtopic.php?f=147&t=5835]Список "достижений"[/URL]
#
[quote:1svz4tqw]Правда, может получиться строка с одним нулем после точки (если R2 равно 0, то inttostr вернет один ноль): '17.0'. Дорисовывать ноль в разряды сотых рубля? Выводить в этом случае '17'?[/quote:1svz4tqw]Можно конечно и так, но и правда как-то сложно - анализировать, увеличивать другую переменную, тратить 4 байта на число до сотни. Именно поэтому проще умножить на 100 (знаю, умножать не айс, но что поделать) и сделать округление в один integer (longint, int64 нужное подчеркнуть - целое знаковое, до 21 миллиона рублей будет достаточно длины 4 байта). Тогда после преобразования в строку целого рубля получим ровно два нуля в конце. От умножения на 100 наверно даже можно уйти если преобразовывать на ассемблере на уровне битов, с учетом распределения битов мантиссы и порядка в double.[quote:1svz4tqw]Только почему мы должны заниматься такими извращениями???[/quote:1svz4tqw]С этим согласен. Вот только если мы в итоге округлим в одну сторону, а гис в другую - будет "неудобняк". Значит нужно договориться о форматах. И тут можно отметить, что разработчики ГИС не раз подчеркивали, что шаблоны Экселя для ручного заполнения, а при ручном заполнении проблемы не возникает - значит ее и не исправят, поэтому автоматизация сопряжена с такими танцами с бубном.
#
[QUOTE]Сергей_ пишет:
Я попробовал без переименования на файле нажать на этом файле правую кнопку мыши и в контекстном меню выбрать 7-Zip->Открыть архив.[/QUOTE]Да, есть такое. 7-zip добавляет меню открытия для любых расширений, как по мне это удобно для одной программы и не очень удобно в целом. В том плане, что таких же "умных" программ накапливается просто вагон и маленькая тележка - и меню постепенно превращается в "кабину современного авиалайнера" - куча неиспользуемых строк.[QUOTE]Сергей_ пишет:
один финт - запись макросов в Excel.[/QUOTE]Сами в начале пробовали? В записанных макросах Эксель и Ворд все делают через объект Selection, в который можно затолкать что угодно и поэтому новичкам ни разу не понятно. В обычных же "рабочих" макросах крайне редко использую Selection. Поэтому для изучения объектной модели с нуля это категорически не подходит. Максимум уточнить новые для себя детали. Про документацию можно сказать то же - просто бесит когда в справке Майкрософт пишет, что метод или свойство (тот же Cells(x,y)) возвращает Object а какого он типа этот объект? им лениво было уточнить что это Range? Ну я конечно понимаю, что теоретически наверно может быть что-то другое, но в 99,9% это Range. Поэтому изначально только копирование чужого работающего кода, а уж потом запись макросов.[QUOTE]Programmer пишет:
Округление может не всегда помочь.[/QUOTE]Конечно, double и float округлять несколько бесполезно из-за двоичного представления дробной части, более перспективно умножение на 100, округление/отбрасывание дробной части (перевод в целое число, при этом и занимаемый размер уменьшится с 8 байт до 4 байт и "помехи" двоичного представления исчезнут) и перевод [B][U]целого числа[/U][/B] в строку. А там уже строкой можно рулить как угодно - например, вставить точку отступив справа 2 символа.
[QUOTE]Programmer пишет:
Тогда часть строки '1234.5600012' скопируется с первого символа по седьмой (точка в пятой позиции). В результате c1 будет равна: '1234,56', ее то и выводим. Должно помочь, надеюсь.[/QUOTE]Замечательно, только это может быть не '1234.5600012', а '1234.559998' и тогда программа исказит копейки.
#
Спасибо. Действительно менеджер паскаля использует что-то подобное, хотя в подробности не вдавался: в начале блока точно пишется скрытая служебная структура, в том числе в ней указан размер блока, что позволяет освобождать память не указывая размер - менеджер сам его считает. И между блоками расстояние достаточное, скорее всего в конце тоже есть служебные маркеры. heaptrc вообще прямо в яблочко, как раз на FreePascal компилирую. Раньше о нем читал, что утечки памяти выявлять удобно, а тут не вспомнил.

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

Однако, похоже разгадка оказалась вообще совсем в другом (хотя обломы с памятью не исключаю до конца) - компилятор Фрипаскаля понимает разные "диалекты" Паскаля и некоторые управляющие конструкции не работают в одних, но работают в других. Обычно диалект распространяется только на один модуль и смешивание неудобств не доставляет. В частности, в диалекте Дельфи работает обработка исключений try.. except..end; try..finally..end; но не работает объявление операторов. На диалекте Фрипаскаля наоборот. Поэтому модуль длинных строк на одном диалекте, а httpclient на другом. О несоответствии этих конструкций текущему диалекту модуля компилятор должным образом ругается.

Однако, также есть отличия в синтаксисе инициализации/выгрузки модуля от классического BEGIN END (аналог main в си) и специальных ExitProc (каждый модуль сохраняет указатель ExitProc при загрузке, потом восстанавливает при выгрузке и если не NULL вызывает функцию по этому адресу - выходит нечто похожее на стек модулей). Уже давненько привык к варианту секций initialization .. finalization .. end. В этот раз тоже было так записано, модуль работал, когда более-менее отладил его - перешел к следующему, который его использует. И где-то в этот момент видимо изменился диалект, секции initialization и finalization просто стали игнорироваться без каких-либо сообщений об ошибке.
[SIZE=85px][COLOR=greenpt]Отправлено спустя 27 минуты 31 секунды:[/COLOR][/SIZE]
Фактически, уже чудо что хотя бы что-то работало на непроинициализированном модуле. После очередной отладки обратил внимание, что помимо ошибок доступа еще не читается кэш ответов портала (при чудесах с памятью не удивительно) и вываливаются обращения к EnterCriticalSection (пока отлаживал просто их комментировал - в тестовой программе все равно только одна thread). А InitializeCriticalSection и чтение файла как раз были в inialization. Сложил 2 и 2, вставил туда еще вывод строки на консоль - не выводит, перенес код инициализации и выгрузки в отдельные процедуры, вручную их вызвал - заработало, хотя наверно теперь надо все модули проверить. И уже не знаю на кого злиться - на авторов компилятора, который не предупреждает, что часть кода просто игнорируется или на себя что не использую классику, которая точно реализована в компиляторе.

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

Подпишись на рассылку новостей ЖКХ, а также наших статей!

Спасибо, вы успешно подписались на рассылку!