|
Notes |
|
|
|
|
Ну, строго говоря, там не обязательно "windows-1251", там та кодировка, которая установлена у вас для неюникодных программ. |
|
|
|
(0014208)
|
|
sheavy
|
|
03-05-2014 18:20
|
|
Поддерживаю этот пост! Экспериментирую с импортом sml в MS SQL. Без encoding="windows-1251" возникают сложности. Не могу это обойти.
Было бы здорово указать кодировку. Спасибо. |
|
|
|
|
|
Если вас интересует решение этой проблемы, то жду пул-реквеста с исправлениями. Иначе в ближайшее время можете особо не рассчитывать. |
|
|
|
(0014233)
|
|
sheavy
|
|
14-05-2014 07:07
|
|
|
Хорошо, попробую организовать. Был бы признателен если бы кто-то дал направление, куда копать. Какой модуль или библиотека за это отвечает. |
|
|
|
|
|
u_MarkDbSml.pas и u_MarkCategoryDBSml.pas |
|
|
|
(0014235)
|
|
zed
|
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
|
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
|
|
19-02-2015 05:25
|
|
|
Я думаю, этот тикет можно закрывать как "won't fix" - изменить стандартное поведение компонента (TDataSet), который пишет метки в sml, не представляется возможным, а городить свой велосипед с ручным парсингом xml в SAS я думаю не стоит. Кому надо открыть метки в сторонней программе, могут без проблем добавить руками эту строку с кодировкой. |
|
|
|
(0015280)
|
|
Fed
|
|
19-02-2015 05:48
|
|
Не удобно постоянно руками добавлять эту строку с кодировкой, особенно когда нужно эти данные получать автоматически.
Хорошо бы решить эту проблему, но вот как? |
|
|
|
|
|
Ну, единственное правильное решение - заставить TClientDataSet сохранять строки в UTF-8, но как этого добиться я не знаю. Писать encoding="windows-1251" нельзя, так как там не обязательно "windows-1251", а любая, которая сейчас указана дефолтной в системе. |
|
|
|
(0015283)
|
|
vasketsov
|
19-02-2015 08:20
(edited on: 19-02-2015 08:26) |
|
>как этого добиться я не знаю
Его надо отнаследовать, и использовать WriteDataPacket.
TDataPacketFormat = (dfBinary, dfXML, dfXMLUTF8);
Либо отнаследовать и продублировать код GetXMLData через DSBase с флагом xmlUTF8 вместо xmlON.
|
|
|
|
(0015285)
|
|
Fed
|
|
19-02-2015 10:36
|
|
|
|
|
(0015286)
|
|
zed
|
19-02-2015 10:42
(edited on: 19-02-2015 10:44) |
|
Если перейти на юникод (dfXMLUTF8), то может поломаться обратная совместимость. К тому же, для неюникодной версии SAS, переход меток на юникод не принесёт ничего, кроме падения быстродействия (WideString-и и всё такое) и увеличения размера (в байтах) sml-файлов.
|
|
|
|
|
|
Может поломаться, а может и нет - я не проверял. А по поводу скорости, это скорее повод побыстрее перейти на юникодную версию. |
|
|
|
|
>может поломаться обратная совместимость
Я могу это попробовать сделать у себя, но только если вы это точно делать не будете. Я полную обратную совместимость для SML и не обещал.
Впрочем, можно же такое (dfXMLUTF8) сделать только для экспорта меток, а саму базу меток не трогать. У вас есть флаг или какой признак, экспорт это или нет?
В общем, подумайте. |
|
|
|
(0015289)
|
|
zed
|
19-02-2015 11:16
(edited on: 19-02-2015 11:22) |
|
Поломать может. У себя я один раз словил глюк когда экспериментировал с форматами (dfBinary, dfXML, dfXMLUTF8), но глубоко рыть не стал. Поэтому придерживаюсь мнения, что если и переходить на юникод, то нужно менять расширение файла, чтобы не миксовать их и не потерять все метки, открывая их попеременно в разных версиях программы.
Если бы в коде был механизм множественности типов баз меток (как это сделано с тайло-хранилищами), то ввести расширенный sml (какой-нибудь smlx) - дело пяти минут (поменять одну константу с False на True): в коде я уже всё подготовил к переходу на юникод (комментарий по коду "ToDo" относится к выносу в конфиг этих параметров, чтобы юзер мог управлять ими из настроек программы).
|
|
|
|
|
> Если бы в коде был механизм множественности типов баз меток (как это сделано с тайло-хранилищами), то ввести расширенный sml (какой-нибудь smlx) - дело пяти минут
Ну так сделай его. Там один шаг остался для его реализации. |
|
|
|
(0015291)
|
|
zed
|
|
19-02-2015 11:31
|
|
Начнём с того, что я предлагаю закрыть тикет как won't fix и не париться :)
На текущий момент юникод в метка бесполезен и местами даже вреден. Нужен он только загадочным внешним автоматизаторам, которые не в силах в текстовом файле заменить одну строку на другую (на самом деле - 5 строчек в скрипте), перед началом своих действий. |
|
|
|
|
|
Ну, а я считаю, что переход на юникод все-таки нужен, поэтому пусть пока живет. |
|
|
|
(0015306)
|
|
zed
|
|
20-02-2015 19:32
|
|
Странная штука этот датасет - флаг dfXMLUTF8 позволяет писать на диск файл в utf-8 кодировке, но в то же время, не даёт возможности по-настоящему работать с юникодом.
В общем, включил я этот флаг и теперь sml будет сохраняться по всем канонам xml. На внутреннюю работу меток это никак не повлияет - они как были неюникодными, так и останутся (даже при переходе на XE2), т.е. никакого падения производительности и прочих проблем быть не должно. С обратной совместимостью по всей видимости тоже всё ОК, старые версии SAS без проблем понимают "новый" sml, как и свежая версия открывает старые sml.
Похоже, этот тикет можно было закрыть ещё полтора года назад, если бы кто вплотную этим вопросом занялся и разобрался с нюансами работы датасетов. |
|
|
|
|
>Похоже, этот тикет можно было закрыть ещё полтора года назад, если бы кто
вплотную этим вопросом занялся и разобрался с нюансами работы датасетов.
Ну да. Тут таких тикетов дофига. |
|