0002107: sml файлы не по стандарту XML

Notes
(0012568) vdemidov (manager) 22-08-2013 19:04	Ну, строго говоря, там не обязательно "windows-1251", там та кодировка, которая установлена у вас для неюникодных программ.

(0014208) sheavy (reporter) 03-05-2014 18:20	Поддерживаю этот пост! Экспериментирую с импортом sml в MS SQL. Без encoding="windows-1251" возникают сложности. Не могу это обойти. Было бы здорово указать кодировку. Спасибо.

(0014209) vdemidov (manager) 05-05-2014 07:03	Если вас интересует решение этой проблемы, то жду пул-реквеста с исправлениями. Иначе в ближайшее время можете особо не рассчитывать.

(0014233) sheavy (reporter) 14-05-2014 07:07	Хорошо, попробую организовать. Был бы признателен если бы кто-то дал направление, куда копать. Какой модуль или библиотека за это отвечает.

(0014234) vdemidov (manager) 14-05-2014 07:35	u_MarkDbSml.pas и u_MarkCategoryDBSml.pas

(0014235) zed (manager) 14-05-2014 10:41 edited on: 14-05-2014 10:43	А самое интересное, что у нас указана кодировка и для меток и для категорий и она UTF-8. Но подозреваю, что строки записываются в Ansi. Хотя, почему строка с кодировкой пропадает из sml файлов остаётся загадкой. Вот ещё в тему меток и юникода: http://sasgis.org/forum/viewtopic.php?f=47&t=2348

(0014236) Fed (reporter) 14-05-2014 13:57 edited on: 15-05-2014 06:02	Файлы marks.sml и Categorymarks.sml имеет формат Generic XML. Как я понимаю в u_MarkCategoryDBSml.pas procedure TMarkCategoryDBSml.InitEmptyDS; а в u_MarkDbSml.pas procedure TMarkDbSml.InitEmptyDS(ACdsMarks: TClientDataSet); *они не влияют на запись .sml файлов**, а только инициализируют структуру данных в TClientDataSet.

(0015279) zed (manager) 19-02-2015 05:25	Я думаю, этот тикет можно закрывать как "won't fix" - изменить стандартное поведение компонента (TDataSet), который пишет метки в sml, не представляется возможным, а городить свой велосипед с ручным парсингом xml в SAS я думаю не стоит. Кому надо открыть метки в сторонней программе, могут без проблем добавить руками эту строку с кодировкой.

(0015280) Fed (reporter) 19-02-2015 05:48	Не удобно постоянно руками добавлять эту строку с кодировкой, особенно когда нужно эти данные получать автоматически. Хорошо бы решить эту проблему, но вот как?

(0015281) vdemidov (manager) 19-02-2015 07:43	Ну, единственное правильное решение - заставить TClientDataSet сохранять строки в UTF-8, но как этого добиться я не знаю. Писать encoding="windows-1251" нельзя, так как там не обязательно "windows-1251", а любая, которая сейчас указана дефолтной в системе.

(0015283) vasketsov (manager) 19-02-2015 08:20 edited on: 19-02-2015 08:26	>как этого добиться я не знаю Его надо отнаследовать, и использовать WriteDataPacket. TDataPacketFormat = (dfBinary, dfXML, dfXMLUTF8); Либо отнаследовать и продублировать код GetXMLData через DSBase с флагом xmlUTF8 вместо xmlON.

(0015285) Fed (reporter) 19-02-2015 10:36	Согласен с vasketsov.

(0015286) zed (manager) 19-02-2015 10:42 edited on: 19-02-2015 10:44	Если перейти на юникод (dfXMLUTF8), то может поломаться обратная совместимость. К тому же, для неюникодной версии SAS, переход меток на юникод не принесёт ничего, кроме падения быстродействия (WideString-и и всё такое) и увеличения размера (в байтах) sml-файлов.

(0015287) vdemidov (manager) 19-02-2015 11:05	Может поломаться, а может и нет - я не проверял. А по поводу скорости, это скорее повод побыстрее перейти на юникодную версию.

(0015288) vasketsov (manager) 19-02-2015 11:15	>может поломаться обратная совместимость Я могу это попробовать сделать у себя, но только если вы это точно делать не будете. Я полную обратную совместимость для SML и не обещал. Впрочем, можно же такое (dfXMLUTF8) сделать только для экспорта меток, а саму базу меток не трогать. У вас есть флаг или какой признак, экспорт это или нет? В общем, подумайте.

(0015289) zed (manager) 19-02-2015 11:16 edited on: 19-02-2015 11:22	Поломать может. У себя я один раз словил глюк когда экспериментировал с форматами (dfBinary, dfXML, dfXMLUTF8), но глубоко рыть не стал. Поэтому придерживаюсь мнения, что если и переходить на юникод, то нужно менять расширение файла, чтобы не миксовать их и не потерять все метки, открывая их попеременно в разных версиях программы. Если бы в коде был механизм множественности типов баз меток (как это сделано с тайло-хранилищами), то ввести расширенный sml (какой-нибудь smlx) - дело пяти минут (поменять одну константу с False на True): в коде я уже всё подготовил к переходу на юникод (комментарий по коду "ToDo" относится к выносу в конфиг этих параметров, чтобы юзер мог управлять ими из настроек программы).

