[h6784rfg6]

Подскажите, пожалуйста, как решить следующую задачу:

Есть файл, содержащий текстовые данные. Все данные разделены по типам (например, текст, дуга, многоугольник). Название типа сопровождено определенным знаком – например <. После названия типа следует повторяющееся кол-во параметров. Далее идет пробел и новый элемент/блок. Все данные перемешаны (Блоки одинаковых типов данных не идут один за другим).
Имеется следующая задача :

Надо вчитать файл в память и проанализировать. Надо пройти все строки файла таким образом:

- При обнаружении названия типа данных (например - <текст) надо создать новый элемент массива структур текст и дальнейшими строчками заполнить параметры этого элемента. Такими параметрами могут быть: положение, номер, ширина, и т.д. При этом каждый параметр находится на новой строчке – порядок параметров не меняется.

Подскажите, как провести такой анализ средствами языка VB.NET. Я новичок, но создать массив структур определенного типа и приписать им значения смог бы (с грехом пополам), но вот провести такой анализ не умею, хоть убей.
Как дополнение скажу, что созданные и заполненные таким образом массивы структур будут применяться для создания определенного чертежа в AutoCAD. Я проштудировал создание элементов AutoCAD, так что смогу, надеюсь, потом использовать сохраненные данные при вызове нужных функций библиотеки ObjectARX.

[hwd]

Сообщение от h6784rfg6 Есть файл, содержащий текстовые данные. Все данные разделены по типам (например, текст, дуга, многоугольник). Название типа сопровождено определенным знаком – например <.

Что мешает сразу выложить файл? DXF - тоже текстовый файл. Судя по логину, регистрация для разового обращения на форум?

Сообщение от h6784rfg6 провести такой анализ не умею, хоть убей.

Кто-то мешает научиться?

[h6784rfg6]

Могу вставить) Кстати, у тебя тоже ничего так логин)

[Олег (jr.)]

Попробуй сначала в консольном приложении:

Код:

[Выделить все]

       public static void ReadSBahn()
       {
           string fileName=@"C:Test\...\S-Bahn.rvx";
           List<string> myList = new List<string>();
           List<List<string>> myData = new List<List<string>>();
           FileStream MyFileStream = null;
           StreamReader MyReader = null;
           MyFileStream = new FileStream(fileName, FileMode.Open);
          
           MyReader = new StreamReader(MyFileStream);
           
           MyReader.BaseStream.Position = 0;
           while (!MyReader.EndOfStream)
           {
               String myString = MyReader.ReadLine();
               // reads data into an array & outputs data to console

               string[] myArray = myString.Split('>');
               myList = new List<string>();
               //just to display a headers:
               //if (myArray.Length>1)
               //Console.WriteLine("{0}\t{1}", myArray[0].ToString(), myArray[1].ToString());
               //to display all items:
               for (int i = 0; i < myArray.Length; i++)
               {
                   myList.Add(myArray[i].ToString());
                   //Console.WriteLine("{0}\t", myArray[i].ToString());
               }

               myData.Add(myList);

       
           }
           foreach (List<string> item in myData)
           {
               // parse every item and pass them in AutoCAD
               Console.WriteLine("{0}\t", item[0].ToString());
           }
           Console.WriteLine();
       }

[Дима_]

Сообщение от h6784rfg6 Я новичок, но создать массив структур определенного типа и приписать им значения смог бы (с грехом пополам), но вот провести такой анализ не умею, хоть убей.

Я 8 раз прочитав так и не понял, что у тебя вызывает затруднения.

[h6784rfg6]

Я не могу пройти файл строчка за строчкой и приписать значения( Надо чтобы при нахождении определенного блока последующие n строк были записаны как новый элемент массива структуры) Вот это не могу

[gomer]

откуда такой формат файла?

[hwd]

@h6784rfg6,
Я пока воздержусь от продолжительных матов в адрес автора обозначенного формата... Во всяком случае до того времени, как ты ответишь на вопрос #7. Так же интересует, что помешало автору формата воспользоваться DXF или XML?

[h6784rfg6]

Точно не знаю, откуда взялся этот формат. Мне дали файл и сказали импортировать данные из него в автокад. Так что все претензии к аффтару формата))

[hwd]

Сообщение от h6784rfg6 Точно не знаю, откуда взялся этот формат. Мне дали файл и сказали импортировать данные из него в автокад. - При обнаружении названия типа данных (например - <текст) надо создать новый элемент массива структур текст и дальнейшими строчками заполнить параметры этого элемента. Такими параметрами могут быть: положение, номер, ширина, и т.д. При этом каждый параметр находится на новой строчке – порядок параметров не меняется.

