FbEdit без кракозябров
|
|
haav | Дата: Суббота, 08.07.2017, 08:53 | Сообщение # 1 |
Генералиссимус
Группа: Администраторы
Сообщений: 1361
Статус: Offline
| Привет всем!
Я знаю, что тех , кто использует FbEdit , очень раздражают кракозябры. Это заставляет совершать много лишних действий. После недавних дней кодинга, мое терпение кончилось и я решил разобраться с этой проблемой. Пришлось полностью пересобирать все ASM библиотеки. Дело в том, что FbEDIT.dll собирается из 7-ми статических библиотек. Уж не знаю, как там у Кетилло было все настроено, но по умолчанию нихера ничего не компилируется. И так и сяк пробовал подставлять пути, но каждый раз библиотеки требовали один и тот же путь к другой библиотеке. Я уж этот путь с нужной библиотекой и в папку с проектом подставлял и в папку с самими библиотеками и еще в кучу других папок пихал и даже глобальным делал на уровне системы, ничего не получалось. Вот если подсунуть им путь при компиляции их самих, то они прекрасно его видят и далее никаких ошибок. В итоге, чтобы внести небольшое дополнение в ASM код , пришлось пересобирать все статические библиотеки и только после этого пересобирать сам FbEdit.dll. Собранный файл выкладываю для тех кому нужно. Советую старый fbedit.dll переименовать и только после этого копировать fbedit.dll из архива в папку с редактором. Если будут какие косяки , которых не было с авторским fbedit.dll, пишите.
Вы сохраняете власть над людьми покуда оставляете им что-то…Отберите у человека все, и этот человек уже будет неподвластен вам…
|
|
| |
DarkDemon | Дата: Среда, 19.07.2017, 01:13 | Сообщение # 2 |
Полковник
Группа: Друзья
Сообщений: 188
Статус: Offline
| Стас, а что за "крякозябры"? А то я что-то не в теме. Сам просто убрал плагин CP1251ToCP866.dll, это что-то с этим связанное? Редактор потестим.
|
|
| |
haav | Дата: Среда, 19.07.2017, 08:04 | Сообщение # 3 |
Генералиссимус
Группа: Администраторы
Сообщений: 1361
Статус: Offline
| Цитата DarkDemon ( ) Сам просто убрал плагин CP1251ToCP866.dll, это что-то с этим связанное?
Нет, с ним не связано. Вообще не знаю, зачем ты отключил данный плагин, если ты частенько работаешь с OEM? Ведь данный плагин может как загружать OEM , так и сохранять в этом формате. Возможно ты пробовал авторский плагин. Да, его реализация данного плагина вообще не работала. Я его подправлял и после этого редактор распознает при загрузке OEM и может сохранять в этот формат. Ты должен понимать, что распознавание идет только , если в тексте есть русские символы. При чем ни один редактор со 100% гарантией не сможет распознать OEM866.
Пример:
В файле, сохраненым как OEM866 написано:
Цитата 12345678 "Ёэя" 8363534
Данный текст редакторы как правило считают как текст в формате ASCII 1251. Плохо, что не придумали маркеры в файле для 866 и 1251 кодировок. Каждый редактор использует свой алгоритм распознавания, но как я и сказал без ошибок распознать формат не получится. Впрочем, если кто-то предложит более практичный алгоритм распознавания, я с радостью его внедрю в плагин.
Цитата DarkDemon ( ) Стас, а что за "крякозябры"?
Для того, чтобы отловить данный баг , сделай пошагово с авторским FBEdit.dll:
1) Открой редактор 2) Напиши любое русское слово 3) Переключи раскладку на английскую 4) Скопируй текст из FbEDIT 5) Вставь скопированный текст в любой другой редактор (Notepad, AkelPad и пр.)
Вы сохраняете власть над людьми покуда оставляете им что-то…Отберите у человека все, и этот человек уже будет неподвластен вам…
|
|
| |
DarkDemon | Дата: Четверг, 20.07.2017, 12:17 | Сообщение # 4 |
Полковник
Группа: Друзья
Сообщений: 188
Статус: Offline
| Цитата haav ( ) Вообще не знаю, зачем ты отключил данный плагин, если ты частенько работаешь с OEM? Это был плагин в твоей сборке. У него был жёсткий косяк, уже точно не помню из-за чего, но информация жёстко переводилась из одной кодировки в другую и портилась при сохранении(после того как я попортил ряд своих файлов мне пришлось отключить эту штуку), это было связано с тем, что некоторые символы не могут быть переведены в принципе т.к. не имеют соответствия. Дело в том, что как раз больше работаю с OEM866 чем с UTF, потому что мне так проще писать собственные функции. Из-за, в общем, того что часть системных функций написаны под другие кодировки это создаёт ряд ощутимых сложностей(в каждом своём проекте в буквальном смысле трахаюсь с кодировками), вообще не занимался этими вопросами с тех самых пор, когда у нас на форуме создавал тему про кодировки.
Цитата haav ( ) Вставь скопированный текст в любой другой редактор (Notepad, AkelPad и пр.) А понял. Было такое, знаешь как я делаю, вставляю текст в OpenOffice Writer и тут же копирую его и уже вставляю куда мне надо. Бред, конечно. Сейчас авторский FBEdit найти не могу, с твоей сборкой такого вроде нет, или же не знаю от чего это ещё может зависеть, только что скопировал в bred русский текст который напечатал в FBEdit - всё нормально. Но подобные баги отчётливо помню. Просто всегда под рукой Writer, на Word-е 2003-м тоже прокатывает.
|
|
| |
haav | Дата: Четверг, 20.07.2017, 14:03 | Сообщение # 5 |
Генералиссимус
Группа: Администраторы
Сообщений: 1361
Статус: Offline
| Цитата DarkDemon ( ) Это был плагин в твоей сборке. У него был жёсткий косяк, уже точно не помню из-за чего, но информация жёстко переводилась из одной кодировки в другую и портилась при сохранении(после того как я попортил ряд своих файлов мне пришлось отключить эту штуку), это было связано с тем, что некоторые символы не могут быть переведены в принципе т.к. не имеют соответствия. Дело в том, что как раз больше работаю с OEM866 чем с UTF, потому что мне так проще писать собственные функции. Из-за, в общем, того что часть системных функций написаны под другие кодировки это создаёт ряд ощутимых сложностей(в каждом своём проекте в буквальном смысле трахаюсь с кодировками), вообще не занимался этими вопросами с тех самых пор, когда у нас на форуме создавал тему про кодировки.
Леха, сможешь воспроизвести этот баг, желательно на видео? Я в принципе не понимаю, как может такое случится... Если сможешь , то так же неплохо бы и файл, который после работы с плагином как ты говоришь косячит.
Цитата DarkDemon ( ) Сейчас авторский FBEdit найти не могу
Как это не можешь найти? FbEdit.dll всегда был авторским, я никогда до создания этой темы в него изменений не вносил.
P.S. Судя по тому, что отзывов в этой теме кроме твоих нет, народу пофиалетово. В принципе я исправлял баг в dll-ке для себя, чтобы не трахаться с крякозябрами. Ну а если другим нравится канителиться с другими редакторами, когда нужно скопировать что-то из FbEdit, пусть трахаются дальше.
Вы сохраняете власть над людьми покуда оставляете им что-то…Отберите у человека все, и этот человек уже будет неподвластен вам…
|
|
| |
DarkDemon | Дата: Пятница, 21.07.2017, 13:18 | Сообщение # 6 |
Полковник
Группа: Друзья
Сообщений: 188
Статус: Offline
| Цитата haav ( ) Леха, сможешь воспроизвести этот баг, желательно на видео? Я в принципе не понимаю, как может такое случится... Если сможешь , то так же неплохо бы и файл, который после работы с плагином как ты говоришь косячит. Завтра попробую, просто сейчас компы местми меняю возьни много. Сам если честно уже не помню нюансов, помню только что несколько файлов с русскими комментариями попортил в своё время(все коменты стали нечитаемыми и восстановить переводом кодировок уже было нельзя). Очевидно что это было из-за специфики кодинга.
Цитата haav ( ) Судя по тому, что отзывов в этой теме кроме твоих нет, народу пофиалетово. FBEdit-ом мало кто пользуется. Сам уж мирюсь в FBEdito-ом, потому что нет ничего более достойного. Надо уже собраться с силами и написать редактор, помню одно время начал этим заниматься, но упёрся в отсутствие нормального рабочего места и отложил это дело. В идеале бы получить гибрид редактора QB4 + TurboPascal + BlitzBasic. Не новомодного, а DOS-подобного. Причём мне лично отладчик и всякие плюшки не нужны, нужен просто удобный и привычный визуально редактор, где я бы не тратил время на оформление кода и навигации по коду, а просто решал бы поставленные задачи.
|
|
| |
quiet_snow_los | Дата: Среда, 26.07.2017, 17:14 | Сообщение # 7 |
Рядовой
Группа: Пользователи
Сообщений: 16
Статус: Offline
| Добрался наконец-то до FB. Залогинился с грехом пополам через uid, правда ник какой-то стрёмный(я просто там лосём обозвался и в конце он мне его дописал), ну да ладно. Короче смотри: https://yadi.sk/i/VnbOaoG93LRtHd
Не знаю может быть ты и фиксил как раз именно этот косяк.
Сообщение отредактировал quiet_snow_los - Среда, 26.07.2017, 17:15 |
|
| |
haav | Дата: Среда, 26.07.2017, 20:26 | Сообщение # 8 |
Генералиссимус
Группа: Администраторы
Сообщений: 1361
Статус: Offline
| Цитата quiet_snow_los ( ) Добрался наконец-то до FB. Залогинился с грехом пополам через uid, правда ник какой-то стрёмный(я просто там лосём обозвался и в конце он мне его дописал), ну да ладно. Короче смотри:
Хорошо Леха. Спасибо, что записал видео. Хоть я очень редко работаю с OEM , но думаю меня тоже сильно расстроит, если в какой то момент при работе с OEM, испортится исходник. Буду думать, как исправить.
Цитата Не знаю может быть ты и фиксил как раз именно этот косяк.
Нет. Авторский плагин вообще OEM не распознавал, да и сохранять не было возможности в этой кодировке.
Вы сохраняете власть над людьми покуда оставляете им что-то…Отберите у человека все, и этот человек уже будет неподвластен вам…
|
|
| |
quiet_snow_los | Дата: Среда, 26.07.2017, 22:53 | Сообщение # 9 |
Рядовой
Группа: Пользователи
Сообщений: 16
Статус: Offline
| Стас, да не запаривайся, это в принципе не мешает, т.к. отключаю плагин и нормально работаю. Кстати по дефолту в твоей сборке он выключен. Сейчас, на самом деле, ASCII 866 уже неактуален, с ним работают только старпёры потипа меня.
Сам просто использую ASCII, во-первых, потому что он очень прост и во-вторых - потому что не хочу зависеть от сторонних шрифтов, так хотя бы знаю, что где бы прогу не запустил, на XP, на семёрке или десятке - она заработает без изменений в шрифтах. Но вот при взаимодействии с функциями ОС иногда случаются косячки - пожалуй это меньшая из жертв такого подхода. Конечно всё понимаю, но, полагаю, вряд-ли кто-то сохранит имя файла китайскими иероглифами и прочими символами и будет пытаться открывать его в проге, заточенной под OEM866, в остальных же случаях есть функции конверсии(перевод в мультибайтовое представление и в целевую кодировку), которые вроде работают, а в последнем своём проекте, помню, лихо набивал функцию конвертации CASE-ами, работало.
Проблемы обычно нет тогда, когда у программиста всё унифицировано под одну кодировку, а у меня ж нифига не унифицировано, как куропатка прыгаю в bred и обратно. Хорошо хотя бы FBEdit есть, он свой хлеб отрабатывает на 5 баллов.
|
|
| |
haav | Дата: Четверг, 27.07.2017, 17:15 | Сообщение # 10 |
Генералиссимус
Группа: Администраторы
Сообщений: 1361
Статус: Offline
| Посмотрел как следует твое видео и так же порыл исходник FbEdit. В данном случае как раз плагин работает как надо, а проблемы возникают по двум причинам:
1) Виноват ты сам, когда в файл, открытый в кодировке ASCII 1251 копируешь данные из другого редактора, в котором файл открыт в OEM866. Или наоборот. Любой редактор будет косячить. Например один из самых популярных редакторов AkelPad предупреждает о таких действиях при сохранении, выводя предупреждение:
2) Редактор FbEdit изначально не затачивался под OEM , а плагин банально переводит при загрузке и при сохранении в нужный формат.
И так , что делает плагин? В случае, когда исходник в OEM, либо сохраняется как OEM: Cам редактор работает не с OEM , при загрузке из файла, данные преобразовываются в ASCII 1251. При сохранении, данные из редактора (ASCII 1251) преобразовываются в OEM и сохраняются.
В случае, когда исходник в ASCII, либо сохраняется как ASCII: Плагин фактически ничего не делает.
Вторая причина кроется в том, что функционал работы редактора с буфером обмена не настроен для корректной работы с OEM . Редактор всегда получает данные из ClipBoard по дефолту, а ведь у ClipBoard есть различие форматов:
CF_TEXT , CF_OEMTEXT
Если бы автор внес перечисление форматов и возможность принудительного получения данных по указанному формату , в зависимости от кодировки исходного файла, то все работало бы как надо. В принципе все это можно сделать и возможно я займусь этим как только будет настроение. Тем более , что плагину очень не хватает возможности принудительно выбирать кодировку при загрузке файла. Автоматическое определение кодировки конечно хорошо, но вот в какой формат должен преобразовывать редактор, если его пользует такой человек как ты , смешивая форматы?
Вы сохраняете власть над людьми покуда оставляете им что-то…Отберите у человека все, и этот человек уже будет неподвластен вам…
|
|
| |
haav | Дата: Четверг, 27.07.2017, 19:30 | Сообщение # 11 |
Генералиссимус
Группа: Администраторы
Сообщений: 1361
Статус: Offline
| Во блин, Леха я в тупике. Прикинь какая шняга получается.
Берем файл, в котором записано следующее (пишу в HEX виде, чтобы было точно и наверняка):
Цитата 27 20 D0 F3 F1 F1 EA E8 E9 20 F2 E5 EA F1 F2 0D 0A 0D 0A 50 72 69 6E 74 20 22 48 65 6C 6C 6F 20 57 6F 72 6C 64 21 22 0D 0A 0D 0A 27 20 90 E3 E1 E1 AA A8 A9 20 E2 A5 AA E1 E2 0D 0A 0D 0A 50 72 69 6E 74 20 22 48 65 6C 6C 6F 20 57 6F 72 6C 64 21 22
открываем Hex редактор и вставляем туда это содержимое, потом сохраняем как txt.
Открываем в редакторе, поддерживающем OEM (akelpad, Notepad++ ...). Переводим в кодировку OEM и копируем все из редактора в буфер обмена.
Затем запускаем этот код:
Код #include once "window9.bi"
Function GetClipBoardText() As String Export OpenClipboard(0) Var Clip = GetClipboardData(CF_TEXT) Var size_ = GlobalSize(Clip) Dim Buf As String = Space(size_) Var Mem = GlobalLock(Clip) CopyMemory(Strptr(buf), Mem, size_) Function=buf GlobalUnlock(Mem) CloseClipboard() End Function
Dim As integer hwnd,event hwnd=OpenWindow("1",300,10,800,400) EditorGadget(1,10,10,300,300, "") EditorGadget(2,400,10,300,300, "") PasteEditor (2,GetClipBoardText()) SendMessage(GadgetID(1),WM_PASTE,0,0) Do event=WaitEvent() If event=EventClose Then End Loop
И что мы видим? Третья буква различается в редакторах, хотя должно быть одинаково!
1) WM_PASTE работает правильно 2) GetClipBoardText() работает неправильно
Код функции GetClipBoardText() на всех языках программирования такой же, тут проблемы точно нет. В принципе я запускал такой же код на purebasic причем встроенной функцией GetClipboardText, результат тот же.
То есть получается сами winapi функции для работы с OEM работают коряво? В редакторах akelPad , notepad и многих других судя про всему используется WM_PASTE , но в случае FbEDIT используется метод с GetClipboardData(CF_TEXT) и он не дает нужного результата. Кстати , если вызвать GetClipboardData(CF_OEMTEXT) , то все копируется правильно. Но как угадать, когда нужно вызывать CF_OEMTEXT , а когда CF_TEXT ? Да... жопа. И WM_PASTE для FbEDIT не катит, поскольку редактор самописный, а не переделанный RichEDIT...
Вы сохраняете власть над людьми покуда оставляете им что-то…Отберите у человека все, и этот человек уже будет неподвластен вам…
|
|
| |
quiet_snow_los | Дата: Пятница, 28.07.2017, 18:04 | Сообщение # 12 |
Рядовой
Группа: Пользователи
Сообщений: 16
Статус: Offline
| Цитата haav ( ) То есть получается сами winapi функции для работы с OEM работают коряво? Где-то точно коряво. Неспроста же полез мутить свои функции, помню, когда копался с разными API была куча просто непоняток и косяков. Где-то даже пол текста было нормально, а пол текста криво.
Цитата haav ( ) Виноват ты сам, когда в файл, открытый в кодировке ASCII 1251 копируешь данные из другого редактора, в котором файл открыт в OEM866. Так потом в видео показываю что без плагина всё копируется идеально. После твоего поста у меня как раз подозрения на сохранение. Суть в том, что всё, что кроме псевдографики должно переводиться из кодировки в кодировку идеально вне зависимости от направления перевода.
Цитата haav ( ) а плагин банально переводит при загрузке и при сохранении в нужный формат А с внутренним представлением текста там что? Т.е. я делаю банальное предположение, что если он всегда находится в 1251 то почему же тогда не портится без плагина? ))) Я сам в тупике. Просто мы наверное сильно заморачиваемся.
Цитата haav ( ) Да... жопа. Именно ))) она самая. Получается та же ситуация что и в мире, нет универсального разговорного языка и это создаёт сложности неимоверного масштаба. В программировании с кодировками та же байда. С клипбордом, кстати, ещё не разбирался поэтому не могу ничего сказать.Добавлено (28.07.2017, 18:04) ---------------------------------------------
Цитата haav ( ) но вот в какой формат должен преобразовывать редактор, если его пользует такой человек как ты , смешивая форматы? Ну пока меня выручает Bred, а задача FBEdit'a просто подсвечивать синтаксис, если бы Bred умел подсвечивать синтаксис - то думаю, мне бы и FBEdit не потребовался, я бы просто прописал батник и компилировал из командной строки. Правда Bred2 работает не на всех системах, например на WinXP x64 полностью обломался с Bred-ом. На некоторых конфах(Win7\XP), приходится ставить режим совместимости с WinXP SP2. Очень забавно, вроде бы процессор должен запускать все 32 битные проги и на 64 битах так же, но по факту, что-то где-то отваливается.
|
|
| |
haav | Дата: Пятница, 28.07.2017, 21:21 | Сообщение # 13 |
Генералиссимус
Группа: Администраторы
Сообщений: 1361
Статус: Offline
| Цитата quiet_snow_los ( ) Т.е. я делаю банальное предположение, что если он всегда находится в 1251 то почему же тогда не портится без плагина?
Судя по видео, когда ты отключал плагин и копировал инфу из BRED , кодировка в BRED при копировании всегда была ASCII 1251 (в строке состояния обоих редакторов это хорошо видно). Поскольку в FBEDIT и в BRED кодировки совпадали, то никаких косяков не возникало. Однако это не отменяет тот вопрос, который возник у меня, и как его решить я пока не знаю. Дело тут даже не в FBEDIT , просто может настать момент когда нужен будет функционал , связанный с буфером обмена и главное чтобы без косяков.
Цитата Ну пока меня выручает Bred, а задача FBEdit'a просто подсвечивать синтаксис, если бы Bred умел подсвечивать синтаксис - то думаю, мне бы и FBEdit не потребовался, я бы просто прописал батник и компилировал из командной строки. Правда Bred2 работает не на всех системах, например на WinXP x64 полностью обломался с Bred-ом. На некоторых конфах(Win7\XP), приходится ставить режим совместимости с WinXP SP2. Очень забавно, вроде бы процессор должен запускать все 32 битные проги и на 64 битах так же, но по факту, что-то где-то отваливается.
У меня BRED2, BRED3 на win7 вообще нифига толком не работает. Печатаешь текст русскими буквами, потом меняешь формат на OEM и пипец (все символы в кракозябрах и обратно уже не вернуть). В жопу его
Вы сохраняете власть над людьми покуда оставляете им что-то…Отберите у человека все, и этот человек уже будет неподвластен вам…
|
|
| |
haav | Дата: Суббота, 29.07.2017, 10:39 | Сообщение # 14 |
Генералиссимус
Группа: Администраторы
Сообщений: 1361
Статус: Offline
| В общем провел исследования и вот к чему пришел. Если хочешь забыть про всякие траблы с кодировками, то нужно использовать UNICODE в своих проектах. Вот пример:
Код #Define UNICODE #Include "windows.bi"
Dim Shared As HWND mHwnd Dim msg As MSG Dim As WNDCLASSEX wc Dim As WString*20 NameClass="MyClass" Dim As HINSTANCE Hinst=GetModuleHandle(0) LoadLibrary "RICHED20.DLL"
Function EditorGadget Alias "EditorGadget" (ByVal gadget As Integer, ByVal x As Integer,ByVal y As Integer,ByVal Width_ As Integer,ByVal height_ As Integer,ByVal stri As WString Ptr = 0,ByVal par As Integer=0) As HWND Export Var hhh= CreateWindowEx( &h00000200, "RICHEDIT20W", stri,&h503110C4 Or par, x, y, Width_, Height_, mHwnd, Cast(HMENU,gadget), 0, 0) SendMessage( hhh, EM_LIMITTEXT,-1,0) Return hhh End Function
Function wndproc(hwnd As HWND, msg As Uinteger,_ wparam As WPARAM, lparam As LPARAM) As Integer Select Case msg Case WM_CREATE
Case WM_DESTROY PostQuitMessage(0) End Select Return DefWindowProc(hwnd,msg,wparam,lparam) End Function
With wc .cbSize=SizeOf(WNDCLASSEX) .style=CS_HREDRAW Or CS_VREDRAW .lpfnWndProc=@WndProc .hInstance=Hinst .hIcon=LoadIcon(0,IDI_QUESTION) .hCursor=LoadCursor(0,IDC_ARROW) .hbrBackground=Cast(HBRUSH,COLOR_WINDOWFRAME) .lpszClassName=StrPtr(NameClass) .hIconSm=.hIcon End With
If RegisterClassEx(@wc)=0 Then Print "Register error, press any key" Sleep End Endif
Function GetClipBoardText() As WString Ptr Export OpenClipboard(0) Var Clip = GetClipboardData(CF_UNICODETEXT) Var size_ = GlobalSize(Clip) Dim Buf As WString ptr = Allocate(size_) Var Mem = GlobalLock(Clip) CopyMemory(buf, Mem, size_) Function=buf GlobalUnlock(Mem) CloseClipboard() End Function
mHwnd = CreateWindowEx(0,NameClass,"",_ WS_VISIBLE Or WS_OVERLAPPEDWINDOW,100,100,800,500,0,0,Hinst,0)
Var ed1 = EditorGadget(1,10,10,300,300, "") Var ed2 = EditorGadget(2,400,10,300,300, "")
SendMessage(ed1,EM_REPLACESEL,1,Cast(LPARAM,GetClipBoardText())) SendMessage(ed2,WM_PASTE,0,0)
While GetMessage(@msg,0,0,0) TranslateMessage(@msg) DispatchMessage(@msg) Wend
Данный пример уже работает верно, в отличии от примера из этого поста.
При использовании ASCII , вся байда кроется в том, что в кодировках 1251 и 866 во второй половине таблицы разный набор символов. Система всегда делает неявные преобразования между кодировками в буфере обмена. Когда я получаю текст из буфера обмена с помощью GetClipboardData(CF_TEXT) , то я получаю уже не тот набор байтов, который положил в него, копируя OEM данные (система уже преобразовала его в ascii 1251). Когда я загоняю в буфер текст и в этом тексте например есть символ ╨ в OEM кодировке , то система преобразовывая в ASCII 1251 пытается подобрать такой же символ, а не найдя впихивает бурду в виде символа "|" . Однако символ "|" и символ "╨" имеют разное байтовое представление A6 и D0. Отсюда и случаются косяки с кодировками. В случае же UNICODE , проблем не возникает, поскольку в UNICODE можно найти абсолютно любой символ.
Поскольку FBEDIT как проект не юникодовый, нихера с ним не сделаешь.
Вы сохраняете власть над людьми покуда оставляете им что-то…Отберите у человека все, и этот человек уже будет неподвластен вам…
|
|
| |
TimurAR | Дата: Четверг, 11.01.2018, 22:19 | Сообщение # 15 |
Рядовой
Группа: Пользователи
Сообщений: 14
Статус: Offline
| Уважаемые форумчани внесу свои 2 копейки. На WinXP 32 такой проблемы никогда не было. Система Win7 64. Проблема та же самая. Внесение изменений в реестр по кодовой странице не помогло, но если при этом заменить файл "C:\Windows\System32\C_1252.NLS" на копию файла "C:\Windows\System32\C_1251.NLS" естественно переименовав, то после перезагрузки с кодировкой проблема пропала. Однако со временем (вероятно связано с восстановлением системных файлов) исходный файл восстанавливается.
Сообщение отредактировал TimurAR - Четверг, 11.01.2018, 22:22 |
|
| |
|