(0015290) vdemidov (manager) 19-02-2015 11:24	> Если бы в коде был механизм множественности типов баз меток (как это сделано с тайло-хранилищами), то ввести расширенный sml (какой-нибудь smlx) - дело пяти минут Ну так сделай его. Там один шаг остался для его реализации.

(0015291) zed (manager) 19-02-2015 11:31	Начнём с того, что я предлагаю закрыть тикет как won't fix и не париться :) На текущий момент юникод в метка бесполезен и местами даже вреден. Нужен он только загадочным внешним автоматизаторам, которые не в силах в текстовом файле заменить одну строку на другую (на самом деле - 5 строчек в скрипте), перед началом своих действий.

(0015292) vdemidov (manager) 19-02-2015 11:33	Ну, а я считаю, что переход на юникод все-таки нужен, поэтому пусть пока живет.

(0015306) zed (manager) 20-02-2015 19:32	Странная штука этот датасет - флаг dfXMLUTF8 позволяет писать на диск файл в utf-8 кодировке, но в то же время, не даёт возможности по-настоящему работать с юникодом. В общем, включил я этот флаг и теперь sml будет сохраняться по всем канонам xml. На внутреннюю работу меток это никак не повлияет - они как были неюникодными, так и останутся (даже при переходе на XE2), т.е. никакого падения производительности и прочих проблем быть не должно. С обратной совместимостью по всей видимости тоже всё ОК, старые версии SAS без проблем понимают "новый" sml, как и свежая версия открывает старые sml. Похоже, этот тикет можно было закрыть ещё полтора года назад, если бы кто вплотную этим вопросом занялся и разобрался с нюансами работы датасетов.

(0015308) vdemidov (manager) 21-02-2015 09:42	>Похоже, этот тикет можно было закрыть ещё полтора года назад, если бы кто вплотную этим вопросом занялся и разобрался с нюансами работы датасетов. Ну да. Тут таких тикетов дофига.

Users who viewed this issue
User List	Anonymous (4182x), Alezy80 (1x), Fed (114x), sheavy (1x), Tolik (1x), vdemidov (5x), zed (2x)
Total Views	4306
Last View	19-04-2024 16:09

Issue History
Date Modified	Username	Field	Change
22-08-2013 18:36	Snake	New Issue
22-08-2013 19:04	vdemidov	Note Added: 0012568
22-08-2013 19:20	vdemidov	Status	new => confirmed
22-08-2013 19:20	vdemidov	Product Version	.Nightly => 120808
22-08-2013 19:20	vdemidov	Target Version	=> 29xxxx
03-05-2014 18:20	sheavy	Note Added: 0014208
05-05-2014 07:03	vdemidov	Note Added: 0014209
14-05-2014 07:07	sheavy	Note Added: 0014233
14-05-2014 07:35	vdemidov	Note Added: 0014234
14-05-2014 10:41	zed	Note Added: 0014235
14-05-2014 10:43	zed	Note Edited: 0014235	View Revisions
14-05-2014 13:57	Fed	Note Added: 0014236
15-05-2014 05:59	Fed	Note Edited: 0014236	View Revisions
15-05-2014 06:02	Fed	Note Edited: 0014236	View Revisions
19-02-2015 05:16	zed	Relationship added	has duplicate 0002633
19-02-2015 05:25	zed	Note Added: 0015279
19-02-2015 05:28	zed	Relationship added	parent of 0001217
19-02-2015 05:35	zed	Severity	trivial => tweak
19-02-2015 05:48	Fed	Note Added: 0015280
19-02-2015 07:43	vdemidov	Note Added: 0015281
19-02-2015 08:20	vasketsov	Note Added: 0015283
19-02-2015 08:26	vasketsov	Note Edited: 0015283	View Revisions
19-02-2015 08:57	vdemidov	Description Updated	View Revisions
19-02-2015 08:57	vdemidov	Additional Information Updated	View Revisions
19-02-2015 10:36	Fed	Note Added: 0015285
19-02-2015 10:42	zed	Note Added: 0015286
19-02-2015 10:44	zed	Note Edited: 0015286	View Revisions
19-02-2015 11:05	vdemidov	Note Added: 0015287
19-02-2015 11:15	vasketsov	Note Added: 0015288
19-02-2015 11:16	zed	Note Added: 0015289
19-02-2015 11:22	zed	Note Edited: 0015289	View Revisions
19-02-2015 11:24	vdemidov	Note Added: 0015290
19-02-2015 11:31	zed	Note Added: 0015291
19-02-2015 11:33	vdemidov	Note Added: 0015292
19-02-2015 11:38	vdemidov	Relationship added	related to 0002166
20-02-2015 19:32	zed	Note Added: 0015306
20-02-2015 19:34	zed	Status	confirmed => resolved
20-02-2015 19:34	zed	Fixed in Version	=> 150915
20-02-2015 19:34	zed	Resolution	open => fixed
20-02-2015 19:34	zed	Assigned To	=> zed
20-02-2015 19:35	zed	Target Version	29xxxx => 150915
21-02-2015 09:42	vdemidov	Note Added: 0015308
12-11-2015 14:27	vdemidov	Relationship added	related to 0002901

SASGIS