Я офигеваю! RichEdit.

← →
nsvi (2003-02-06 01:38) [0]

В абсолютно одинаковых условиях в RichEdit файл 200 кб в кодировке Win загружается за 0,5 с, тот же файл, но в кодировке DOS грузится 1,5 минуты, файл 700 кб в Win за 1,5 с, в DOS - не дождался (больше 15 минут).
Это при загрузке в
RichEdit1.RE_LoadFromFile(filename,reText,false);
Пробовал через PStrList, в него-то грузится файл DOS махом, но передача в RichEdit занимает столько же времени, как и прямо в него. Какая ему разница какая кодировка? Ведь файл то текстовый, причем один и тот же?
D6,Duron-1000,256 мб

← →
Gandalf (2003-02-06 11:01) [1]

Код в студию! Например если сделать так:

RichEdit1.RE_LoadFromFile("DosOrWin.TXT",reText,False);

то два файла в любой кодировке грузятся одинаково.

← →
nsvi (2003-02-06 13:35) [2]

Так я же написал код, ну а сам файл текстовый, называется, к примеру в кодировке win "text1.txt", в кодировке dos - "text2.txt" - его не перешлешь. Код именно
RichEdit1.RE_LoadFromFile("text1.txt",reText,False);

← →
Gandalf (2003-02-06 13:52) [3]

> Так я же написал код

Пардон, проглядел...

У меня этот код работает, на ура.
WinXP,D5-7,KOlnMCK 1.64-5.

← →
Kladov (2003-02-06 19:54) [4]

> Какая ему разница какая кодировка?

Это надо у MS спросить. Не знаю как в XP, но в 2K пока именно так. Решить можно подменой riched32.dll на более раннюю или наоборот более позднюю, у которой нет такого заглюка (если получится). Или предварительным конвертированием из 866 в 1251. Например, так:

procedure TForm1.Button1Click(Sender: PObj);
var FS, MS: PStream;
S: PChar;
L: Integer;
begin
if OpenSaveDialog1.Execute then
begin
FS := NewReadFileStream( OpenSaveDialog1.Filename );
MS := NewMemoryStream;
Stream2Stream( MS, FS, FS.Size );
FS.Free;
S := MS.Memory;
for L := 1 to MS.Size do
begin
if S^ = #0 then S^ := " ";
Inc( S );
end;
S := MS.Memory;
MS.Position := 0;
OemToChar( S, S );
( MS, MS.Size, reText, FALSE )
> Какая ему разница какая кодировка?

Это надо у MS спросить. Не знаю как в XP, но в 2K пока именно так. Решить можно подменой riched32.dll на более раннюю или наоборот более позднюю, у которой нет такого заглюка (если получится). Или предварительным конвертированием из 866 в 1251. Например, так:

procedure TForm1.Button1Click(Sender: PObj);
var FS, MS: PStream;
S: PChar;
L: Integer;
begin
if OpenSaveDialog1.Execute then
begin
FS := NewReadFileStream( OpenSaveDialog1.Filename );
MS := NewMemoryStream;
Stream2Stream( MS, FS, FS.Size );
FS.Free;
S := MS.Memory;
for L := 1 to MS.Size do
begin
if S^ = #0 then S^ := " ";
Inc( S );
end;
S := MS.Memory;
MS.Position := 0;
OemToChar( S, S );
RichEdit1.RE_LoadFromStream( MS, MS.Size, reText, FALSE );
MS.Free;
end;
end;

Остается только придумать способ автоматически отличить текст в dos-кодировке от win-кодировки.

← →
nsvi (2003-02-07 00:53) [5]

Тут поэкспериментировал... Кусок файла 100 кб конвертировал в разные кодировки. Время загрузки в RichEdit:
в Win - 0,5 с;
в KOI - 0,5 с;
в MAC - 1 c;
в ISO - 1 с;
в DOS - 20 с.
За большую точность не ручаюсь, на глазок.
Ну теперь-то все ясно, автомат для перекодировки не проблема.

Попутно еще вопрос, что за свойство у RichEdit - Localizy (loForm, loNo, loYes)?

← →
SPeller (2003-02-07 06:59) [6]

> Попутно еще вопрос, что за свойство у RichEdit - Localizy
> (loForm, loNo, loYes)?

ООпределяет, будут ли строковые свойства данного контрола задаваться через resourcestring.

← →
nsvi (2003-02-07 07:05) [7]

Ну вот, сделал автораспознавание и перекодировку перед загрузкой в RichEdit, теперь DOS-файл 700 кб грузится за 5 с.
Спасибо за информацию.

← →
SerB (2003-02-07 13:54) [8]

nsvi -огласите весь список (киньте код)можно мылом
Кладову... качнул 1.60 и поочереди пропатчил (установил перекомпилировал) до 1.64 перестал работать KOLOledb ругается на несоответствие типов int64 и
I64... В чем может быть дело... Когда накладывал патчи никакой оугани не было?

