View Issue Details

IDProjectCategoryView StatusLast Update
0000868WishesEditorpublic2014-05-23 13:17
ReporterJohnDoe Assigned To2useven10  
PrioritynormalSeverityfeatureReproducibilityalways
Status closedResolutionfixed 
Summary0000868: Порча текста при смене кодировки на "несовместимую"
DescriptionЕсли при редактировании файла с русским текстом не_в_юникоде попытаться поменять кодировку на UTF8, то фар выдаёт warning:

This file contains characters, which cannot be
correctly translated using the selected codepage.
It is not recommended to save this file.

Спасибо конечно за предупреждение, но текст-то уже безнадёжно испорчен - отменить преобразование невозможно.
Additional InformationВозможны разные варианты решения
Например
1) Не менять кодировку до явного сохранения по F2 (возможно при этом стоит выдать ворнинг повторно)
2) Сделать в ворнинге выбор кодировки
3) Добавить в ворнинг кнопку отмены

Последний вариант наиболее прост, но наименее удобен
TagsNo tags attached.
Build2797

Relationships

related to 0001773 closedvskirdin Far Manager Дадим возможность разрешать пункт AutoDetect в меню по Shift-F8 
has duplicate 0002354 closed2useven10 Far Manager Проблема с кодировками в редакторе. Файл в 1251 открывается в UTF-8 и при переключении в 2151 козябры 
related to 0001775 closedvskirdin Wishes Shift-F4: Возможность пере-автоопределения кодировки при открытии файла 
related to 0002250 closed2useven10 Far Manager Непоказ текста в 1251 внутри файла в UTF8 
related to 0002684 closed2useven10 Wishes Возможность смены кодировки путём перечитывания файла 

Activities

alexy

2009-05-18 18:31

administrator   bugnote:0003157

Нефиг так делать, с какого перепугу ты вообще полез на utf-8 менять.

JohnDoe

2009-05-18 21:31

updater   bugnote:0003159

Интересная реакция на багрепорт :-)

Во-первых, можно и без перепугу - случайно. Запросто можно промахнуться. И мышью, и клавиатурой.

Во-вторых лично я наткнулся на баг в процессе циклического перебора кодировок (макросом назначенным на F9)

ShiftF8 Down Enter

Очень было бы удобно, да баг помешал...

JohnDoe

2009-05-19 09:17

updater   bugnote:0003163

Хочу поспорить насчёт терминов Bug/Wish

Текст необратимо портится , не давая пользователю отменить преобразование - это самый настоящий баг.

Примерно как если бы при копировании файлов диалог предупреждающий о замене файла выдавался бы уже после факта перезаписи.

И насколько я понимаю выбрать UTF-8 - не единственный способ получить "несовместимую" кодировку.

Px

2009-05-19 10:55

reporter   bugnote:0003164

"Спасибо конечно за предупреждение, но текст-то уже безнадёжно испорчен - отменить преобразование невозможно."
Возможно, если файл не сохраняли после сообщения об ошибке :)
Возвращаем правильную кодировку, выходим из файла не сохраняя его, возвращаемся назад в файл - всё на месте. Если же не возвращать кодировку назад, при попытке войти в файл выдаётся всё то же сообщение "This file contains..."
А вот если сохранить изменения в файле, тогда русский текст действительно портится безвозвратно, и это плохо, явно надо проверять возможность/корректность преобразования до его выполнения

alexy

2009-05-19 10:57

administrator   bugnote:0003165

Проверять до не реально, ибо тогда тормоза ибо проверка==перекодировка, т.е. предёт два раза перекодировать. Что да можно это предупреждать до смены что то типа "ты дыбил, нафига сюда полез!".

Px

2009-05-19 11:08

reporter   bugnote:0003166

"Что да можно это предупреждать до смены что то типа "ты дыбил, нафига сюда полез!". "
Неудобно, надо будет либо вести "чёрный список" преобразований (из ansi в utf8 ни-ни), либо выводить предупреждение при каждой смене кодировки, что явно будет раздражать, предупреждение будут отключать и периодически наступать на грабли, ругая разработчиков.
Собственно, основная проблема в том, что если ты внёс изменения в файл, и случайно промазал (или макросом изменил) кодировку, ты теряешь возможность сохранить изменения и приходится выполнять ту же работу дважды.
Но вообще возникает вопрос - а как, собственно, должен выглядеть файл в oem/ansi, при отображении его в виде utf8, ведь даже в редакторе мы только меняем представление файла?
PS: Провёл ещё эксперимент - показ UTF8 в oem/ansi работает корректно

alexy

2009-05-19 11:15

administrator   bugnote:0003167

