Latest post of the previous page:
а что вообще за ересь здесь происходит? настройку можно сохранить в бинарном виде и там будет не обязательно строка, можно в виде строки. это разные вещи. и на уровне фара интерпретировать бинарные данные как строку — это какой-то бред.Развитие экспорта/импорта
-
- Posts: 6834
- Joined: Thu 23 Mar, 2006 21:36
- Location: Israel
- Has thanked: 41 times
- Been thanked: 530 times
Развитие экспорта/импорта
ccaid, поскольку эта проблема (условно скажем так) наблюдается именно в моих плагинах, посмотрю, что можно сделать.
Со свободным временем сейчас не очень, поэтому может быть не скоро.
Со свободным временем сейчас не очень, поэтому может быть не скоро.
- DrKnS
- Posts: 6114
- Joined: Thu 04 Aug, 2005 06:44
- Location: Kyiv
- Has thanked: 12 times
- Been thanked: 426 times
Развитие экспорта/импорта
Far, в принципе, тоже можно допилить: экспорт блобов как "XX,XX,XX,XX..." - это дикий троекратный оверхед.
У Base64, например, оверхед всего 33%, формат стандартный и декодируется чем угодно, в отличие от.
У Base64, например, оверхед всего 33%, формат стандартный и декодируется чем угодно, в отличие от.
Развитие экспорта/импорта
DrKnS, если допилить в смысле: заменить на base64, то это шило на мыло, выигрыш только в оверхеде, но не в понятности. а для декодирования чем угодно, все равно требуется ручная работа с каждой строкой: выделить, скопировать, вставить, нажать. если процесс автоматизировать, то это уже не чем угодно, а специально написанным скриптом. а скрипт автоматизации можно написать и для существующего варианта.
Фар делают добрые люди
- DrKnS
- Posts: 6114
- Joined: Thu 04 Aug, 2005 06:44
- Location: Kyiv
- Has thanked: 12 times
- Been thanked: 426 times
Развитие экспорта/импорта
ccaid, я, действительно, не понимаю, чего вы хотите.
В xml нельзя хранить бинарные данные в сыром виде. Их в любом случае надо кодировать.
Вы хотите, чтобы Far каждый раз обнюхивал блоб, и, если там по счастливой случайности нет несовместимых с xml символов, сохранял его как текст?
Вашему случаю это всё равно не поможет - вы там выше жаловались, что плагин лепит всё в одну строку с \n вместо переводов строки, так здесь будет еще хуже - 
 или 
, потому что если не эскейпить - парсер их нормализует, а мы не знаем и не можем знать, можно нормализовать в конкретно этом случае или от этого всё загорится и взорвётся, потому что это бинарные данные.
В xml нельзя хранить бинарные данные в сыром виде. Их в любом случае надо кодировать.
Вы хотите, чтобы Far каждый раз обнюхивал блоб, и, если там по счастливой случайности нет несовместимых с xml символов, сохранял его как текст?
Вашему случаю это всё равно не поможет - вы там выше жаловались, что плагин лепит всё в одну строку с \n вместо переводов строки, так здесь будет еще хуже - 
 или 
, потому что если не эскейпить - парсер их нормализует, а мы не знаем и не можем знать, можно нормализовать в конкретно этом случае или от этого всё загорится и взорвётся, потому что это бинарные данные.
Развитие экспорта/импорта
DrKnS, в тех случаях, о которых я говорю, в блобе по факту находится текст. и, да, я бы хотел, чтобы он сохранялся как текст, с переводами строк. это желание конечного пользователя, без привязки к техническим проблемами и способам их решения. то есть в мои намерения не входит настаивать на технически-неверном решении. я хочу, чтобы был найден вариант, который был бы и корректен (для xml), и решал задачу показа текста.
в xml из дистриба colorer я видел конструкцию из строк, заключенных в квадратные скобки. не поможет ли в обсуждаемом случае эта конструкция?
в xml из дистриба colorer я видел конструкцию из строк, заключенных в квадратные скобки. не поможет ли в обсуждаемом случае эта конструкция?
Фар делают добрые люди
- DrKnS
- Posts: 6114
- Joined: Thu 04 Aug, 2005 06:44
- Location: Kyiv
- Has thanked: 12 times
- Been thanked: 426 times
Развитие экспорта/импорта
Если вы про <!CDATA[[...]]>, то это просто такой вычурный способ не экранировать "<", ">" и "&" (за счет экранирования "]]>"), для бинарных данных это не предназначено.
Развитие экспорта/импорта
я про это:
внутри тега многострочная вставка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">
]>
Фар делают добрые люди
- DrKnS
- Posts: 6114
- Joined: Thu 04 Aug, 2005 06:44
- Location: Kyiv
- Has thanked: 12 times
- Been thanked: 426 times
Развитие экспорта/импорта
Есть два блоба, в одном "по факту текст", в другом честный сериализованный объект.
Символы \r и \n есть и там и там. Символов \0, позволяющих утверждать "это не текст", нет ни там ни там.
XML нормализует \r\n в \n и \r в \n.
Если сделать это в "по факту тексте" - ничего страшного не произойдет.
Если сделать это в блобе - плагин или фар десериализует блоб неправильно, управление пойдет не туда и либо свалится с access violation, либо отформатирует вам диск.
Какой на строки разобъете, какой так оставите?
Развитие экспорта/импорта
в тексте не может быть управляющих символов: 0-31, может еще каких — за исключением комбинации \r\n.
в том числе, не может быть одиночных символов \r, \n — источник текста (Lua-плагин или скрипт) будет порождать только \r\n.
текстовые блобы возможны только в ветке <pluginsconfig>.
как совсем крайний случай, может быть белый список плагинов, где есть текстовые блобы. но это крайне, крайне нежелательно.
можно придумать и ввести какой-то признак для узнавания текстовых блобов (в теге, в блобе, ...). это решение должно опираться на какие-то технические, реализационные нюансы, поэтому конкретные подходящие варианты решений я не смогу предложить. распознавание будет 100%, но минус: теряется совместимость с прежними версиями, требуется обновление Lua-плагинов.
юзер-драйвен решение: рядом с ключом блоба создается ключ с именем блоба плюс какой-то предопределенный постфикс. но я не знаю, как отнесется плагин к левому ключу в своей ветке настроек.
в том числе, не может быть одиночных символов \r, \n — источник текста (Lua-плагин или скрипт) будет порождать только \r\n.
текстовые блобы возможны только в ветке <pluginsconfig>.
как совсем крайний случай, может быть белый список плагинов, где есть текстовые блобы. но это крайне, крайне нежелательно.
можно придумать и ввести какой-то признак для узнавания текстовых блобов (в теге, в блобе, ...). это решение должно опираться на какие-то технические, реализационные нюансы, поэтому конкретные подходящие варианты решений я не смогу предложить. распознавание будет 100%, но минус: теряется совместимость с прежними версиями, требуется обновление Lua-плагинов.
юзер-драйвен решение: рядом с ключом блоба создается ключ с именем блоба плюс какой-то предопределенный постфикс. но я не знаю, как отнесется плагин к левому ключу в своей ветке настроек.
Фар делают добрые люди
-
- Posts: 6834
- Joined: Thu 23 Mar, 2006 21:36
- Location: Israel
- Has thanked: 41 times
- Been thanked: 530 times
Развитие экспорта/импорта
Все LuaFAR-плагины у меня (включая LuaMacro) и скрипты пишут в базу данных только одиночные \n (hex 0A).
-
- Posts: 6834
- Joined: Thu 23 Mar, 2006 21:36
- Location: Israel
- Has thanked: 41 times
- Been thanked: 530 times
Развитие экспорта/импорта
ccaid, ваша настойчивость заслуживает уважения, но... я убеждён в том, что Фар не должен при экспорте заниматься анализом содержимого, а напротив - строго экспортировать в указанном при сохранении данных формате.
На этом моё участие в данной ветке исчерпано.
На этом моё участие в данной ветке исчерпано.