FreeBasic
Главная
Вход
Регистрация
Четверг, 18.04.2024, 17:31Приветствую Вас Гость | RSS
[ Новые сообщения · Участники · Правила форума · Поиск · RSS ]
  • Страница 1 из 2
  • 1
  • 2
  • »
Форум » Freebasic » Вопросы по языку FreeBasic » FbEdit без кракозябров (исправление)
FbEdit без кракозябров
haavДата: Суббота, 08.07.2017, 08:53 | Сообщение # 1
Генералиссимус
Группа: Администраторы
Сообщений: 1361
Репутация: 49
Статус: Offline
Привет всем!

Я знаю, что тех , кто использует FbEdit , очень раздражают кракозябры. Это заставляет совершать много лишних действий. После недавних дней кодинга, мое терпение кончилось и я решил разобраться с этой проблемой. Пришлось полностью пересобирать все ASM библиотеки. Дело в том, что FbEDIT.dll собирается из 7-ми статических библиотек. Уж не знаю, как там у Кетилло было все настроено, но по умолчанию нихера ничего не компилируется. И так и сяк пробовал подставлять пути, но каждый раз библиотеки требовали один и тот же путь к другой библиотеке. Я уж этот путь с нужной библиотекой и в папку с проектом подставлял и в папку с самими библиотеками и еще в кучу других папок пихал и даже глобальным делал на уровне системы, ничего не получалось. Вот если подсунуть им путь при компиляции их самих, то они прекрасно его видят и далее никаких ошибок. В итоге, чтобы внести небольшое дополнение в ASM код , пришлось пересобирать все статические библиотеки и только после этого пересобирать сам FbEdit.dll. Собранный файл выкладываю для тех кому нужно. Советую старый fbedit.dll переименовать и только после этого копировать fbedit.dll из архива в папку с редактором. Если будут какие косяки , которых не было с авторским fbedit.dll, пишите.
Прикрепления: FbEdit.zip (170.6 Kb)


Вы сохраняете власть над людьми покуда оставляете им что-то…Отберите у человека все, и этот человек уже будет неподвластен вам…
 
DarkDemonДата: Среда, 19.07.2017, 01:13 | Сообщение # 2
Полковник
Группа: Друзья
Сообщений: 188
Репутация: -2
Статус: Offline
Стас, а что за "крякозябры"? А то я что-то не в теме. Сам просто убрал плагин CP1251ToCP866.dll, это что-то с этим связанное?
Редактор потестим.
 
haavДата: Среда, 19.07.2017, 08:04 | Сообщение # 3
Генералиссимус
Группа: Администраторы
Сообщений: 1361
Репутация: 49
Статус: 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
Репутация: -2
Статус: Offline
Цитата haav ()
Вообще не знаю, зачем ты отключил данный плагин, если ты частенько работаешь с OEM?

Это был плагин в твоей сборке. У него был жёсткий косяк, уже точно не помню из-за чего, но информация
жёстко переводилась из одной кодировки в другую и портилась при сохранении(после того как я попортил
ряд своих файлов мне пришлось отключить эту штуку), это было связано с тем, что некоторые символы не могут
быть переведены в принципе т.к. не имеют соответствия.
Дело в том, что как раз больше работаю с OEM866 чем с UTF, потому что мне так проще писать собственные функции.
Из-за, в общем, того что часть системных функций написаны под другие кодировки это создаёт ряд
ощутимых сложностей(в каждом своём проекте в буквальном смысле трахаюсь с кодировками), вообще не занимался
этими вопросами с тех самых пор, когда у нас на форуме создавал тему про кодировки.

Цитата haav ()
Вставь скопированный текст в любой другой редактор (Notepad, AkelPad и пр.)

А понял. Было такое, знаешь как я делаю, вставляю текст в OpenOffice Writer и тут же копирую его
и уже вставляю куда мне надо. Бред, конечно. Сейчас авторский FBEdit найти не могу, с твоей сборкой
такого вроде нет, или же не знаю от чего это ещё может зависеть, только что скопировал в bred русский
текст который напечатал в FBEdit - всё нормально. Но подобные баги отчётливо помню. Просто всегда
под рукой Writer, на Word-е 2003-м тоже прокатывает.
 
