|
ПостроительDOM при чтении преобразовывает CDATA в Текст | ☑ | ||
---|---|---|---|---|
0
vadymdymdym
07.05.15
✎
20:33
|
Привет всем. Встретился с проблемой. При чтении объекта ЧтениеXML при помощи объекта ПостроительDOM узел типа СекцияCDATA преобразовываются в узел типа Текст. Можно ли этого избежать? В самом же объекте ЧтениеXML - да можно. При его создании указываются т.н. параметры XML, в которых один из параметров - это СекцииCDATAКакТекст. Если значение этого параметра равно Ложь - данные секции читаются как нужно. Что делать с объектом ПостроительDOM?
|
|||
1
DrShad
07.05.15
✎
20:39
|
А чем текстовые узлы не подходят?
|
|||
2
vadymdymdym
07.05.15
✎
20:53
|
(1) Тем, что мне необходимо считать данные XML, затем изменить то, что мне нужно, а затем снова их сохранить. А при сохранении перетирает все эти секции
|
|||
3
Лефмихалыч
07.05.15
✎
21:53
|
чует моя чуйка, что вариантов нет. Доказать не могу
|
|||
4
ДенисЧ
07.05.15
✎
22:02
|
(2) Придётся смириться.
Если не умеет объект - значит, не используй его. |
|||
5
DrShad
07.05.15
✎
22:18
|
Виндовым парсером читай, он точно умеет
|
|||
6
Zhuravlik
07.05.15
✎
22:34
|
(0) DOM можно превратить в дерево значений (затратно), затем обойти файл еще раз, используя чтение XML, и дополнить дерево нужной информацией.
|
|||
7
Zhuravlik
07.05.15
✎
22:36
|
+ кстати, если запись реализуется с XDTO - очень удобно пользоваться таким деревом, как источником данных.
|
|||
8
vadymdymdym
07.05.15
✎
22:55
|
(5) А вот это идея. Наверное придется. Просто думал, может все-таки ДокументDOM может))
(6) Тоже вариант, но не хочется. Ибо, слишком громоздко. С таки же успехом можно и при помощи ЧтенияXML сделать обход и построить дерево (7) Не, с XDTO там никак)) Всем спасибо за варианты. |
|||
9
Лефмихалыч
07.05.15
✎
23:27
|
(6) проще читать последовательно и последовательно же записывать, подменяя на лету то, что надо заменить. Накладных затрат меньши на пару порядков
|
|||
10
vadymdymdym
08.05.15
✎
00:10
|
(9) Да тоже громоздко. Особенно когда документ содержит разные типы узлов с разными уровнями вложенности. Помог DrShad. Виндовый парсер рулит
|
|||
11
DrShad
08.05.15
✎
00:26
|
(8) ну так в виндовом тот же DOM только импортный
|
|||
12
vadymdymdym
08.05.15
✎
00:33
|
(11) Ну... по сути - да))
|
|||
13
Garykom
гуру
08.05.15
✎
00:40
|
нафехуа вам DOM? юзайте SAX и будет Вам счастье...
|
|||
14
DrShad
08.05.15
✎
00:55
|
Dom тяжелее, только хардкор
|
|||
15
vadymdymdym
08.05.15
✎
01:14
|
(13) Ну... я конечно не силен в этом, но ... насколько я понимаю SAX - это последовательный доступ к документу. Т.е. по сути - это те же объекты ЧтениеXML и ЗаписьXML в 1С-ке, что не приемлимо в силу громоздкости. Ежели поделитесь примером использования SAX в 1С-ке - буду Вам очень признателен))
|
|||
16
Garykom
гуру
08.05.15
✎
01:42
|
||||
17
vadymdymdym
08.05.15
✎
08:04
|
(16) Спасибо, кэп))). Это мы проходили)). Я думал, я увижу что-то вроде решения моей задачи)). А в моем случае что предлагаете?)) Воспользоваться советом Лефмихалыча с последовательным чтением и записью? Да нет уж. Много букв в коде будет. Не осилю))). А если серьезно - очень много геморроя будет. Ради одной замены в файле будет пройден цикл обработки чтения, распознавания узлов, создания таких же узлов... Зачем если все решается двумя строками selectNodes и element.text="Мое значение"))
|
|||
18
Fragster
гуру
08.05.15
✎
08:18
|
у меня наоборот - превращает большие (больше нескольких сотни примерно символов) строки в cdata. Наверное какие-нибудь опции записи могут на это повлиять. Но чисто визуально на другой стороне это никак не влияет на то, как там этот XML потом разбирается.
|
|||
19
vadymdymdym
08.05.15
✎
09:11
|
(18) А вот об этом я не подумал, кстати. Действительно, если парсер здесь воспринимает эти узлы одинаково, то и на той стороне сервак может поступить также. Попробую, отпишусь))
|
|||
20
Garykom
гуру
08.05.15
✎
15:20
|
(17) задачка: файлик xml распакованный скажем 500 мегабайт, сколько нужно оперативки на компе чтобы сделать DOM ?
|
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |