Объявление

Свернуть
Пока нет объявлений.

Модуль VLСверкаПФ не работает

Свернуть
X
  • Фильтр
  • Время
  • Показать
  • Сортировать
  • Упорядочить по
Очистить всё
новые сообщения

    #31
    Версия обновлена. В ходе решения вопроса с атрибутами и файлами "только чтение" также реализована долгожданная работа с файлами во вложенных папках (включается флажком).
    А теперь хотелось бы вынести на обсуждение следующий вопрос - скорее, к программистам. Вчера получил несколько файлов, которые криво обрабатывались программой (в некоторых случаях - вплоть до вылета с исключением) и в то же время нормально открывались в Internet Explorer и Firefox и проходили проверку программой CheckXML. Ручное изучение файлов показало суть кривой обработки: после имён элементов ДатаЗаполнения и СтраховойНомер стоят пробелы как в открывающих, так и в закрывающих тэгах:
    Код:
    <СтраховойНомер >123-456-789 01</СтраховойНомер >
    <ДатаЗаполнения >01.01.2001</ДатаЗаполнения >
    Русская Википедия пишет общую структуру, но про пробелы там сказано лишь то, что их в именах элементов быть не должно. По официальной спецификации XML я вообще не понял, можно ли так делать. Цель - думаю, переписывать мне XML-парсер под это дело или отложить, списав на ошибку формирования.

    Комментарий


      #32
      Сообщение от lubezniy Посмотреть сообщение
      Версия обновлена. В ходе решения вопроса с атрибутами и файлами "только чтение" также реализована долгожданная работа с файлами во вложенных папках (включается флажком).
      Обогнали. Я сегодня тоже написал чтение вложенных папок, правда, без рекурсии.

      Ручное изучение файлов показало суть кривой обработки: после имён элементов ДатаЗаполнения и СтраховойНомер стоят пробелы как в открывающих, так и в закрывающих тэгах:
      Я этот вопрос поднимал ещё месяц назад, при объяснении причин зависания "псковской программы".

      Код:
      <СтраховойНомер >123-456-789 01</СтраховойНомер >
      <ДатаЗаполнения >01.01.2001</ДатаЗаполнения >
      Русская Википедия пишет общую структуру, но про пробелы там сказано лишь то, что их в именах элементов быть не должно. По официальной спецификации XML я вообще не понял, можно ли так делать. Цель - думаю, переписывать мне XML-парсер под это дело или отложить, списав на ошибку формирования.
      Думается, вопрос однозначный.
      1. Википедия. Если в именах элементов пробелов быть не должно, они должны отсутствовать не только внутри имени, но и в начале или конце. Ведь не говорится, что имя может начинаться с пробела, или им заканчиваться.
      2. Спецификация. Тут ещё нагляднее.
      STag ::= '<' Name (S Attribute)* S? '>'
      Отдельно показаны открывающая и закрывающая скобки, пробелы не предусмотрены.
      Вывод: правильнее всего включить проверку на пробелы в checkXml, тогда проблема разрешится сама собой.

      Комментарий


        #33
        На самом деле, в открывающем тэге пробел служит разделителем имени элемента и его атрибутов. Это есть даже в файлах ПФР (ПачкаВходящихДокументов). Главный вопрос - по закрывающим тэгам.

        Комментарий


          #34
          Сообщение от lubezniy Посмотреть сообщение
          На самом деле, в открывающем тэге пробел служит разделителем имени элемента и его атрибутов. Это есть даже в файлах ПФР (ПачкаВходящихДокументов). Главный вопрос - по закрывающим тэгам.
          Но сути вопроса это не меняет
          А вдруг кому-нить захочется делать так: < СтраховойНомер >
          А с выводом Вы согласны?
          Последний раз редактировалось vk65; 16.07.2011, 14:37.

          Комментарий


            #35
            Сообщение от lubezniy Посмотреть сообщение
            реализована долгожданная работа с файлами во вложенных папках (включается флажком).
            procedure TMain_Form.OnShow (Sender: TObject);
            нужно добавить:
            Subdirs_CheckBox.Checked := Config.Subdirs;

            Комментарий


              #36
              Сообщение от Алексей К. Посмотреть сообщение
              включен в CheckXML.
              [/url]
              Спасибо, что включили ! Просьба еще обновлять ее там своевременно.
              Сегодня, 16.07.2011, скачал более свежую CHECKXML, а там устаревшая программа VLSVERKAPF.EXE за 28 июня, хотя есть уже улучшенная за 11 июля.

              Комментарий


                #37
                Сообщение от vk65 Посмотреть сообщение
                Но сути вопроса это не меняет
                А вдруг кому-нить захочется делать так: < СтраховойНомер >
                А с выводом Вы согласны?
                Меня смутили два момента.
                Первое - в спецификации по end-tags (чуть дальше) прописано:
                Код:
                End-tag
                [42]   	ETag	   ::=   	'</' Name S? '>'
                Что означает S с вопросительным знаком, я, по правде говоря, не понял. Если S означает string, а вопросительный знак - любое количество символов в строке, то ладно.
                Второй момент осознаётся, если от формализма перейти к практике. В бизнесе существует понятие обычаев делового оборота. На простой русский в нашем контексте оно переводится примерно как "мало ли что написано, все так делают". IE открывает, Firefox открывает, CheckXML не ругается - ну и? Если это случай из разряда единичных, можно до лучших времён списать его на производственные издержки, вписав потенциальную несовместимость с файлами, сформированными такой-то программой, с указанием способа устранения. Если не единичный, придётся или сделать какую-то предобработку, или переписать парсер (т. е., серьёзно повозиться).

                Комментарий


                  #38
                  Сообщение от vk65 Посмотреть сообщение
                  procedure TMain_Form.OnShow (Sender: TObject);
                  нужно добавить:
                  Subdirs_CheckBox.Checked := Config.Subdirs;
                  Точно, прошляпил. В следующей версии будет исправлено.

                  Комментарий


                    #39
                    Сообщение от lubezniy Посмотреть сообщение
                    Второй момент осознаётся, если от формализма перейти к практике. В бизнесе существует понятие обычаев делового оборота. На простой русский в нашем контексте оно переводится примерно как "мало ли что написано, все так делают". IE открывает, Firefox открывает, CheckXML не ругается - ну и? Если это случай из разряда единичных, можно до лучших времён списать его на производственные издержки, вписав потенциальную несовместимость с файлами, сформированными такой-то программой, с указанием способа устранения. Если не единичный, придётся или сделать какую-то предобработку, или переписать парсер (т. е., серьёзно повозиться).
                    Уважаемый Виктор! Внимательно слежу за Вашим и vk65 творчеством и сотрудничеством. К сожалению, не пишу в Delphi и пока не пользовалась Вашей программой по причине отсутствия времени, а также её неактуальности для меня в связи с наличием программы собственной разработки (на 1С). Однако хочу высказать свое мнение. Т.к. года два назад самой пришлось "рисовать" файл XML, и файл был сформирован криво именно про причине несоответствия открывающих и закрывающих тегов формату: <ИмяТега>Значение</Имятега> (просто прошляпила ), полагаю, что это случай единичный (взять хотя бы статистику от Sova64) и Вам переписывать парсер не нужно. Ведь у большинства все работает. Большинство страхователей пользуются стандартными программами (Смоленск, Оренбург, Башкирия), распространяемыми ПФ. А такие как я, Михаил Иванович, BlackFox и многие другие, пользующиеся собственными программами, подобные ошибки с тегами не допускают, или же должны их исправить. Правила на то и правила, чтобы им соответствовать. Посему возмущает вольное обращение с форматом страхового номера (123-456-789-12 вместо утвержденного 123-456-789 12 ).
                    Считаю, что Вам не надо тратить время на то, чтобы программа работала на орбите, под водой, в жерле вулкана и т.п., поскольку вероятность использования её в таких условиях равна нулю!
                    А проверку на отсутствие пробелов в тегах - включить в ЧЕКХМЛ !

                    Комментарий


                      #40
                      Сообщение от lubezniy Посмотреть сообщение
                      Что означает S с вопросительным знаком, я, по правде говоря, не понял. Если S означает string, а вопросительный знак - любое количество символов в строке, то ладно.
                      Ситуация несколько хуже:
                      2.3 Common Syntactic Constructs
                      This section defines some symbols used widely in the grammar.
                      S (white space) consists of one or more space (#x20) characters, carriage returns, line feeds, or tabs.
                      Вопросительный знак означает, что элемент может присутствовать, но не обязан.
                      А если понимать дословно вот это:
                      [Definition: The end of every element that begins with a start-tag MUST be marked by an end-tag containing a name that echoes the element's type as given in the start-tag:]
                      можно сделать вывод, что так правильно: <tag >x</tag >,
                      а вот так неправильно: <tag>x</tag >.
                      То есть, с поиском закрывающего тэга вроде особых проблем нет. Проблема в том, что, встретив внутри открывающего тэга пробел, вы ожидаете атрибут, а его нет. Хотя, тоже в принципе решаемо - можно искать " >". Но при этом время обработки может увеличиться в разы.

                      IE открывает, Firefox открывает, CheckXML не ругается - ну и?
                      То, что браузеры нормально воспринимают - это вообще вопрос вторичный. А вот что будет, если в ПФР создадут какой-нибудь новый проверочный комплекс и ошибки посыплются там. Особенно, после того, как чек выдал "Успех".

                      Если это случай из разряда единичных, можно до лучших времён списать его на производственные издержки, вписав потенциальную несовместимость с файлами, сформированными такой-то программой, с указанием способа устранения.
                      Только неизвестно, сколько существует программ, которые так формируют.

                      Если не единичный, придётся или сделать какую-то предобработку, или переписать парсер (т. е., серьёзно повозиться).
                      Я лично полностью согласен с мнением LoraK. Могу только добавить. На данный момент можно выдавать сообщение типа "не найден закрывающий тэг </ИмяТэга>", чтобы пользователю было понятно, в чем проблема.
                      Последний раз редактировалось vk65; 17.07.2011, 01:11.

                      Комментарий


                        #41
                        Сообщение от LoraK Посмотреть сообщение
                        А проверку на отсутствие пробелов в тегах - включить в ЧЕКХМЛ !
                        А с этим может возникнуть проблема: разработчики чека часто говорят, что не имеют права добавлять проверки, которых нет в ТЗ.

                        Комментарий


                          #42
                          Сообщение от LoraK Посмотреть сообщение
                          Уважаемый Виктор! Внимательно слежу за Вашим и vk65 творчеством и сотрудничеством. К сожалению, не пишу в Delphi и пока не пользовалась Вашей программой по причине отсутствия времени, а также её неактуальности для меня в связи с наличием программы собственной разработки (на 1С). Однако хочу высказать свое мнение. Т.к. года два назад самой пришлось "рисовать" файл XML, и файл был сформирован криво именно про причине несоответствия открывающих и закрывающих тегов формату: <ИмяТега>Значение</Имятега> (просто прошляпила ), полагаю, что это случай единичный (взять хотя бы статистику от Sova64) и Вам переписывать парсер не нужно. Ведь у большинства все работает.
                          Не думаю. Если файл соответствует спецификации XML (а необходимость такого соответствия прописана в 192п), он должен быть прочитан.
                          Сообщение от LoraK Посмотреть сообщение
                          Большинство страхователей пользуются стандартными программами (Смоленск, Оренбург, Башкирия), распространяемыми ПФ. А такие как я, Михаил Иванович, BlackFox и многие другие, пользующиеся собственными программами, подобные ошибки с тегами не допускают, или же должны их исправить. Правила на то и правила, чтобы им соответствовать. Посему возмущает вольное обращение с форматом страхового номера (123-456-789-12 вместо утвержденного 123-456-789 12 ).
                          Если уж на то пошло, формат страхового номера прописан лишь для отдельных документов в давно не действующем, хоть и не отменённом приложении 3 к 192п (формат 4.0). Формы СЗВ-6 к этим документам не относятся. Впрочем, в прошлой ветке была ссылка на Екжанова, где он объяснял, почему CheckXML в своё время начал пропускать такие номера. Повторяться не стоит.
                          Сообщение от LoraK Посмотреть сообщение
                          А проверку на отсутствие пробелов в тегах - включить в ЧЕКХМЛ !
                          Вот этого точно не будет - хотя бы из-за нарушения таким шагом спецификации XML. Я уж не говорю про стандартный парсер, используемый в СheckXML (меня он в своё время не устроил тем, что мог обрабатывать только файлы, а мне нужно было использовать его для чтения строк, полученных по HTTP).

                          Комментарий


                            #43
                            Сообщение от vk65 Посмотреть сообщение
                            Ситуация несколько хуже:
                            Вопросительный знак означает, что элемент может присутствовать, но не обязан.
                            А если понимать дословно вот это:
                            можно сделать вывод, что так правильно: <tag >x</tag >,
                            а вот так неправильно: <tag>x</tag >.
                            То есть, с поиском закрывающего тэга вроде особых проблем нет. Проблема в том, что, встретив внутри открывающего тэга пробел, вы ожидаете атрибут, а его нет. Хотя, тоже в принципе решаемо - можно искать " >". Но при этом время обработки может увеличиться в разы.
                            Поэтому я думаю насчёт предобработки. Если время обработки увеличится в большие разы лишь для тех файлов, которые содержат пробелы (вернее, whitespaces) в тэгах, это не будет очень существенно: таких страхователей сравнительно немного. Для остальных же файлов - смотря во сколько раз.

                            То, что браузеры нормально воспринимают - это вообще вопрос вторичный. А вот что будет, если в ПФР создадут какой-нибудь новый проверочный комплекс и ошибки посыплются там. Особенно, после того, как чек выдал "Успех".
                            Вообще говоря, таких извращенцев, как я, использующих свои парсеры, мало. Microsoft-овский парсер, используемый в IE и, если я не ошибаюсь, CheckXML, корректно переваривает такие вещи. Проблемы по нему лишь две: работа только с файлами и многообразие версий, осложняющее развёртывание (насколько я понимаю, эта проблема портит кровь пользователям CheckУфа и программ, в которые она встроена).
                            Только неизвестно, сколько существует программ, которые так формируют.
                            Неизвестность - это плохо.
                            Я лично полностью согласен с мнением LoraK. Могу только добавить. На данный момент можно выдавать сообщение типа "не найден закрывающий тэг </ИмяТэга>", чтобы пользователю было понятно, в чем проблема.
                            В общем, будем думать, экспериментировать и смотреть.

                            Комментарий


                              #44
                              Сообщение от lubezniy Посмотреть сообщение
                              Поэтому я думаю насчёт предобработки. Если время обработки увеличится в большие разы лишь для тех файлов, которые содержат пробелы (вернее, whitespaces) в тэгах, это не будет очень существенно: таких страхователей сравнительно немного. Для остальных же файлов - смотря во сколько раз.
                              Естественно, только содержащих пробелы из-за того, что строка с данными может из-за этого многократно просматриваться до самого конца.
                              В принципе, если искать закрывающий тэг не как '</' + B + '>', а как '</' + B, он найдётся по-любому, а потом при желании можно проверить, есть ли у него пробелы перед '>'.
                              И мне кажется, что если выдавать об этом предупреждение, хотя бы общее, а не по каждому тэгу, есть вероятность, что автор конкретной программы формирования поправит вывод у себя, и общее количество таких программ со временем уменьшится.

                              Комментарий


                                #45
                                Сообщение от vk65 Посмотреть сообщение
                                В принципе, если искать закрывающий тэг не как '</' + B + '>', а как '</' + B, он найдётся по-любому, а потом при желании можно проверить, есть ли у него пробелы перед '>'.
                                Это смотря как построить файл. На такой вот конструкции, скорее всего, будет завал.
                                Код:
                                <ИвановИван>
                                 <ИвановИванИванович>
                                 </ИвановИванИванович>
                                </ИвановИван>

                                Комментарий

                                реклама

                                Свернуть
                                Обработка...
                                X