Развитие экспорта/импорта

Вам не хватает чего-то в Far? Вы считаете, что вашу идею стоит услышать? Пишите сюда.
Shmuel
Posts: 5860
Joined: Thu 23 Mar, 2006 21:36
Location: Israel
Has thanked: 22 times
Been thanked: 215 times

Развитие экспорта/импорта

Post by Shmuel » Fri 15 Feb, 2019 22:23

Latest post of the previous page:

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

User avatar
DrKnS
Posts: 5364
Joined: Thu 04 Aug, 2005 06:44
Location: Kyiv
Has thanked: 6 times
Been thanked: 219 times

Развитие экспорта/импорта

Post by DrKnS » Fri 15 Feb, 2019 22:39

Far, в принципе, тоже можно допилить: экспорт блобов как "XX,XX,XX,XX..." - это дикий троекратный оверхед.
У Base64, например, оверхед всего 33%, формат стандартный и декодируется чем угодно, в отличие от.

ccaid
Posts: 846
Joined: Fri 12 Jun, 2009 16:04
Has thanked: 17 times
Been thanked: 5 times

Развитие экспорта/импорта

Post by ccaid » Sat 16 Feb, 2019 09:38

DrKnS, если допилить в смысле: заменить на base64, то это шило на мыло, выигрыш только в оверхеде, но не в понятности. а для декодирования чем угодно, все равно требуется ручная работа с каждой строкой: выделить, скопировать, вставить, нажать. если процесс автоматизировать, то это уже не чем угодно, а специально написанным скриптом. а скрипт автоматизации можно написать и для существующего варианта.
Фар делают добрые люди

User avatar
DrKnS
Posts: 5364
Joined: Thu 04 Aug, 2005 06:44
Location: Kyiv
Has thanked: 6 times
Been thanked: 219 times

Развитие экспорта/импорта

Post by DrKnS » Sat 16 Feb, 2019 10:27

ccaid, я, действительно, не понимаю, чего вы хотите.
В xml нельзя хранить бинарные данные в сыром виде. Их в любом случае надо кодировать.
Вы хотите, чтобы Far каждый раз обнюхивал блоб, и, если там по счастливой случайности нет несовместимых с xml символов, сохранял его как текст?
Вашему случаю это всё равно не поможет - вы там выше жаловались, что плагин лепит всё в одну строку с \n вместо переводов строки, так здесь будет еще хуже - 
 или 
, потому что если не эскейпить - парсер их нормализует, а мы не знаем и не можем знать, можно нормализовать в конкретно этом случае или от этого всё загорится и взорвётся, потому что это бинарные данные.

ccaid
Posts: 846
Joined: Fri 12 Jun, 2009 16:04
Has thanked: 17 times
Been thanked: 5 times

Развитие экспорта/импорта

Post by ccaid » Sat 16 Feb, 2019 10:56

DrKnS, в тех случаях, о которых я говорю, в блобе по факту находится текст. и, да, я бы хотел, чтобы он сохранялся как текст, с переводами строк. это желание конечного пользователя, без привязки к техническим проблемами и способам их решения. то есть в мои намерения не входит настаивать на технически-неверном решении. я хочу, чтобы был найден вариант, который был бы и корректен (для xml), и решал задачу показа текста.
в xml из дистриба colorer я видел конструкцию из строк, заключенных в квадратные скобки. не поможет ли в обсуждаемом случае эта конструкция?
Фар делают добрые люди

User avatar
DrKnS
Posts: 5364
Joined: Thu 04 Aug, 2005 06:44
Location: Kyiv
Has thanked: 6 times
Been thanked: 219 times

Развитие экспорта/импорта

Post by DrKnS » Sat 16 Feb, 2019 11:03

Если вы про <!CDATA[[...]]>, то это просто такой вычурный способ не экранировать "<", ">" и "&" (за счет экранирования "]]>"), для бинарных данных это не предназначено.

ccaid
Posts: 846
Joined: Fri 12 Jun, 2009 16:04
Has thanked: 17 times
Been thanked: 5 times

Развитие экспорта/импорта

Post by ccaid » Sun 17 Feb, 2019 07:39

я про это:
catalog.xml wrote:<?xml version="1.0" encoding='UTF-8'?>
<!DOCTYPE catalog PUBLIC "-//Cail Lomecb//DTD Colorer CATALOG take5//EN"
"http://colorer.sf.net/2003/catalog.dtd"[

<!ENTITY hrc "hrc">
<!ENTITY hrd "hrd">

<!ENTITY catalog-console SYSTEM "hrd/catalog-console.xml">
<!ENTITY catalog-rgb SYSTEM "hrd/catalog-rgb.xml">
<!ENTITY catalog-text SYSTEM "hrd/catalog-text.xml">

]>
внутри тега многострочная вставка
Фар делают добрые люди