Понятно. Если случится встреча с автором - натяни ему глаз на ж@пу и попутно расскажи о существовании XML.

Теперь по поводу твоего вопроса:

Насколько я тебя понял, ты хочешь редактировать обозначенный файл, добавляя в него новые "элементы", а не вычерчивать на его основе что-то в AutoCAD. Работать непосредственно с тем гуаном, которое тебе прислали - не советую, лучше преобразовать данные в удобоваримый "стандартный" формат и работать с ними, после чего результат обратно превращать в гуано. Парсить этот "формат" очень просто: построчно считываешь текст и анализируешь на наличие ">" или "=". Результат преобразуешь в объектную модель LINQ to XML и жанглируешь им так, как тебе нужно: добавляешь\удаляешь элементы XElement и XAttribute, меняешь их местами и т.п. (чего душе угодно). Затем, когда создашь нужную тебе структуру, выполняй обратное действо: из XML данные записываешь в твой "формат".

Всё просто до безобразия, однако если бы у автора "формата" руки росли не из ж@пы, то тебе не пришлось бы заниматься ненужным парсингом и переформатированием, т.к. ты сразу работал бы непосредственно с XML, средствами обозначенной мною выше .net технологии (или любой другой, предназначенной для работы с XML).

P.S. Кодом из #4 увлекаться не рекомендую, в виду наличия в нём изрядного количества ошибок (да и вообще там какая-то муть написана). Сразу же, что бросилось в глаза:
1. Утечка памяти в виду не освобождения ранее взятых ресурсов, т.е. отсутствие следующих вызовов:

Код:

[Выделить все]

MyReader.Close();
MyReader.Dispose();
MyFileStream.Close();
MyFileStream.Dispose();

Поскольку блоки using для обозначенных объектов в коде не присутствуют.

2. Отсутствие обработки пустых строк, коих в файле предостаточно, в виду чего в список попадает большое количество ненужных "пустышек".

3. Это полнейшая муть:

Код:

[Выделить все]

string[] myArray = myString.Split('>');
myList = new List<string>();
//just to display a headers:
//if (myArray.Length>1)
//Console.WriteLine("{0}\t{1}", myArray[0].ToString(), myArray[1].ToString());
//to display all items:
for (int i = 0; i < myArray.Length; i++)
{
	myList.Add(myArray[i].ToString());
	//Console.WriteLine("{0}\t", myArray[i].ToString());
}

Подумай, что будет при обработки ">RAHMEN" (или любой др. подобной) и всех прочих подобных строк (какие элементы будут добавлены в список)? Добавление в список новых, собственно ручно сгенерированных "пустышек".

4. В коде нет обработки, отделяющей имя свойства от его значения.

5. В основе всего должно лежать логическое обоснование: я не знаю, с какой целью автор разместил табуляцию в коде:

Код:

[Выделить все]

 Console.WriteLine("{0}\t", item[0].ToString());

На визуальное форматирование она никакого влияния не оказывает (в данном примере).

6. Нахрена там вообще список списков (вопрос риторический)? Тот же самый результат, предоставленный автором кода, можно получить ограничившись и всего лишь одним списком. Я ещё понимаю, если бы каждый набор записей был записан в виде записи словаря, т.е. однозначно идентифицирован, дабы можно было работать с конкретной, чётко определённой группой записей. Однако то, что по факту сделано в коде #4 - это муть.

[gomer]

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

[Дима_]

Сообщение от hwd Парсить этот "формат" очень просто: построчно считываешь текст и анализируешь на наличие ">" или "=". Результат преобразуешь в объектную модель LINQ to XML и жанглируешь им так, как тебе нужно: добавляешь\удаляешь элементы XElement и XAttribute, меняешь их местами и т.п. (чего душе угодно). Затем, когда создашь нужную тебе структуру, выполняй обратное действо: из XML данные записываешь в твой "формат".

ИХМО данная рекомендация правильно если "твой формат" и есть XML, ну или очень близкий к нему (не столько к формату, а к функционалу жонглировния встроенного в LINQ). Я бы сразу просписал правила "жонглирования" своего формата и парсил в него - зачем лишнее звено?
з.ы. хотя тут я не учел что это VB... - а там с "жонглированием" и описанием формата может оказаться неважно.

[hwd]