← →
Alexander (2003-02-07 14:34) [9]

Когда я недавно переставил машину и установил все апдейты, то у меня пропало свойство BorderStyle для KolForm, которое появилось где-то в 1.62. Хотя всё проапдейтилось хорошо.

← →
Kladov (2003-02-07 18:35) [10]

Посмторите версию в самом mirror.pas, строка
**********...
* VERSION
**********...

Int64 заменен на I64 в kol.pas. Надо поправить KOLOLEDB. сегодня сделаю.

← →
nsvi (2003-02-08 01:24) [11]

> SerB (07.02.03 13:54)
> nsvi -огласите весь список (киньте код)можно мылом

извиняюсь, список чего и какой код?

← →
Gandalf (2003-02-08 13:14) [12]

> извиняюсь, список чего и какой код?

Я жумаю интересовались кодом, который выясняет кодировку текста. Или просто тут функцию (реализацию) которая "DOS-файл 700 кб грузится за 5 с"

← →
Kladov (2003-02-08 14:48) [13]

Любую кодировку выяснить так просто нельзя. Но для русского языка ansi или OEM в принципе можно. OEM русские буквы от $80 до $AF, а в ANSI от $C0 до $FF. Для программ вроде штилица, которым приходится уметь различать много кодировок, используются слоговые словари. Достаточно даже матрицы битов 128x128x128 где 1=допустимое буквосочетание. Например БАЛ - допустимое, а ЯЮЧ - нет. Остается подсчитать баллы, какой словарь дает больше допустимых трехбуквенных сочетаний, та и кодировка. Для того, чтобы составить такой словарь, достаточно прогнать нормальный текст, не содержащий слишком много опечаток, через фильтр, который построит такой словарь. Десятка мегабайт более чем достаточно, даже мегабайта текста хватит, лишь бы он был политературнее. Война и Мир Толстого хорошо подойдет.

← →
nsvi (2003-02-08 15:38) [14]

Конечно, со 100% гарантией нельзя определить кодировку, но я пользуюсь перекодировщиком уже месяца 2 и ни разу не было неудачно. Достаточно 5 кб и вероятнось 98%, я не оценивал.
Разные кодировки используют символы в разных диапазонах, DOS от 128 до 159 большие и от 160 до 175 и от 224 до 239 маленькие, Win держит большие от 192 до 223, маленькие от 224 до 255, KOI наоборот по сравнению с Win. Вроде можно различить. Так и различаю.

← →
nsvi (2003-02-08 16:16) [15]

Код конечно примитивный, но работает:
procedure TForm1.AutoCodir();
var
m128,m160,m176,m192,m224,m240,m208,n:integer;
st:string;
b:byte;
begin
if length(sn)>5000 then
st:=startcopy(sn,5000)
else
st:=sn;
m224:=0;
m192:=0;
m176:=0;
m160:=0;
m128:=0;
m240:=0;
m208:=0;

for n:=1 to length(st) do
begin
b:=ord(st[n]);
if b>239 then
inc(m240)
else
if b>223 then
inc(m224)
else
if b>207 then
inc(m208)
else
if b>191 then
inc(m192)
else
if b>175 then
inc(m176)
else
if b>159 then
inc(m160)
else
if b>127 then
inc(m128);
end;
{Если попадутся отдельные символы не в том диапазоне
избавимся от них}
m128:=m128 div 10;
m160:=m160 div 10;
m176:=m176 div 10;
m192:=m192 div 10;
m208:=m208 div 10;
m224:=m224 div 10;
m240:=m240 div 10;
if (m160>0) and (m224>0) then //DOS
DOStoWIN(sn)
else
if m176>0 then //ISO
ISOtoWIN(sn)
else
if (m128>0) and (m224>0) and (m240>0) then //MAC
MACtoWIN(sn)
else
if ((m192+m208)>0) and ((m240+m224)>0) and
((m192+m208)>(m240+m224))then //KOI
( sn) Код конечно примитивный, но работает:
procedure TForm1.AutoCodir();
var
m128,m160,m176,m192,m224,m240,m208,n:integer;
st:string;
b:byte;
begin
if length(sn)>5000 then
st:=startcopy(sn,5000)
else
st:=sn;
m224:=0;
m192:=0;
m176:=0;
m160:=0;
m128:=0;
m240:=0;
m208:=0;