Редактор хранит текст тока в юникоде - для смены кодировки весь этот текст нужно:
1. перекодировать из юникода в оригинальную
2. перекодировать из ново выбраной в юникод.

JohnDoe

2009-05-19 11:16

updater   bugnote:0003168

>Возможно, если файл не сохраняли после сообщения об ошибке :)
До перекодировки файл может уже иметь несохранённые изменения - и все они потеряются.
Учитывая потенциальную "деструктивность" можно конечно сделать "принудительное" сохранение...

>Проверять до не реально, ибо тогда тормоза
А куда мы торопимся-то? Неужели полсекунды ожидания важнее сохранности данных? Тем более смена кодировки - разовая операция.

>Что да можно это предупреждать до смены
Так это значит что F8 нельзя будет нажать без того чтоб тебя дыбилом не обозвали?

JohnDoe

2009-05-19 11:19

updater   bugnote:0003169

>Что да можно это предупреждать до смены
Ещё можно хранить список потенциально несовместимых кодировок

alexy

2009-05-19 11:27

administrator   bugnote:0003170

Можно запретить переходить из однобайтовых в другие (как и нет щас перехода в юникодные кодировки например) но это не удобно.

Нужно понимать что текст который в однобайтовой кодировке, ну ни как не может нормально перекодироватся в UTF-8.

F8 тут не причём, порча может быть только при переходе в UTF8 если текст в файле совсем не UTF8.

JohnDoe

2009-05-19 12:23

updater   bugnote:0003171

>Нужно понимать что текст который в однобайтовой кодировке, ну ни как не может нормально перекодироватся в UTF-8.

Естественно.
Но бывает довольно часто сразу не понятно что текст в UTF-8, и открываем файл в однобайтной кодировке, а уже потом переключаемся в UTF-8 - и наоборот.

(а макрос для того чтобы автоматизировать это дело)

Имхо двойное перекодирование - меньшее зло

alexy

2009-05-19 12:26

administrator   bugnote:0003172

Ну так для этого случая и проблемы нет.
Проблема она тока когда на UTF8 текст пытаешся открыть как UTF8 - а тут сам себе злобный буратино.

JohnDoe

2009-05-19 12:30

updater   bugnote:0003173

Либо реализовать отмену - по CtrlZ.
Подозреваю что накладных расходов будет больше чем при двойном перекодировании...

Px

2009-05-19 12:36

reporter   bugnote:0003174

Как вариант произвести преобразование в новый объект (структуру? не программер я, не в курсе), произвести проверку на корректность, если возникли потери выводим красное окно с предупреждением, при утвердительном ответе убираем оригинальный вариант, оставляя преобразованный, при отрицательном возвращаем оригинал и кодировку, и удаляем результат преобразований

JohnDoe

2009-05-19 12:36

updater   bugnote:0003175

Last edited: 2009-05-19 12:40

2PX - накладных расходов больше чем при двойном перекодировании

>Проблема она тока когда не-UTF8 текст пытаешся открыть как UTF8 - а тут сам себе злобный буратино.

Проблема в том что иногда не понятно что с текстом не так - логично при этом пытаться сменить кодировку.
И логично не заставлять пользователя вникать в тонкости реализации перекодирования в фаре, и в случае если он напортачил по неведению - позволить отмену, а не называть его буратиной.

Кстати кодировка-то запоминается. И после ошибочного выбора UTF-8 файл опять откроется с потерями. И надо будет плясать чтобы открыть его нормально. Не юзерфрендли всё это
У нас же не EDLIN

JohnDoe

2009-05-19 15:55

updater   bugnote:0003176

Хочу подвести итоги: Выяснилось что сама по себе "несовместимость" кодировок между собой не страшна, поскольку редактор хранит текст в юникоде.

Поэтому тикет на самом деле должен быть сформулирован так:

0000868: Выбор кодовой страницы: портится текст при открытии неюникодного текста в юникоде

Поскольку проблема сужается, то почему бы действительно при выборе UTF-8 не пренебречь накладными расходами и не осуществить дополнительную проверку?

alexy

2009-05-19 16:03

administrator   bugnote:0003177

А если файл большой?

Px

2009-05-19 16:26

reporter   bugnote:0003178

"А если файл большой?"
То ругани в случае его повреждения будет много :)))

JohnDoe

2009-05-19 16:36

updater   bugnote:0003179

Тормоза будут проявляться только при конвертации в UTF, а это не так часто приходится делать.

К тому же - насколько большим должен быть файл, чтобы ощутить эти тормоза?

samlyukov

2009-05-19 17:11

reporter   bugnote:0003180

