[Дельфи, нюб] Как записать двухмерный массив в текстовый файл?
меня будут пинать, но я бы заюзал xml, чтобы программа производила впечатление энтерпрайз-поделки.
http://www.codenet.ru/progr/delphi/stat/Using-XML/
http://www.codenet.ru/progr/delphi/stat/Using-XML/
Эм...
Что конкретно не получается?
Чтение из файла? Запись в него?
В чём вообще проблема может быть в этой тривиальной задаче?
Что конкретно не получается?
Чтение из файла? Запись в него?
В чём вообще проблема может быть в этой тривиальной задаче?
чтобы файл хранился вот примерно так:
<? xml version="1.0">
<root>
<table rows="N" cols="M>
<line>
<item>val1</item>
<item>val2</item>
....
</line>
</table>
</root>
дорого, конечно, но зато потом гемора будет поменьше.
<? xml version="1.0">
<root>
<table rows="N" cols="M>
<line>
<item>val1</item>
<item>val2</item>
....
</line>
</table>
</root>
дорого, конечно, но зато потом гемора будет поменьше.
дорого, конечно, но зато потом гемора будет поменьше.Чем интересно?
xml-парсеры есть везде. А при хранении двумерных массивов из строк в каком-нибудь самодельном формате могут возникнуть некоторые сложности.
Я гляну. Спасибо.
А другой, более насущный вопрос ,если можно :
Как трёхмерный график построить в Дельфи , с использованием , опять же двумерного массива значений функции в узлах сетки ?
А другой, более насущный вопрос ,если можно :
Как трёхмерный график построить в Дельфи , с использованием , опять же двумерного массива значений функции в узлах сетки ?
Удачи найти готовый компонент для графика =)
Боюсь создание нового класса ты не осилишь =/
Боюсь создание нового класса ты не осилишь =/
Ясно. Собственно так и думал, что встроенной халявы нет типа как в MathLab.
thx
thx
Халява всегда есть! =)
Всё уже написано до нас. Нужно только умень найти, украсть, или купить.
можешь глянуть это:
http://www.torry.net/pages.php?id=846
он правда под .NET
Всё уже написано до нас. Нужно только умень найти, украсть, или купить.
можешь глянуть это:
http://www.torry.net/pages.php?id=846
он правда под .NET
Для этого есть (проприетарная - нужен серийник) программа Surfer. Ей нужно подать файл следующего формата:
x_1 y_1 z_1
x_2 y_2 z_2
...
Пример:
x_1 y_1 z_1
x_2 y_2 z_2
...
Пример:
var
data:array[0..100,0..100] of extended;
i,j:integer;
f:text;
begin
{calculate function}
assign(f,'res.txt');
rewrite(f);
for i:=0 to 100 do
for j:=0 to 100 do
writeln(f,i*0.01,' ',j*0.01,' ',data[i,j]);
close(f);
end;
Простейший способ нарисовать что либо трехмерное в Дельфи - это взботнуть OpenGL (реально за день два разобраться).
XML лучше не использовать, а взять cvs (т.е. столбцы разделенные ; ) - менее гемморно.
XML лучше не использовать, а взять cvs (т.е. столбцы разделенные ; ) - менее гемморно.
Если у человека проблема записать массив в текстовый файл, то openGL ему точно не поможет.
XML лучше не использовать, а взять cvs (т.е. столбцы разделенные ; ) - менее гемморно.
всё хорошо, кроме случая многострочного текста в элементах массива.
хотя у автора сего чудного треда в массиве числа, конечно 
а взять cvs (т.е. столбцы разделенные ; )Во-первых csv, во-вторых не обязательно ;
Для этого есть (проприетарная - нужен серийник) программа Surferсудя по дальнейшему содержанию поста, Surfer не нужен, а нужен gnuplot.
Гыгы, я их путаю, как и svc и scv 
А почему до сих пор никто не вспомнил про TeeChart? Или его использовать уже не модно?
xml-парсеры есть везде. А при хранении двумерных массивов из строк в каком-нибудь самодельном формате могут возникнуть некоторые сложности.Это не аргумент, а всего лишь перевод проблемы на более высокий уровень.
Да, хранить в xml - хорошо, потому что xml-парсеры есть везде. А хранить в текстовом файле тоже хорошо, потому что библиотеки для работы с текстовыми файлами есть уж точно везде. И ч0?
библиотеки для работы с текстовыми файлами есть уж точно вездедля работы с текстовыми файлами - да, есть, а вот парсинга и генератора того же cvs уже обычно нет.
А хранить в текстовом файле тоже хорошо, потому что библиотеки для работы с текстовыми файлами есть уж точно везде. И ч0?
пионер, б%ять. Как ты будешь хранить многомерный массив состоящий из многострочного текста? С экранирующими символами охота поебацца?
Во-первых, в XML с ними тоже надо ебаться.
Во-вторых, если до тебя не дошло - есть способ хранения данных "в текстовом файле", и есть способ хранения данных "в XML-файле".
Если ты используешь второй способ - у тебя ниоткуда магическим образом не появятся функции "записать двумерный массив в XML-файл" и "считать двумерный массив из XML-файла". Тебе придётся писать их самому, используя функции XML-парсера.
И мой пост был о том, что само по себе наличие XML-парсера не может служить аргументом в пользу XML перед каким-то своим форматом. Потому что в любом случае тебе придётся писать две функции, упомянутые выше, ручками. Только в одном случае ты будешь использовать функции для работы с файлами и строками, а в другом - для работы с XML.
Наличие XML-парсера может служить лишь аргументом в пользу того, что XML - не совсем говно, и он не хуже текстовых файлов - потому что тебе не придётся разбирать сам XML руками, и ты можешь использовать XML-парсер (точно так же, как тебе не надо руками искать на винчестере нужные блоки, и ты можешь использовать готовую функцию "считать файл с таким-то именем в строку"). Для того, чтобы показать, что XML лучше текстовых файлов, тебе придётся искать другой аргумент.
Во-вторых, если до тебя не дошло - есть способ хранения данных "в текстовом файле", и есть способ хранения данных "в XML-файле".
Если ты используешь второй способ - у тебя ниоткуда магическим образом не появятся функции "записать двумерный массив в XML-файл" и "считать двумерный массив из XML-файла". Тебе придётся писать их самому, используя функции XML-парсера.
И мой пост был о том, что само по себе наличие XML-парсера не может служить аргументом в пользу XML перед каким-то своим форматом. Потому что в любом случае тебе придётся писать две функции, упомянутые выше, ручками. Только в одном случае ты будешь использовать функции для работы с файлами и строками, а в другом - для работы с XML.
Наличие XML-парсера может служить лишь аргументом в пользу того, что XML - не совсем говно, и он не хуже текстовых файлов - потому что тебе не придётся разбирать сам XML руками, и ты можешь использовать XML-парсер (точно так же, как тебе не надо руками искать на винчестере нужные блоки, и ты можешь использовать готовую функцию "считать файл с таким-то именем в строку"). Для того, чтобы показать, что XML лучше текстовых файлов, тебе придётся искать другой аргумент.
бла-бла-бла, бла-бла-бла.
Ты сам-то хоть понял, что написал? В случае xml не придётся заботиться об экранировании текста.
Ты сам-то хоть понял, что написал? В случае xml не придётся заботиться об экранировании текста.
Очень важное замечание. Его логическим продолжением является утверждение "PHP не нужен". Ведь есть Ассемблер!
Ведь, в конце концов, есть два способа написания программ - на Ассемблере и на PHP. И если ты используешь второй способ - у тебя ниоткуда магичесим образом не появится функция "сделать чтобы все было зашибись". Тебе придется писать ее самому, используя функции PHP.
Само по себе наличия интерпретатора PHP не может служить аргументом в пользу PHP перед каким-то другим языком. Потому что в любом случае тебе придётся писать функцию, упомянутую выше, ручками. Только в одном случае ты будешь использовать операции для работы с регистрами и битами, а в другом - функции PHP.
Наличие интерпретатора PHP может служить лишь аргументом в пользу того, что PHP - не совсем говно, и он не хуже ассемблера - потому что тебе не придётся реализовывать PHP самостоятельно, и ты можешь использовать существующий интерпретатор (точно так же, как тебе не надо руками искать на винчестере нужные блоки, и ты можешь использовать готовый системный вызов "считать файл с таким-то именем в буфер"). Для того, чтобы показать, что PHP лучше Ассемблера, тебе придётся искать другой аргумент.
Ведь, в конце концов, есть два способа написания программ - на Ассемблере и на PHP. И если ты используешь второй способ - у тебя ниоткуда магичесим образом не появится функция "сделать чтобы все было зашибись". Тебе придется писать ее самому, используя функции PHP.
Само по себе наличия интерпретатора PHP не может служить аргументом в пользу PHP перед каким-то другим языком. Потому что в любом случае тебе придётся писать функцию, упомянутую выше, ручками. Только в одном случае ты будешь использовать операции для работы с регистрами и битами, а в другом - функции PHP.
Наличие интерпретатора PHP может служить лишь аргументом в пользу того, что PHP - не совсем говно, и он не хуже ассемблера - потому что тебе не придётся реализовывать PHP самостоятельно, и ты можешь использовать существующий интерпретатор (точно так же, как тебе не надо руками искать на винчестере нужные блоки, и ты можешь использовать готовый системный вызов "считать файл с таким-то именем в буфер"). Для того, чтобы показать, что PHP лучше Ассемблера, тебе придётся искать другой аргумент.
Нет, это не будет логическим продолжением.
А вот между си и PHP, если ты пишешь свой собственный алгоритм сортировки - действительно, разницы практически не будет. Тебе надо будет писать одно и то же, и отличия будут - всего лишь небольшие, связанные с отличием синтаксиса.
Вот скажи мне, как тут наличие парсера XML скажет, что XML лучше текстовых файлов:
?
А вот между си и PHP, если ты пишешь свой собственный алгоритм сортировки - действительно, разницы практически не будет. Тебе надо будет писать одно и то же, и отличия будут - всего лишь небольшие, связанные с отличием синтаксиса.
Вот скажи мне, как тут наличие парсера XML скажет, что XML лучше текстовых файлов:
fh = new File('data.txt');
fh->freadln("%d %d", rows, cols);
arrData = array of int [1..rows][1..cols];
for(i=1;i<rows,i++) {
for(j=1;j<rows;j++) {
fh->fread("%d", arrData[i][j]);
}
fh->freadln;
}xh = new XMLParser('data.txt');
rows = xh->table->getAttr('rows');
cols = xh->table->getAttr('cols');
arrData = array of int [1..rows][1..cols];
for(i=1;i<rows;i++) {
for(j=1;j<cols;j++) {
arrData[i][j] = xh->table->rows[i]->cols[j]->getCData;
}
}?
В случае xml не придётся заботиться об экранировании текста.То есть, как минимум, нужен уже не только парсер XML (кто файл-то создавать будет?)
ОК, у связки парсера XML с созданием XML есть одно преимущество перед самописным форматом и прямой работой с файлами - не надо думать об экранировании (хотя всё экранирование выносится в одну строчку, как и обратная процедура).
Что-нибудь ещё?
схема dom обычно включает и возможность изменения и сохранения документа.
В случае xml не придётся заботиться об экранировании текста.кстати
а как экранируются скобки ]]> (или как там они пишется) ?
т.е. вопроса два:
1) есть стандарт на их экранирование
2) ве ли парсеры этот стандарт выполняют?
скобки чаще всего экранируются методом "авось"
кстатиДаже если они не экранируются - можно ведь написать <![CDATA[]]]]><![CDATA[>]]>, по идее, должно получиться как раз то, что нужно?
а как экранируются скобки ]]> (или как там они пишется) ?
не надо думать об экранированииэто мало?
Что-нибудь ещё?масштабирование - возможность добавить произвольную информация, как отдельно, так и к каждому значению.
стандартизованнось - проще засунуть эти данные в другую программу
стандартизованнось - проще засунуть эти данные в другую программуВот это вызывает сомнения.
Потому что XML - такой же стандарт, как и файловая система. И само по себе использование XML не даст тебе никаких преимуществ перед использованием простого текстового файла.
XML - это стандарт хранения произвольных данных, так же, как и файл в ФС.
Вот если пользоваться каким-то подмножеством XML, которое является стандартом для хранения двумерных массивов - это уже другое дело.
А если придумать это подмножество самому - другая программа съест (точнее, не съест) эти данные точно так же, как и файл в придуманном лично тобой формате.
И даже более того. На двумерные массивы _уже_ есть стандарт текстовых файлов - а именно CSV. Стандарта XML-файлов на них нет.
Так что, если записать этот двухмерный массив в CSV - засунуть эти данные в другую программу будет гораздо легче, чем если он будет записан в _какой-то_ XML. Другая программа просто не поймёт по этому _какому-то_ XML-у, где именно там таблица.
И в данном случае от использования _какого-то_ XML (просто потому что XML - это круто) вместо _конкретных_ текстовых файлов (а именно, CSV) один только вред и практически никакой пользы.
Например, если посмотреть на то, что тут предлагали.
Возьмём два файла:
1,2
3,4
Как ты думаешь, какой из них больше подойдёт какому-нибудь Excel-у?
<? xml version="1.0">
<root>
<table rows="2" cols="2">
<line>
<item>1</item>
<item>2</item>
</line>
<line>
<item>3</item>
<item>4</item>
</line>
</table>
</root>
Даже больше - первый файл будет понятен довольно большому количеству программ. А второй будет непонятен ни одной, кроме той программы, которая его создала (непонятен, как двухмерный массив).
даже более того. На двумерные массивы _уже_ есть стандарт текстовых файлов - а именно CSVи на него даже стандарт есть?
автоматические чтение не сделаешь: кодировка не декларируется, разделитель тоже не декларируется
И, на всякий случай, сформулирую свою позицию.
Да, XML это действительно круто. В некоторых случаях.
Надо понимать, почему именно XML - круто, и в каких случаях лучше использовать что-то другое вместо XML.
Например, в своих маленьких программах, если созданные твоей программой файлы будет читать только твоя программа - действительно лучше пользоваться XML, это упрощает код и избавляет от той же возни с экранированием, это - преимущества. А вот "XML-парсеры есть везде" не имеет к этому случаю абсолютно никакого отношения - нам наплевать на это "везде", мы о нём не знаем, файлы используются только нашей программой, как хотим, так и храним.
В случае, когда мы храним какие-то конкретные данные (например, адресную книгу и есть широко используемый стандарт на подмножество XML для хранения адресных книг - тоже имеет смысл использовать XML. Потому что - упрощение кода и универсальность, авторы других программ тоже, скорее всего, будут использовать XML, да и конвертеры из/в другие популярные форматы должны быть. Тут аргумент "XML-парсеры есть везде" тоже ни при чём, нам наплевать на то, есть ли где-то-там XML-парсер, мы пользуемся конвертируемым и удобным в использовании форматом файлов адресных книг.
А в случае, когда мы храним какие-то конкретные данные (например, двухмерный массив на который нет никакого XML-стандарта - то надо использовать другие стандарты. Но, конечно, не изобретать свой стандарт-подмножество XML только потому что XML - это круто и XML-парсер есть везде. Потому что, несмотря на то, что XML-парсеры есть везде, команда какого-нибудь MS Office и не подумает писать с использованием XML-парсера (как и с использованием чего-нибудь другого) парсер твоего стандарта двумерных таблиц, и с файлами в твоём стандарте будешь работать только ты. И всем тысячу раз наплевать на то, что где-нибудь есть XML-парсер, как и на то, есть ли где-нибудь библиотека для работы с ФС, потому что сам по себе XML, как и просто файл - всего лишь способ хранения данных вообще, а программы работают не с данными вообще, а с конкретными данными (адресная книга, таблицы итп). Данные можно хранить в XML или каким-то другим способом, можно сравнивать эти способы, искать лучший. Но таблицу или адресную книгу нельзя хранить в XML-файле. Таблицу можно хранить в формате ABC, DEF, XYZ; при этом, ABC будет текстовым, DEF бинарным, а XYZ - подмножеством XML. Но таблица будет храниться именно в формате XYZ, а не в формате XML.
Да, XML это действительно круто. В некоторых случаях.
Надо понимать, почему именно XML - круто, и в каких случаях лучше использовать что-то другое вместо XML.
Например, в своих маленьких программах, если созданные твоей программой файлы будет читать только твоя программа - действительно лучше пользоваться XML, это упрощает код и избавляет от той же возни с экранированием, это - преимущества. А вот "XML-парсеры есть везде" не имеет к этому случаю абсолютно никакого отношения - нам наплевать на это "везде", мы о нём не знаем, файлы используются только нашей программой, как хотим, так и храним.
В случае, когда мы храним какие-то конкретные данные (например, адресную книгу и есть широко используемый стандарт на подмножество XML для хранения адресных книг - тоже имеет смысл использовать XML. Потому что - упрощение кода и универсальность, авторы других программ тоже, скорее всего, будут использовать XML, да и конвертеры из/в другие популярные форматы должны быть. Тут аргумент "XML-парсеры есть везде" тоже ни при чём, нам наплевать на то, есть ли где-то-там XML-парсер, мы пользуемся конвертируемым и удобным в использовании форматом файлов адресных книг.
А в случае, когда мы храним какие-то конкретные данные (например, двухмерный массив на который нет никакого XML-стандарта - то надо использовать другие стандарты. Но, конечно, не изобретать свой стандарт-подмножество XML только потому что XML - это круто и XML-парсер есть везде. Потому что, несмотря на то, что XML-парсеры есть везде, команда какого-нибудь MS Office и не подумает писать с использованием XML-парсера (как и с использованием чего-нибудь другого) парсер твоего стандарта двумерных таблиц, и с файлами в твоём стандарте будешь работать только ты. И всем тысячу раз наплевать на то, что где-нибудь есть XML-парсер, как и на то, есть ли где-нибудь библиотека для работы с ФС, потому что сам по себе XML, как и просто файл - всего лишь способ хранения данных вообще, а программы работают не с данными вообще, а с конкретными данными (адресная книга, таблицы итп). Данные можно хранить в XML или каким-то другим способом, можно сравнивать эти способы, искать лучший. Но таблицу или адресную книгу нельзя хранить в XML-файле. Таблицу можно хранить в формате ABC, DEF, XYZ; при этом, ABC будет текстовым, DEF бинарным, а XYZ - подмножеством XML. Но таблица будет храниться именно в формате XYZ, а не в формате XML.
Автоматическое чтение своих CSV-файлов - сделаешь. Возможно, оно будет читать и чужие CSV-файлы. Excel наверняка будет читать твои CSV-файлы.
А вот если использовать свои XML-файлы, то чужие XML-файлы в чужом формате ты прочитать не сможешь, и Excel не сможет прочитать твои файлы. Потому что XML - вего лишь способ, а сам формат - это то, как именно ты в этом XML хранишь данные; и, несмотря на то, что и ты, и вася пупкин, и тёма лебедев используете для хранения двумерных массивов XML, форматы хранения будут разными - точно так же, как если бы и ты, и вася пупкин и тёма лебедев использовали для хранения двумерных массивов файлы, а не, к примеру, базу данных, форматы хранения тоже были бы разными.
Нет такого формата двумерных массивов - "XML".
А вот если использовать свои XML-файлы, то чужие XML-файлы в чужом формате ты прочитать не сможешь, и Excel не сможет прочитать твои файлы. Потому что XML - вего лишь способ, а сам формат - это то, как именно ты в этом XML хранишь данные; и, несмотря на то, что и ты, и вася пупкин, и тёма лебедев используете для хранения двумерных массивов XML, форматы хранения будут разными - точно так же, как если бы и ты, и вася пупкин и тёма лебедев использовали для хранения двумерных массивов файлы, а не, к примеру, базу данных, форматы хранения тоже были бы разными.
Нет такого формата двумерных массивов - "XML".
и как тому же экселю скармливать таблицу с элементами из многострочного текста?
Потому что, несмотря на то, что XML-парсеры есть везде, команда какого-нибудь MS Office и не подумает писать с использованием XML-парсера (как и с использованием чего-нибудь другого) парсер твоего стандарта двумерных таблиц, и с файлами в твоём стандарте будешь работать только тыно тот же XPath никуда не девается, а с помощью него как раз поддержка чужих xml-ей делается довольно просто
Насколько я помню, многострочные поля (как и поля, содержащие запятые или двойные кавычки) заключаются в двойные кавычки. Двойные кавычки внутри полей заменяются на пару двойных кавычек.
А вообще, всё это легко установить опытным путём - создаёшь в экселе таблицу, пишешь куда хочется многострочный текст и сохраняешь как csv, после чего открываешь результат любимым текстовым редактором.
А вообще, всё это легко установить опытным путём - создаёшь в экселе таблицу, пишешь куда хочется многострочный текст и сохраняешь как csv, после чего открываешь результат любимым текстовым редактором.
А вот если использовать свои XML-файлы, то чужие XML-файлы в чужом формате ты прочитать не сможешь, и Excel не сможет прочитать твои файлы.на голубом глазу гонишь...
ты хоть раз excel-ем xml-файлы открывать пробовал? а тем более xml-файлы со схемой?
Автоматическое чтение своих CSV-файлов - сделаешь.для распознавания кодировки использовать штирлица в автоматическом режиме?
Кем делается?
Разработчиками MS Office делается поддержка XML васи пупкина?
Или вася пупкин пишет программу, которая выдаёт умеет выдавать и считывать XML, а затем - XSLT, который этот XML конвертирует в какой-нибудь CSV для использования в других программах, и какую-то программку, которая, для того, чтобы дать пользователям возможность импорта из других программ, CSV конвертирует в XML (и всё это - не забывая о экранировании)? В чём тогда преимущество использования XML, не легче ли не иметь мозг себе и пользователю, и сразу использовать CSV?
Разработчиками MS Office делается поддержка XML васи пупкина?
Или вася пупкин пишет программу, которая выдаёт умеет выдавать и считывать XML, а затем - XSLT, который этот XML конвертирует в какой-нибудь CSV для использования в других программах, и какую-то программку, которая, для того, чтобы дать пользователям возможность импорта из других программ, CSV конвертирует в XML (и всё это - не забывая о экранировании)? В чём тогда преимущество использования XML, не легче ли не иметь мозг себе и пользователю, и сразу использовать CSV?
ты хоть раз excel-ем xml-файлы открывать пробовал?Извини, нет под рукой Excel-а. Хочешь сказать, он откроет такой xml-файл, как в моём посте, как таблицу?
а тем более xml-файлы со схемой?...а схему, видимо, имеет смысл использовать какую-нибудь готовую... вот мы и приходим к использованию _конкретного_ (а не самодельного) формата для двумерных массивов, который уже будет открываться во многих программах.
Я же в первый раз отвечал на пост "используй какой-нибудь XML - сам придумаешь, какой - потому что XML - круто, и XML-парсеры есть везде". Видишь разницу?
Разработчиками MS Office делается поддержка XML васи пупкина?разработчиками excel делается поддержка xpath-а
и ты бы в этом мог бы сам убедиться, если бы хоть раз попробовал с данными из xml-я поработать в excel
Тебе слово "своих" цветом выделить?
В своих CSV как хочешь, так и хранишь. Например, никто тебе не запрещает принять правило "всегда использовать UTF-8".
В своих CSV как хочешь, так и хранишь. Например, никто тебе не запрещает принять правило "всегда использовать UTF-8".
Ты не ответил на мой вопрос.
Если я сейчас придумаю какой-нибудь формат вроде
excel его откроет?
Какие действия надо совершить, чтобы excel его открыл?
Если я сейчас придумаю какой-нибудь формат вроде
<?xml version="1.0"?>
<penarturRoot>
<penarturMetadata>
<type>2D array</type>
<createdFrom>penartur's megaprogram</createdFrom>
</penarturMetadata>
<penarturTable>
<penarturColumn>
<penarturCell>1</penarturCell>
<penarturCell>3</penarturCell>
</penarturColumn>
<penarturColumn>
<penarturCell>2</penarturCell>
<penarturCell>4</penarturCell>
</penarturColumn>
</penarturTable>
</penarturRoot>
excel его откроет?
Какие действия надо совершить, чтобы excel его открыл?
Вообще, странно, что ты до сих пор меня не понял.
Я тут пытаюсь сказать, что само по себе использование XML никаких преимуществ в переносимости файлов не даёт; более того, просто использование XML, наоборот, сделает твои файлы полностью непереносимыми.
Другое дело - использование какого-нибудь существующего формата для хранения конкретного типа данных (например, двумерных таблиц). И тогда, опять же - в общем случае, переносимость не будет зависеть от того, основан этот формат на XML или нет, поэтому лучше использовать формат, основанный на XML, т.к. с ним проще работать.
Но высказывания вроде "придумай свой формат на основе XML, это будет гораздо круче и переносимее, чем использовать CSV, потому что XML - круто, и XML-парсеры есть везде" являются бредом.
XML - всего лишь средство для создания формата, и (для тех, кто в танке) - XML НЕ ЯВЛЯЕТСЯ ФОРМАТОМ ДЛЯ ХРАНЕНИЯ ДВУМЕРНЫХ МАССИВОВ, АДРЕСНЫХ КНИГ ИЛИ ЕЩЁ ЧЕГО-НИБУДЬ В ЭТОМ РОДЕ. Другое дело, что некоторые из форматов хранения двумерных массивов могут быть основаны на XML - но тогда, опять же, речь идёт об использовании конкретного формата, а не XML вообще.
Я тут пытаюсь сказать, что само по себе использование XML никаких преимуществ в переносимости файлов не даёт; более того, просто использование XML, наоборот, сделает твои файлы полностью непереносимыми.
Другое дело - использование какого-нибудь существующего формата для хранения конкретного типа данных (например, двумерных таблиц). И тогда, опять же - в общем случае, переносимость не будет зависеть от того, основан этот формат на XML или нет, поэтому лучше использовать формат, основанный на XML, т.к. с ним проще работать.
Но высказывания вроде "придумай свой формат на основе XML, это будет гораздо круче и переносимее, чем использовать CSV, потому что XML - круто, и XML-парсеры есть везде" являются бредом.
XML - всего лишь средство для создания формата, и (для тех, кто в танке) - XML НЕ ЯВЛЯЕТСЯ ФОРМАТОМ ДЛЯ ХРАНЕНИЯ ДВУМЕРНЫХ МАССИВОВ, АДРЕСНЫХ КНИГ ИЛИ ЕЩЁ ЧЕГО-НИБУДЬ В ЭТОМ РОДЕ. Другое дело, что некоторые из форматов хранения двумерных массивов могут быть основаны на XML - но тогда, опять же, речь идёт об использовании конкретного формата, а не XML вообще.
Тебе слово "своих" цветом выделить?не понимаю я это слово.
из того, что ты пишешь свою программу, не означает, что ты или твои пользователи не хотят для работы с твоим форматом использовать не твои инструменты.
довольно часто возникают нештатные задачи, которые штатные средства могут не решать, и здесь очень помогает, если формат хранения стандартный.
возьмем тот же телефонный справочник и задачу перейти с кода 095 на 495, одно дело - это когда данные лежат в каком-то непонятном своем бинарном или даже текстовом файле, другое дело - это sql-база или xml
excel его откроет?excel - его откроет, но не как двухмерную таблицу
XML НЕ ЯВЛЯЕТСЯ ФОРМАТОМ ДЛЯ ХРАНЕНИЯ ДВУМЕРНЫХ МАССИВОВ, АДРЕСНЫХ КНИГ ИЛИ ЕЩЁ ЧЕГО-НИБУДЬ В ЭТОМ РОДЕxml является форматом для хранения произвольных данных - этого достаточно.
вот ты часто xml сравниваешь с файловой системой, давай воспользуемся твоей аналогией.
т.е. лучше бы было, если бы каждая программа напрямую хранила бы свои данные на винте без всякой файловой системы?
т.е. лучше бы было, если бы каждая программа напрямую хранила бы свои данные на винте без всякой файловой системы?
excel - его откроет, но не как двухмерную таблицуВот видишь?
А текстовый файл, в котором лежат данные в твоём формате - откроет блокнот, хотя тоже не как двухмерную таблицу.
да, xml не является форматом для описания двухмерных таблиц, адресных книг и т.д., но xml предоставляет базовый каркас для описания данных.
и соответственно свой формат данных удобнее навешивать на этот предоставленный каркас, чем пытаться разработать свой каркас для данных
и соответственно свой формат данных удобнее навешивать на этот предоставленный каркас, чем пытаться разработать свой каркас для данных
xml является форматом для хранения произвольных данных - этого достаточно.xml является форматом для хранения произвольных данных - точно так же, как и текстовый файл.
И само по себе использование xml и наличие/отсутствие где-нибудь XML-парсера ничего не говорят о возможности использования твоих файлов в других программах - как и само по себе использование текстовых файлов и наличие/отсутствие где-нибудь функций для работы с текстовыми файлами.
кстати времена; числа; символы, которые не влезают в кодировку, бинарные данные - ты как будешь хранить? изобретая свой велосипед?
если формат хранения стандартный.Что значит "стандартный"?
Я понимаю, "такой-то формат хранения адресной книги, который используется такой-то программой" - он может быть как-то стандартизирован. Но как стандартным может быть формат "XML-документ, в котором каким-то образом хранятся номера"? И чем он лучше формата "текстовый документ, в котором каким-то образом хранятся номера"?
одно дело - это когда данные лежат в каком-то непонятном своем бинарном или даже текстовом файле, другое дело - это sql-база или xmlЯ не вижу никакого различия между "каким-то непонятным своим текстовым файлом" и "каким-то непонятным своим xml-файлом".
В конце концов, тебе что, станет легче, если данные лежат вот в таком файле:
<?xml version="1.0"?>
<data><![CDATA[содерижмое_какого-то_непонятного_своего_бинарного_или_текстового_файла]]></data>
Как тебе помогло то, что это xml?
Как тебе помогло то, что это xml?это не есть хранение данных в xml, это есть запаковка своего текстового или бинарного представления в xml-конверт
вот ты часто xml сравниваешь с файловой системой, давай воспользуемся твоей аналогией.Я xml сравниваю с текстовыми файлами.
т.е. лучше бы было, если бы каждая программа напрямую хранила бы свои данные на винте без всякой файловой системы?Я не вижу никакой разницы между использованием какой-то самодельной файловой системы и прямым хранением данных на винте. Точнее, разницу вижу - но аргументом в пользу первого варианта не может служить "файловая система - это круто и универсально".
Универсальность появится, когда ты будешь использовать какую-то уже стандартизированную файловую систему. Например, хранение данных не напрямую на разделе, а в файлах, лежащих на разделе FAT32 - даёт универсальность. А хранение данных не напрямую на разделе, а в файлах, лежащих на разделе, отформатированном в самодельную ФС - никакой универсальности не даст.
xml предоставляет базовый каркас для описания данных..txt тоже предоставляет базовый каркас для описания данных.
А вот тут говорят, что неважно, запаковка или нет, главное, чтобы XML был - ведь XML-парсеры есть везде, а значит, такой файл откроет любая программа!
.txt тоже предоставляет базовый каркас для описания данных.да, представляет - так как описывает каким образом должен хранится символ и цепочка символов.
но xml предсталяет поверх этого каркаса еще один каркас более высокоуровневый - где уже описывается:
как декларируется кодировка файла,
как сохраняется одно значение,
как сохраняется значение в формате число, время, строка с расширенными символами, бинарные данные,
как сохраняются набор(дерево) значений.
соответственно при хранений своих данных все эти вопросы надо решать, соответственно мне не понятно, зачем для этого изобретать велосипед, если можно взять готовый работающий каркас.
ты же не придумываешь свой каркас (свою кодировку) для хранения текстовых данных? или придумываешь?
А вот тут говорят, что неважно, запаковка или нет, главное, чтобы XML был - ведь XML-парсеры есть везде, а значит, такой файл откроет любая программа!xml декларирует, что значение (например, телефонный номер ) должно сохраняться так: <tag>номер</tag> или так: tag="номер".
покажи где в твоем примере с xml-конвертом выполняется это требование?
[q]xml декларирует, что значение (например, телефонный номер ) должно сохраняться так: <tag>номер</tag> или так: tag="номер".[q]
То есть, xml декларирует, что нельзя записывать телефонный номер, как <phone country="7" city="926" number="1234567"/>
То есть, xml декларирует, что нельзя записывать телефонный номер, как <phone country="7" city="926" number="1234567"/>
ты же не придумываешь свой каркас (свою кодировку) для хранения текстовых данных?Я использую готовую кодировку (например, UCS-2).
А тут, по этой аналогии, говорят - "ты, главное, каждому символу сопоставь каким-нибудь образом число от 0 до 65535, и сохраняй каждый символ как два байта - тогда любая программа это прочитает, потому что везде есть библиотеки для работы с двубайтными кодировками". Я же, как раз, говорю, что использовать какую-то самодельную двубайтную кодировку саму по себе, из-за того, что два байта на символ - смысла нет, а есть смысл использовать конкретную существующую кодировку (и там уже относительно пофигу, сколько байт на символ).
То есть, xml декларирует, что нельзя записывать телефонный номер, как <phone country="7" city="926" number="1234567"/>можно, т.к. здесь ты уже оперируешь не телефонным номером, а здесь ты уже оперируешь телефонным номером как телефонный номер с кодом города и кодом страны.
Я же, как раз, говорю, что использовать какую-то самодельную двубайтную кодировку саму по себе, из-за того, что два байта на символ - смысла нет, а есть смысл использовать конкретную существующую кодировку (и там уже относительно пофигу, сколько байт на символ).ты как раз говоришь: надо использовать самодельную кодировку в которой как-то по своему сохраняется одно значение, вместо того, чтобы взять стандартную (xml).
ты самое главное пойми: xml - это стандарт о том, как хранится одно значение, которым оперирует программа.
также как стандарт о текстовых файлах - это стандарт о том, как хранится один символ и последовательность символов.
стандарт о текстовых файлах - формулирует, что один символ кодируется одним байтом или несколько (а не может, например, кодироваться половиной байта) и что символы хранятся последовательно.
ps
то, что csv был стандартом на хранение данных где-то дцать лет назад, не дает повод его использовать сегодня.
я самое главное не понял, ты сейчас споришь на тему xml vs csv, или на тему xml vs текстовые файлы?
Кажется, он спорит "против XML".
Все же, существует ли стандартная схема для хранения таблиц в XML ? Иначе его нельзя называть стандартным способом хранения таблиц, и он ничем не лучше csv --- любая отдельно взятая программа его либо прочитает, либо нет, причем скорее нет (для csv, ИМХО, скорее да).
Все же, существует ли стандартная схема для хранения таблиц в XML ? Иначе его нельзя называть стандартным способом хранения таблиц, и он ничем не лучше csv --- любая отдельно взятая программа его либо прочитает, либо нет, причем скорее нет (для csv, ИМХО, скорее да).
причем скорее нет
Просто потому, что способов предсталения табличных данных в нем - дохрена, а csv - один.
Все же, существует ли стандартная схема для хранения таблиц в XML ?такого понятия как таблица - не бывает (на логическом уровне).
есть понятие - матрица, есть понятие - коллекция однородных данных.
так ты сейчас о какой таблице ведешь речь?
Матрица, все же тред с них начинался.
Для матриц тогда уж лучше MathMl стоит брать - если мы конечно говорим о том, как сделать лучше и удобнее, а не о том, как сделать как-нибудь.
Кажется, он спорит "против XML".Я спорю против того, что сам по себе XML даст огромные преимущества - только от того, что ты используешь XML.
Все же, существует ли стандартная схема для хранения таблиц в XML ?Существует, например, формат Excel 2003 XML. Но тогда человеку надо говорить "храни данные в формате Excel 2003 XML, этот формат понимается много где" а не "храни данные в XML, XML-парсер есть везде".
ты сейчас споришь на тему xml vs csv, или на тему xml vs текстовые файлыЯ сейчас спорю на ту тему, что xml в данном контексте ничем не отличается от текстовых файлов, и что xml - это не формат хранения таблиц.
Есть много форматов хранения таблиц, какие-то основаны на xml, какие-то основаны на текстовых файлах - но это всё внизу. И использовать надо какой-то конкретный формат, а не любую только что придуманную хуйню - только потому, что она основана на xml, это совсем другой уровень.
Просто потому, что способов предсталения табличных данных в нем - дохрена, а csv - один.Ну как бы речь как раз о том, что способбов представления табличных данных как в xml, так и в текстовых файлах - дохрена, столько, сколько захочешь, и само по себе использование xml или текстовых файлов никакой совместимости не даст, даже глупо как-то в таком контексте говорить о совместимости - "я возьму XML-файл, в негокаким-то образом напихаю данные, и это будет хорошо и совместимо с другими программами, потому что XML-парсер есть везде"; что я пытаюсь сказать - что это ничем не отличается от "я возьму текстовый файл, в него каким-то образом напихаю данные, и это будет хорошо и совместимо с другими программами, потому что функции для работы с текстовыми файлами есть везде".
можно, т.к. здесь ты уже оперируешь не телефонным номером, а здесь ты уже оперируешь телефонным номером как телефонный номер с кодом города и кодом страны.Ну вот видишь? Кто-то будет хранить номер целиком, кто-то - код города и код страны отдельно, кто-то ещё и все эти коды будет хранить в шестнадцатеричной системе счисления... и какие преимущества тебе дало само по себе то, что это - XML?
> и какие преимущества тебе дало само по себе то, что это - XML?
тем, что я буду думать только о логической составляющей - как мне из кодов и внутреннего номера - получить полный номер телефона, а не о том, как мне из мешанины байтов получить(распарсить) коды и внутренний номер
тем, что я буду думать только о логической составляющей - как мне из кодов и внутреннего номера - получить полный номер телефона, а не о том, как мне из мешанины байтов получить(распарсить) коды и внутренний номер
В случае xml не придётся заботиться об экранировании текста.Народ, вы здесь ёбнулись совсем что ли?
зависит от библиотеки, конечно.
Вручную писать xml вряд ли кто будет
Вручную писать xml вряд ли кто будет
ну полно библиотек, которые могут заэкранировать текст без помощи любого xml
предварая следующее возражение: в xml более одного способа вставки произвольных данных с экранированием, так что о Единственно Верном Стандартном Способе речи не идёт в любом случае
предварая следующее возражение: в xml более одного способа вставки произвольных данных с экранированием, так что о Единственно Верном Стандартном Способе речи не идёт в любом случае
ну полно библиотек, которые могут заэкранировать текст без помощи любого xmlкак в cvs файле в кодировке 1251 заэкранировать греческий символ?
несколько способов есть
у меня другой вопрос - как в csv записать трехмерную таблицу и открыть ее в экселе?
несколько способов естьи чем это тогда лучше xml, экраны которого будут поняты в любом случае?
> экраны которого будут поняты в любом случае?
не в любом, а только в том, когда читатель догадается, какой вид экранирования использован
не в любом, а только в том, когда читатель догадается, какой вид экранирования использован
не в любом, а только в том, когда читатель догадается, какой вид экранирования использовансудя по существительному "читатель", предполагается, что читает человек. Мне сложно представить, зачем человеку нужно давать читать двумерные массивы текста. Это нужно скорее для передачи данных, чем для конечного вывода. А парсер xml уж должен догадаться, что к чему.
cудя по существительному "читатель", предполагается, что читает человекА XmlReader - это тоже человек? Видимо, сотрудник MS
у XmlReader какие-то проблемы с экранами?
Это у тебя проблема, раз думаешь, что читатель - человек.
А у него никаких проблем. Будет многострочный текст такой:
Парсер его съест? Да. Хватит этого, чтоб правильно восстановить текст? Нет.
А у него никаких проблем. Будет многострочный текст такой:
<text:p text:style-name="Table_20_Contents">Тест3</text:p><text:p text:style-name="Table_20_Contents"><text:s/>Тест4</text:p>
Парсер его съест? Да. Хватит этого, чтоб правильно восстановить текст? Нет.
какие-то странные экраны. Что их генерирует?
Это ODF
Оставить комментарий
djhunter
Не бейте сильно.... Как записать двумерный массив N*M в файл текстовый подскажите пожалуйста) я безусловно долго читал хелп , всякого напробовал и что-то ничего не вышло у меня Цикл записи я соображу, подскажите только последовательность вызова всей этой мути для создания текст-файла, добавленя, переноса на новую строчку. А то у меня мягко говоря не пишет.