Сообщение от Дима_ хотя тут я не учел что это VB... - а там с жонглированием может оказаться неважно.

Не VB, а VB.NET - соответственно всё доступно.

Сообщение от Дима_ ИХМО данная рекомендация правильно если "твой формат" и есть XML, ну или очень близкий к нему (не столько к формату, а к функционалу жонглировния встроенного в LINQ). Я бы сразу просписал правила "жонглирования" своего формата и парсил в него - зачем лишнее звено?

"Близость\Дальность" к XML здесь роли не играет. Любые данные можно с лёгкостью представить в формате XML (даже двоичные). "Лишнее звено" в данном случае используется для того, чтобы имеющиеся данные можно было бы обрабатывать ПРИВЫЧНЫМИ, "родными" способами (в данном случае LINQ to XML). XML для того и задумывался, чтобы его использовали как УНИВЕРСАЛЬНЫЙ формат хранения\передачи данных. Под этот формат написано много библиотек\технологий. Соответственно, если знаешь хотя бы одну из них, то и не будет нужды изучать "правила жонглирования" сотен вот таких вот "продуманных" приложений.

[Дима_]

Сообщение от hwd Не VB, а VB.NET - соответственно всё доступно.

Я не уверен (а сказать более сильно сомневаюсь - по крайней мере о таких новшествах не слышал) что он поддерживает создание структур данных произвольного формата с обработкой их как "родных".

Любые данные можно с лёгкостью представить в формате XML (даже двоичные). "Лишнее звено" в данном случае используется для того, чтобы имеющиеся данные можно было бы обрабатывать ПРИВЫЧНЫМИ, "родными" способами (в данном случае LINQ to XML).

Это я понимаю и пишу - самоцитата

ну или очень близкий к нему (не столько к формату, а к функционалу жонглировния встроенного в LINQ)

а если на этом функционале надо писать не меньше (а то и больше) чем под "свою" структуру - то какой в ней смысл.

Соответственно, если знаешь хотя бы одну из них, то и не будет нужды изучать "правила жонглирования" сотен вот таких вот "продуманных" приложений.

Никому изучать мои правила и методы жонглирования не придеться - формат1, переходит в формат2 в "черном ящике" и использования внутри xml или нет никаким образом на результат не влияет. Почему в качестве формата1 и формата2 не использованны стандартные форматы - это другой вопрос. Может просто из-за разгильдяйства и квалификации автора. А может и по объективным причинам - производительность, размер и пр.
Например есть у Вас двоичные данные которые проиндексированны в виде упорядоченного дерева - вы их тоже предложите перевести в XML и жонглировать "стандартными" средставми - нет - если и сохраните (например для переноса куда-либо) в формат XML, то уж поиск-то по дереву точно "соорудите" сами (иначе эффективность его упадет логарифмически) - и возникает вопрос в целесообразности перевода таких данных в XML (один черт придеться писать свои методы которые вызывают тот-же LINQ). Пример в другую крайность - может "его" формат представляет все то-же самое но в другой кодировке + еще пару бантиков - мы этого не знаем - по сему и инструмент надо выбирать по наковальне.

з.ы. я не в коем случае не утверждаю, что XML в варианте автора не подойдет - я про то, что ненужно сразу не подумав пихать "универсальные форматы".

[gomer]

думаю проще было бы найти эту автономноненецкую ГИС и экспортировать из нее в dxf,если конечно дело не запахнет палевологией

[hwd]

Сообщение от Дима_ Я не уверен (а сказать более сильно сомневаюсь - по крайней мере о таких новшествах не слышал) что он поддерживает создание структур данных произвольного формата с обработкой их как "родных".

Я не понял этой фразы. Что подразумевается под "структурами данных произвольного формата"?

Сообщение от Дима_ Может просто из-за разгильдяйства и квалификации автора.

100%

Сообщение от Дима_ А может и по объективным причинам - производительность, размер и пр.

Это вряд ли, т.к. и на XML можно написать компактный по объёму контент.

Сообщение от Дима_ Например есть у Вас двоичные данные которые проиндексированны в виде упорядоченного дерева - вы их тоже предложите перевести в XML и жонглировать "стандартными" средставми

в данном случае речь о данных, представленных в ТЕКСТОВОМ формате.

Сообщение от Дима_ я про то, что ненужно сразу не подумав пихать "универсальные форматы"