развезли тут на 19 топиков непонятно чего ;)
все намного проще можно сделать - warning нужно показывать до применения кодировки, а-ля:
  is a read-only file
Do you wish to edit it?
        Yes No
плюс можно в этот диалог впихнуть первую попавшуюся строку с примером, что мы получим от такой операции.

JohnDoe

2009-05-20 14:09

updater   bugnote:0003184

2samlyukov
1)Намного проще не совсем получается по причине изложенной в 5-м ноуте
2)Первая попавшаяся строка с примером может быть не показательна например в случае если перекодировка затрагивает только кириллицу

А вот в случае облома - да, интересно было бы знать в какой строке и на каком символе он произошёл

JohnDoe

2009-05-20 14:23

updater   bugnote:0003186

Сообщение о несовместимости кодировок появляется не только при попытке смены, но и сразу при открытии файла (F4, или открытие редактора каким-либо плагином).

Так бывает не только если явно задавать кодировку через ShiftF4, но и в случае когда кодировка была запомнена с прошлого раза. (а в прошлый раз на том месте мог быть вообще другой файл)

И приходится делать всякие странные и неочевидные телодвижения чтобы открыть файл в правильной кодировке.

JohnDoe

2011-05-23 15:49

updater   bugnote:0007012

В свете 0001773 (AutoDetect в меню по Shift-F8) проблема порчи текста актуализировалась.
Ведь до этого можно было сказать что юзер "сам дурак" что выбрал несовместимую кодировку.
Теперь же выбирает не юзер, а фар, и более того: для него не действует "табу" переключения между одно/много-байтными кодировками.

Предлагаю реализовать возможность отмены операции смены кодировки через UNDO.
Учитывая, что это ресурсоёмко, предлагаю поставить ограничение на размер файла: в случае если файл большой надо предложить юзеру предварительно сохранить изменения.

JohnDoe

2012-04-19 15:37

updater   bugnote:0008972

Last edited: 2012-04-19 15:41

View 2 revisions

Тикет в целом вроде бы решён. Можно закрыть, проставив связь с 0001773

Один вопрос: как именно производится проверка?

2useven10

2012-04-19 19:06

developer   bugnote:0008976

смена кодировки делается в два приема: сначала проверка без реальной замены, если при этом используются 'дефолтовые символы' - значит плохо. потом, если всё ок, или замена подтверждена - собственно перекодировка.

2useven10

2012-04-19 19:15

developer   bugnote:0008977

2613

JohnDoe

2012-04-20 10:15

updater   bugnote:0008982

Выше (0000868:0003165) высказывались опасения, что "двойная" работа приведёт к "тормозам".
Есть мнение ((0000868:0003172) что такую проверку надо делать не всегда, а только при переключении в UTF-8.

А вы как думаете?

2useven10

2012-04-24 19:29

developer   bugnote:0009045

Last edited: 2012-04-25 03:21

View 3 revisions

Для файлов, которые имеет смысл редактировать - несущественно.
Измерил на своей машине, для гигабайтного файла (нормальный человек f4 давить не будет): проверка около 3сек, переключение от 5 до 11 сек (в зависимости от направления и фазы луны). Вполне приемлемо.

JohnDoe

2012-04-25 07:47

updater   bugnote:0009046

>Измерил на своей машине
Четырёхядерник с 16Г памяти? ;-)

>от 5 до 11 сек
Даже 0,25 секунды ощутимо.
На слабой машине для такой задержки не понадобится гигабайтный файл.

Может всё-таки стоит оптимизировать?

2useven10

2012-04-25 08:00

developer   bugnote:0009048

Last edited: 2012-04-29 18:41

View 2 revisions

8-ми с 12-ю, но это не важно, перекодированием занимается одно ядро.
не стоит. на слабой машине никто не будет редактировать гигабайтный (и даже гораздо меньший) файл - пока он загрузится 8 раз передумаешь.
а если есть такая небходимость - лишние 3 секунды погоды не сделают.

JohnDoe

2012-05-17 12:36

updater   bugnote:0009223

Дублирую из 0001773:0007044.

Если фар обнаруживает, что перекодировка невозможна, то выдаётся такое предупреждение:

  Editor contains characters, which cannot be
 correctly translated using selected codepage.
                   Continue?
───────────────────────────────────────────────
               { OK } [ Cancel ]

Тут хотелось бы видеть ещё и кнопку [ Show ], позволяющую перейти к проблемному месту в тексте.

Ещё: не лучше ли сделать кнопкой по умолчанию [ Cancel ] ?

2useven10

2012-09-11 14:35

developer   bugnote:0009507

2797 - [Show]

2useven10