User avatar
DrKnS
Posts: 5364
Joined: Thu 04 Aug, 2005 06:44
Location: Kyiv
Has thanked: 6 times
Been thanked: 219 times

Развитие экспорта/импорта

Post by DrKnS » Sun 17 Feb, 2019 12:03

ccaid wrote:
Sun 17 Feb, 2019 07:39
внутри тега многострочная вставка
DrKnS wrote:
Sat 16 Feb, 2019 10:27
если не эскейпить - парсер их нормализует, а мы не знаем и не можем знать, можно нормализовать в конкретно этом случае или от этого всё загорится и взорвётся, потому что это бинарные данные

ccaid
Posts: 846
Joined: Fri 12 Jun, 2009 16:04
Has thanked: 17 times
Been thanked: 5 times

Развитие экспорта/импорта

Post by ccaid » Sun 17 Feb, 2019 12:46

ccaid wrote:
Sat 16 Feb, 2019 10:56
в тех случаях, о которых я говорю, в блобе по факту находится текст
Фар делают добрые люди

User avatar
DrKnS
Posts: 5364
Joined: Thu 04 Aug, 2005 06:44
Location: Kyiv
Has thanked: 6 times
Been thanked: 219 times

Развитие экспорта/импорта

Post by DrKnS » Sun 17 Feb, 2019 13:02

ccaid wrote:
Sun 17 Feb, 2019 12:46
по факту
Есть два блоба, в одном "по факту текст", в другом честный сериализованный объект.
Символы \r и \n есть и там и там. Символов \0, позволяющих утверждать "это не текст", нет ни там ни там.
XML нормализует \r\n в \n и \r в \n.
Если сделать это в "по факту тексте" - ничего страшного не произойдет.
Если сделать это в блобе - плагин или фар десериализует блоб неправильно, управление пойдет не туда и либо свалится с access violation, либо отформатирует вам диск.
Какой на строки разобъете, какой так оставите?

ccaid
Posts: 846
Joined: Fri 12 Jun, 2009 16:04
Has thanked: 17 times
Been thanked: 5 times

Развитие экспорта/импорта

Post by ccaid » Sun 17 Feb, 2019 14:28

в тексте не может быть управляющих символов: 0-31, может еще каких — за исключением комбинации \r\n.
в том числе, не может быть одиночных символов \r, \n — источник текста (Lua-плагин или скрипт) будет порождать только \r\n.
текстовые блобы возможны только в ветке <pluginsconfig>.
как совсем крайний случай, может быть белый список плагинов, где есть текстовые блобы. но это крайне, крайне нежелательно.
можно придумать и ввести какой-то признак для узнавания текстовых блобов (в теге, в блобе, ...). это решение должно опираться на какие-то технические, реализационные нюансы, поэтому конкретные подходящие варианты решений я не смогу предложить. распознавание будет 100%, но минус: теряется совместимость с прежними версиями, требуется обновление Lua-плагинов.
юзер-драйвен решение: рядом с ключом блоба создается ключ с именем блоба плюс какой-то предопределенный постфикс. но я не знаю, как отнесется плагин к левому ключу в своей ветке настроек.
Фар делают добрые люди

Shmuel
Posts: 5860
Joined: Thu 23 Mar, 2006 21:36
Location: Israel
Has thanked: 22 times
Been thanked: 215 times

Развитие экспорта/импорта

Post by Shmuel » Sun 17 Feb, 2019 17:01

ccaid wrote:
Sun 17 Feb, 2019 14:28
не может быть одиночных символов \r, \n — источник текста (Lua-плагин или скрипт) будет порождать только \r\n.
Все LuaFAR-плагины у меня (включая LuaMacro) и скрипты пишут в базу данных только одиночные \n (hex 0A).

ccaid
Posts: 846
Joined: Fri 12 Jun, 2009 16:04
Has thanked: 17 times
Been thanked: 5 times

Развитие экспорта/импорта

Post by ccaid » Sun 17 Feb, 2019 17:08

Shmuel wrote:
Sun 17 Feb, 2019 17:01
только одиночные \n (hex 0A)
значит только \n разрешены для текста
Фар делают добрые люди

Shmuel
Posts: 5860
Joined: Thu 23 Mar, 2006 21:36
Location: Israel
Has thanked: 22 times
Been thanked: 215 times

Развитие экспорта/импорта

Post by Shmuel » Sun 17 Feb, 2019 17:15

ccaid, ваша настойчивость заслуживает уважения, но... я убеждён в том, что Фар не должен при экспорте заниматься анализом содержимого, а напротив - строго экспортировать в указанном при сохранении данных формате.
На этом моё участие в данной ветке исчерпано.

Post Reply

Return to “Предложения и идеи”