Здесь вопрос не столько в "универсальности формата", сколько в "универсальности обработки". Обрабатывать структурированные текстовые данные гораздо удобней тем же LINQ to XML, чем построчно читать текст из потока (stream) и затем выполнять парсинг полученного контента, а потом ещё и заниматься внесением изменений в эти данные, вставляя строки между уже имеющимися, изменяя существующие записи, удаляя лишние и т.п.

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

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

[DEM]

Мужики успокойтесь....
Ему уже дали ответ....

[zamtmn]

>>а потом ещё и заниматься внесением изменений в эти данные, вставляя строки между уже имеющимися, изменяя существующие записи, удаляя лишние и т.п.
Надо различать форматы хранения данных и форматы в которых они обрабатываются внутри программы или автокад открыв dxf тоже вставляет строки между имеющимися? Да в xml удобно сохранить (но удобство не в формате, а в том что вокруг него уже написана вся необходимая инфраструктура) какието данные, но это незначит что внутри программы этиже данные обязательно оправдано хранить в нем.

[Дима_]

Сообщение от hwd Я не понял этой фразы. Что подразумевается под "структурами данных произвольного формата"?

В ряде языков программирования структуры данных это не внешнее благо, а формы обращения построенные непосредственно самим языком и есть механизмы при которых они будут выглядеть не как внешние объекты (Dicitionary и пр), а так-же как встроенные типа - например массивы. Например в F# полный аналог XML структуры (может я чего упустил - но как-то так) можно задать 3 строками:

Код:

[Выделить все]

 type MyXml=
  |MyNode of string*(string*string) list*MyXml list
  |Val of string*string

ну и пример заполнения (ручной):
MyNode("Root",["version","1.0";"encoding","utf8"],[MyNode("Tree1",[],[Val("1","Раз");Val("2","Два")]);MyNode("tree2",[],[Val("3","ТРИ")])]);;
вернет:
val it : MyXml =
MyNode
("Root",[("version", "1.0"); ("encoding", "utf8")],
[MyNode ("Tree1",[],[Val ("1","Раз"); Val ("2","Два")]);
MyNode ("tree2",[],[Val ("3","ТРИ")])])
Это уже совсем далеко от темы - но в общем парситься после такого представления она (структура) штатными средствами ничуть не хуже чем xml LINQ - хотя конечно если LINQ окажеться за глаза то переписывать его никакого смысла нет.

Сообщение от hwd в данном случае речь о данных, представленных в ТЕКСТОВОМ формате.

тут ключевое не двоичные или текстовые данные - а индексированные - при переносе их в XML для поиска по индексу LINQ не поможет (оно про то что они индексированны не знает - а чтоб ему это объяснить надо чуток попрогромировать сверх его "родного" функционала.)

чем построчно читать текст из потока (stream) и затем выполнять парсинг полученного контента, а потом ещё и заниматься внесением изменений в эти данные, вставляя строки между уже имеющимися, изменяя существующие записи, удаляя лишние и т.п.

Такого я не предлогал.

Если всё ещё не понятно о чём я говорю, то можно сделать простое сравнение...

Да все мне пока понятно - еще раз повторю пока не вижу данных во что их надо преобразовывать и по каким правилам - увидив их можно сказать - что в данном случае подойдет больше, но пока их нет говорить а тем более предлагать устроить конкурс (я может тоже посмотря на них - решу что LINQ здесь проще всего) - это что монетку бросить - я уже привел два варианта на которым XML мякго говоря не эффективен.

[hwd]

Сообщение от zamtmn Надо различать форматы хранения данных и форматы в которых они обрабатываются внутри программы или автокад открыв dxf тоже вставляет строки между имеющимися?

Начиная читать это предложение я воспринимаю это как утверждение, но дочитав до конца, вижу плавный переход к вопросу. Так это вопрос или утверждение? Я различаю форматы хранения и форматы хранения в памяти (вообще это называется сериализацией/десериализацией). Как за кулисами AutoCAD обрабатывает DXF я не в курсе, но предполагаю, что так же выполняют десериализацию в объектный код (правда объекты свои, не XML to LINQ).

Сообщение от zamtmn Да в xml удобно сохранить (но удобство не в формате, а в том что вокруг него уже написана вся необходимая инфраструктура

Именно это я и пытаюсь донести до зрителей.

Сообщение от zamtmn но это незначит что внутри программы этиже данные обязательно оправдано хранить в нем.

А внутри программы данные и не нужно хранить в формате XML. Внутри программы они десериализуются в объектный код и работа ведётся с объектами, а не с "текстом в формате XML".