haavДата: Четверг, 20.07.2017, 14:03 | Сообщение # 5
Генералиссимус
Группа: Администраторы
Сообщений: 1361
Репутация: 49
Статус: Offline
Цитата DarkDemon ()
Это был плагин в твоей сборке. У него был жёсткий косяк, уже точно не помню из-за чего, но информация
жёстко переводилась из одной кодировки в другую и портилась при сохранении(после того как я попортил
ряд своих файлов мне пришлось отключить эту штуку), это было связано с тем, что некоторые символы не могут
быть переведены в принципе т.к. не имеют соответствия.
Дело в том, что как раз больше работаю с OEM866 чем с UTF, потому что мне так проще писать собственные функции.
Из-за, в общем, того что часть системных функций написаны под другие кодировки это создаёт ряд
ощутимых сложностей(в каждом своём проекте в буквальном смысле трахаюсь с кодировками), вообще не занимался
этими вопросами с тех самых пор, когда у нас на форуме создавал тему про кодировки.


Леха, сможешь воспроизвести этот баг, желательно на видео? Я в принципе не понимаю, как может такое случится... Если сможешь , то так же неплохо бы и файл, который после работы с плагином как ты говоришь косячит.

Цитата DarkDemon ()
Сейчас авторский FBEdit найти не могу


Как это не можешь найти? FbEdit.dll всегда был авторским, я никогда до создания этой темы в него изменений не вносил.

P.S. Судя по тому, что отзывов в этой теме кроме твоих нет, народу пофиалетово. В принципе я исправлял баг в dll-ке для себя, чтобы не трахаться с крякозябрами. Ну а если другим нравится канителиться с другими редакторами, когда нужно скопировать что-то из FbEdit, пусть трахаются дальше.


Вы сохраняете власть над людьми покуда оставляете им что-то…Отберите у человека все, и этот человек уже будет неподвластен вам…
 
DarkDemonДата: Пятница, 21.07.2017, 13:18 | Сообщение # 6
Полковник
Группа: Друзья
Сообщений: 188
Репутация: -2
Статус: Offline
Цитата haav ()
Леха, сможешь воспроизвести этот баг, желательно на видео? Я в принципе не понимаю, как может такое случится...
Если сможешь , то так же неплохо бы и файл, который после работы с плагином как ты говоришь косячит.

Завтра попробую, просто сейчас компы местми меняю возьни много. Сам если честно уже не помню нюансов,
помню только что несколько файлов с русскими комментариями попортил в своё время(все коменты стали
нечитаемыми и восстановить переводом кодировок уже было нельзя). Очевидно что это было из-за специфики
кодинга.

Цитата haav ()
Судя по тому, что отзывов в этой теме кроме твоих нет, народу пофиалетово.

FBEdit-ом мало кто пользуется. Сам уж мирюсь в FBEdito-ом, потому что нет ничего более достойного.
Надо уже собраться с силами и написать редактор, помню одно время начал этим заниматься, но упёрся
в отсутствие нормального рабочего места и отложил это дело.
В идеале бы получить гибрид редактора QB4 + TurboPascal + BlitzBasic. Не новомодного, а DOS-подобного.
Причём мне лично отладчик и всякие плюшки не нужны, нужен просто удобный и привычный визуально редактор,
где я бы не тратил время на оформление кода и навигации по коду, а просто решал бы поставленные задачи.
 
quiet_snow_losДата: Среда, 26.07.2017, 17:14 | Сообщение # 7
Рядовой
Группа: Пользователи
Сообщений: 16
Репутация: 0
Статус: Offline
Добрался наконец-то до FB. Залогинился с грехом пополам через uid, правда ник какой-то стрёмный(я просто там
лосём обозвался и в конце он мне его дописал), ну да ладно.
Короче смотри:
https://yadi.sk/i/VnbOaoG93LRtHd

Не знаю может быть ты и фиксил как раз именно этот косяк.


Сообщение отредактировал quiet_snow_los - Среда, 26.07.2017, 17:15
 
haavДата: Среда, 26.07.2017, 20:26 | Сообщение # 8
Генералиссимус
Группа: Администраторы
Сообщений: 1361
Репутация: 49
Статус: Offline
Цитата quiet_snow_los ()
Добрался наконец-то до FB. Залогинился с грехом пополам через uid, правда ник какой-то стрёмный(я просто там
лосём обозвался и в конце он мне его дописал), ну да ладно.
Короче смотри:


Хорошо Леха. Спасибо, что записал видео. Хоть я очень редко работаю с OEM , но думаю меня тоже сильно расстроит, если в какой то момент при работе с OEM, испортится исходник. Буду думать, как исправить.

Цитата
Не знаю может быть ты и фиксил как раз именно этот косяк.