2013-04-05 18:22

developer   bugnote:0010681

Last edited: 2013-04-08 01:34

View 2 revisions

что осталось:
1) кнопка [Change Codepage] при открытии файла в неправильной кодировке (содержит символы, которые невозможно корректно ...).
2) дать возможность перечитывать файл при смене кодировки по Shift-F8 и таким образом снять, например, ограничения по смене юникод-неюникод кодировок.

добавьте, если что-то пропустил...

JohnDoe

2014-05-23 12:51

updater   bugnote:0012426

2useven10

1) http://bugs.farmanager.com/view.php?id=2250#c12247
2) http://bugs.farmanager.com/view.php?id=2684

А данный тикет можно закрыть

Issue History

Date Modified Username Field Change
2009-05-18 17:32 JohnDoe New Issue
2009-05-18 18:31 alexy Note Added: 0003157
2009-05-18 21:31 JohnDoe Note Added: 0003159
2009-05-18 22:17 DrKnS Project Far Manager => Wishes
2009-05-19 09:17 JohnDoe Note Added: 0003163
2009-05-19 10:55 Px Note Added: 0003164
2009-05-19 10:57 alexy Note Added: 0003165
2009-05-19 11:08 Px Note Added: 0003166
2009-05-19 11:15 alexy Note Added: 0003167
2009-05-19 11:16 JohnDoe Note Added: 0003168
2009-05-19 11:19 JohnDoe Note Added: 0003169
2009-05-19 11:27 alexy Note Added: 0003170
2009-05-19 12:23 JohnDoe Note Added: 0003171
2009-05-19 12:26 alexy Note Added: 0003172
2009-05-19 12:30 JohnDoe Note Added: 0003173
2009-05-19 12:36 Px Note Added: 0003174
2009-05-19 12:36 JohnDoe Note Added: 0003175
2009-05-19 12:37 JohnDoe Note Edited: 0003175
2009-05-19 12:40 JohnDoe Note Edited: 0003175
2009-05-19 15:55 JohnDoe Note Added: 0003176
2009-05-19 16:03 alexy Note Added: 0003177
2009-05-19 16:26 Px Note Added: 0003178
2009-05-19 16:36 JohnDoe Note Added: 0003179
2009-05-19 17:11 samlyukov Note Added: 0003180
2009-05-20 14:09 JohnDoe Note Added: 0003184
2009-05-20 14:23 JohnDoe Note Added: 0003186
2011-05-23 15:49 JohnDoe Note Added: 0007012
2012-04-19 15:37 JohnDoe Note Added: 0008972
2012-04-19 15:41 JohnDoe Note Edited: 0008972 View Revisions
2012-04-19 19:06 2useven10 Note Added: 0008976
2012-04-19 19:12 2useven10 Relationship added related to 0001773
2012-04-19 19:15 2useven10 Note Added: 0008977
2012-04-19 19:15 2useven10 Assigned To => 2useven10
2012-04-19 19:15 2useven10 Status new => feedback
2012-04-20 10:15 JohnDoe Note Added: 0008982
2012-04-20 10:15 JohnDoe Status feedback => assigned
2012-04-24 19:29 2useven10 Note Added: 0009045
2012-04-24 19:34 2useven10 Note Edited: 0009045 View Revisions
2012-04-25 03:21 2useven10 Note Edited: 0009045 View Revisions
2012-04-25 07:47 JohnDoe Note Added: 0009046
2012-04-25 08:00 2useven10 Note Added: 0009048
2012-04-29 18:41 2useven10 Note Edited: 0009048 View Revisions
2012-05-17 12:36 JohnDoe Note Added: 0009223
2012-09-11 14:35 2useven10 Note Added: 0009507
2012-09-11 14:35 2useven10 Status assigned => feedback
2013-02-03 00:33 alexy Severity minor => feature
2013-04-01 12:10 2useven10 Relationship added related to 0002354
2013-04-01 12:38 2useven10 Relationship added related to 0001775
2013-04-05 18:22 2useven10 Note Added: 0010681
2013-04-05 18:22 2useven10 Relationship replaced has duplicate 0002354
2013-04-05 18:37 2useven10 Status feedback => assigned
2013-04-08 01:34 2useven10 Note Edited: 0010681 View Revisions
2013-05-08 12:27 2useven10 Relationship added related to 0002250
2014-05-23 12:51 JohnDoe Note Added: 0012426
2014-05-23 13:16 2useven10 Relationship added related to 0002684
2014-05-23 13:17 2useven10 Build => 2797
2014-05-23 13:17 2useven10 Status assigned => closed
2014-05-23 13:17 2useven10 Resolution open => fixed