for n:=1 to length(st) do
begin
b:=ord(st[n]);
if b>239 then
inc(m240)
else
if b>223 then
inc(m224)
else
if b>207 then
inc(m208)
else
if b>191 then
inc(m192)
else
if b>175 then
inc(m176)
else
if b>159 then
inc(m160)
else
if b>127 then
inc(m128);
end;
{Если попадутся отдельные символы не в том диапазоне
избавимся от них}
m128:=m128 div 10;
m160:=m160 div 10;
m176:=m176 div 10;
m192:=m192 div 10;
m208:=m208 div 10;
m224:=m224 div 10;
m240:=m240 div 10;
if (m160>0) and (m224>0) then //DOS
DOStoWIN(sn)
else
if m176>0 then //ISO
ISOtoWIN(sn)
else
if (m128>0) and (m224>0) and (m240>0) then //MAC
MACtoWIN(sn)
else
if ((m192+m208)>0) and ((m240+m224)>0) and
((m192+m208)>(m240+m224))then //KOI
KOItoWIN(sn);
{Иначе WIN}
end;

В строке SN - строка, кот. нужно перекодировать. Процедуры типа KOItoWIN(sn) работают с таблицами кодировок которых полно везде, и процедуры я не привожу.

← →
nsvi (2003-02-08 16:18) [16]

И последнее,
Проверил еще раз, секундомера, правда, нет, но ориентировочно грузятся:
Win -1,5 - 2 c;
KOI -1,5 - 2 c;
MAC - 2 c;
ISO - 2 c;
DOS - 2,5 - 3c;
Файл текстовый, книга, скачанная с Интернет в формате DOS, размер 708 кб. Повторю: Duron-1000, 256мб RAM, WinME. Перекодировал в другие кодировки в двух программах - не своих, свои не трогал.

← →
nsvi (2003-02-09 14:05) [17]

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

← →
mkal (2003-02-09 14:05) [18]

> Это надо у MS спросить. Не знаю как в XP, но в 2K пока именно
> так. Решить можно подменой riched32.dll на более раннюю
> или наоборот более позднюю, у которой нет такого заглюка
> (если получится). Или предварительным конвертированием из
> 866 в 1251.

У меня под XP (D7, KOL 1.64) глюк наблюдается во всей красе.
Вариант с перекодировкой меня не устраивает, поэтому хотелось бы узнать, как заменить riched32.dll. Что надо делать, чтобы моя программа работала с нормальным riched32.dll?

← →
nsvi (2003-02-09 15:36) [19]

Не пробовал, к сожалению. Может кто подскажет, где взять?

← →
Kladov (2003-02-09 19:02) [20]

Взять из установленного win98, положить в свою директорию, загрузить принудительно, указав точный путь. Причем загружать надо до того, как начнут создаваться контролы. Код можно добавить в <project_name>_0.inc (если MCK). Не пробовал, но не вижу причин, почему бы это не заработало. Только смысл? richedxxx.dll - он же большой. Таскать за собой такую громаду только чтобы не вставлять в программу полкилобайта кода (если только OEM->ANSI, то вряд ли будет больше).

← →
}{enon (2003-02-09 19:37) [21]

>Это надо у MS спросить.

Наверное, здесь народ из M$ поступил как обычно - грузится DOS-текст, а потом перекодируется во все кодировки форточек в хронологическом порядке (Win 95.0001, Win 95.0002 и т.д.) не разбирая отличаются они или нет :)
Вряд ли это именно так, но что-то больно много в Windows"e используется элементов предыдущих версий.

← →
Kladov (2003-02-09 20:23) [22]

Нет, просто он натыкаясь на сиволы OEM-кодировки, упорно пытается воспринимать их как двухбайтовые символы unicode.

← →
nsvi (2003-02-10 01:46) [23]

А ведь верно, с другим RichEdit будет работать только на твоем компе. Так что смысла нет, если предполагаешь работу и у других.
Тут вот что заметил, 100 кб за 20 с, тогда 700 должен за 2,5 минуты, а он за 15 и так и не дождался, может кусками загружать? Надо попробовать.

← →
MKal (2003-02-10 10:49) [24]

Ну, RichEdit весит меньше 100 Кб. Это в принципе не очень много.
Просто мне надо работать именно с кодировкой 866, причем с большими файлами (1-20 Мб). Так что для меня это лучший выход.

← →
nsvi (2003-02-10 13:44) [25]

Ничего не получится. Проверил загрузку блоками по 5кб, то же самое. Потом сделал цикл, где создается строки 200 кб, заполненые символами от 160 до 175 (в диапазоне, где тормоза) и грузится в RichEdit. Так вот, строка, начиненная символом 173 (буква "н" DOS) загрузка 2,5 минуты, загрузка со всеми остальными символами 1-2 с. Трудно сказать, что это за код для RichEdit и почему он на нем тормозит.
Поэтому ничего сделать тут нельзя, кроме как делать предварительное перекодирование в Windows-1251. Кстати, все равно в Виндовских программах работать с DOS-текстом невозможно, а сохранить потом результаты работы в DOS всегда пожалуйста.
Ну а если нужно, то другими методами. Кстати, проверил и в XP - то же самое. Так что пора прекращать дискуссию.

Я офигеваю! RichEdit. Найти похожие ветки