Нет. Авторский плагин вообще OEM не распознавал, да и сохранять не было возможности в этой кодировке.


Вы сохраняете власть над людьми покуда оставляете им что-то…Отберите у человека все, и этот человек уже будет неподвластен вам…
 
quiet_snow_losДата: Среда, 26.07.2017, 22:53 | Сообщение # 9
Рядовой
Группа: Пользователи
Сообщений: 16
Репутация: 0
Статус: Offline
Стас, да не запаривайся, это в принципе не мешает, т.к. отключаю плагин и нормально работаю.
Кстати по дефолту в твоей сборке он выключен.
Сейчас, на самом деле, ASCII 866 уже неактуален, с ним работают только старпёры потипа меня.

Сам просто использую ASCII, во-первых, потому что он очень прост и во-вторых - потому что не хочу
зависеть от сторонних шрифтов, так хотя бы знаю, что где бы прогу не запустил, на XP, на семёрке
или десятке - она заработает без изменений в шрифтах. Но вот при взаимодействии с функциями ОС
иногда случаются косячки - пожалуй это меньшая из жертв такого подхода. Конечно всё понимаю,
но, полагаю, вряд-ли кто-то сохранит имя файла китайскими иероглифами и прочими символами и будет
пытаться открывать его в проге, заточенной под OEM866, в остальных же случаях есть функции
конверсии(перевод в мультибайтовое представление и в целевую кодировку), которые вроде работают,
а в последнем своём проекте, помню, лихо набивал функцию конвертации CASE-ами, работало.

Проблемы обычно нет тогда, когда у программиста всё унифицировано под одну кодировку, а у меня ж
нифига не унифицировано, как куропатка прыгаю в bred и обратно. Хорошо хотя бы FBEdit есть,
он свой хлеб отрабатывает на 5 баллов.
 
haavДата: Четверг, 27.07.2017, 17:15 | Сообщение # 10
Генералиссимус
Группа: Администраторы
Сообщений: 1361
Репутация: 49
Статус: 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

Если бы автор внес перечисление форматов и возможность принудительного получения данных по указанному формату , в зависимости от кодировки исходного файла, то все работало бы как надо. В принципе все это можно сделать и возможно я займусь этим как только будет настроение. Тем более , что плагину очень не хватает возможности принудительно выбирать кодировку при загрузке файла. Автоматическое определение кодировки конечно хорошо, но вот в какой формат должен преобразовывать редактор, если его пользует такой человек как ты , смешивая форматы? smile

Прикрепления: 9332076.png (15.0 Kb)


Вы сохраняете власть над людьми покуда оставляете им что-то…Отберите у человека все, и этот человек уже будет неподвластен вам…
 
haavДата: Четверг, 27.07.2017, 19:30 | Сообщение # 11
Генералиссимус
Группа: Администраторы
Сообщений: 1361
Репутация: 49
Статус: 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...
Прикрепления: text.txt (0.1 Kb)


Вы сохраняете власть над людьми покуда оставляете им что-то…Отберите у человека все, и этот человек уже будет неподвластен вам…
 
quiet_snow_losДата: Пятница, 28.07.2017, 18:04 | Сообщение # 12
Рядовой
Группа: Пользователи
Сообщений: 16
Репутация: 0
Статус: 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
Репутация: 49
Статус: 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 и пипец (все символы в кракозябрах и обратно уже не вернуть). В жопу его smile


Вы сохраняете власть над людьми покуда оставляете им что-то…Отберите у человека все, и этот человек уже будет неподвластен вам…
 
haavДата: Суббота, 29.07.2017, 10:39 | Сообщение # 14
Генералиссимус
Группа: Администраторы
Сообщений: 1361
Репутация: 49
Статус: 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
Репутация: 0
Статус: Offline
Уважаемые форумчани внесу свои 2 копейки.
На WinXP 32 такой проблемы никогда не было.
Система Win7 64. Проблема та же самая. Внесение изменений в реестр по кодовой странице не помогло, но если при этом заменить файл "C:\Windows\System32\C_1252.NLS" на копию файла "C:\Windows\System32\C_1251.NLS" естественно переименовав, то после перезагрузки с кодировкой проблема пропала. Однако со временем (вероятно связано с восстановлением системных файлов) исходный файл восстанавливается.


Сообщение отредактировал TimurAR - Четверг, 11.01.2018, 22:22
 
Форум » Freebasic » Вопросы по языку FreeBasic » FbEdit без кракозябров (исправление)
  • Страница 1 из 2
  • 1
  • 2
  • »
Поиск: