снова про строки в 2.7.1

Вопросы программирования и использования среды Lazarus.

Модератор: Модераторы

снова про строки в 2.7.1

Сообщение zub » 08.01.2013 14:42:34

Код: Выделить всё
s: AnsiString;
...
s:=ConsoleToUTF8(AStringList.Text);
//Form1.Memo1.Text:=s1;//так работает
Form1.Memo1.Text := Form1.Memo1.Text + (s);//нужно так, но так не работает

Пытаюсь получить выхлоп TProcess, s получается валидной строкой с кирилицей, но при добавлении в Form1.Memo вместо кирилицы лезут вопросы, если просто присвоить - всё ок.

Методы из viewtopic.php?f=1&t=7719 не работают - s сразу получается с кривой кодировкой.
Система русская win7x64, кодировка файлов проекта - utf8 (в перемешку с bom и без bom)
zub
долгожитель
 
Сообщения: 2887
Зарегистрирован: 14.11.2005 23:51:26

Re: снова про строки в 2.7.1

Сообщение Padre_Mortius » 08.01.2013 14:44:37

а если использовать UTF8Copy?
Padre_Mortius
энтузиаст
 
Сообщения: 1265
Зарегистрирован: 29.05.2007 17:38:07
Откуда: Спб

Re: снова про строки в 2.7.1

Сообщение zub » 08.01.2013 14:54:50

в смысле так?
Код: Выделить всё
Form1.Memo1.Text := Form1.Memo1.Text + UTF8Copy(s,1,UTF8Length(s));

не работает((

Добавлено спустя 4 минуты 6 секунд:
а так
Код: Выделить всё
      s1:=UTF8Copy(Form1.Memo1.Text,1,UTF8Length(Form1.Memo1.Text))+UTF8Copy(s,1,UTF8Length(s));
      Form1.Memo1.Text :=s1;

в правильной кодировке только последняя добавленая строчка

Добавлено спустя 12 минут 25 секунд:
Заработало воттак:
Код: Выделить всё
      s:=ConsoleToUTF8(AStringList.Text);
      s:=utf8tosys(Form1.Memo1.Text)+s;
      Form1.Memo1.Text:=UTF8Copy(s,1,UTF8Length(s));

Ну и хрень((
zub
долгожитель
 
Сообщения: 2887
Зарегистрирован: 14.11.2005 23:51:26

Re: снова про строки в 2.7.1

Сообщение SSerge » 08.01.2013 18:32:38

zub писал(а):Ну и хрень((


А зря вы не читаете, что я пишу. Вот это например: http://sirserge.altai.info/articles/?id=45

В дополнение к сказанному, если файл исходника с BOM, компилятор включает кодирование всех строковых констант в 16-битный уникод, как и при директиве {$codepage UTF-8}, только это еще и нихрена не видно с первого взгляда. Не зря сказано: такое не делать!
SSerge
энтузиаст
 
Сообщения: 971
Зарегистрирован: 12.01.2012 05:34:14
Откуда: Барнаул

Re: снова про строки в 2.7.1

Сообщение zub » 08.01.2013 20:15:00

SSerge
>>А зря вы не читаете
Уже читаю, спасибо.

>> если файл исходника с BOM, компилятор включает кодирование всех строковых констант в 16-битный уникод
интересно зачем? исходники та в UTF8

>>Не зря сказано: такое не делать!
Не нашел как в delphi xe эту фишку отключить, исходники редактируются то там, то в лазаре.
но насколько понял в данном случае мне должна помочь {$modeswitch systemcodepage-}?
zub
долгожитель
 
Сообщения: 2887
Зарегистрирован: 14.11.2005 23:51:26

Re: снова про строки в 2.7.1

Сообщение SSerge » 09.01.2013 07:16:08

zub писал(а):интересно зачем? исходники та в UTF8


А затем, что товарищи из емберкадеры сделали Type string=UnicodeString и всё внутреннее представление информации в этих самых UnicodeString. Соответственно, экспериментальные версии fpc методично "подгоняются под оригинал". А модель программирования lazarus вообще не поддерживает маркированных строк и unicode-реализацию компилятора, там utf8 - поверх абстракции на байтовых строках.

zub писал(а):мне должна помочь {$modeswitch systemcodepage-}?

Вряд ли.
SSerge
энтузиаст
 
Сообщения: 971
Зарегистрирован: 12.01.2012 05:34:14
Откуда: Барнаул

Re: снова про строки в 2.7.1

Сообщение zub » 09.01.2013 07:48:10

>>А затем, что товарищи из емберкадеры сделали Type string=UnicodeString
Я про то почему они становятся
кодирование всех строковых констант в 16-битный уникод

исходники та что с бом что без бом остаются утф8, логичнее маркировать как utf8. Наличие бом легко не заметить (я заметил случайно что бом появился после сохранения файла в дельфи :? ) и сидеть гадать что за глюки.
zub
долгожитель
 
Сообщения: 2887
Зарегистрирован: 14.11.2005 23:51:26

Re: снова про строки в 2.7.1

Сообщение SSerge » 09.01.2013 08:00:58

Компилятор внутри себя работает либо в 16-битном уникоде, либо с немаркированными байтовыми строками. Логика в принципе сохраняется - есть BOM, значит файло в уникоде, соответствующим этому префиксу, а раз это не байтовые строки - то нужно тотчас преобразовать в стандартное внутреннее представление. :mrgreen: Я эту фишку, кстати, случайно заметил в описании новых фич на какой то новый релиз. Вот, сделали. :D

zub писал(а):я заметил случайно что бом появился после сохранения файла в дельфи

Ых, когда их по некоей причине этих меток в файле обнаружится несколько, то будет еще смешнее :D
Мне кажется, нужно просто сотворить простенькую утилитку, лишающие файлы bom-ов при передаче. Либо отложить дельфи далеко в сторону. :arrow:
SSerge
энтузиаст
 
Сообщения: 971
Зарегистрирован: 12.01.2012 05:34:14
Откуда: Барнаул

Re: снова про строки в 2.7.1

Сообщение zub » 09.01.2013 08:31:22

Мне кажется, нужно просто сотворить простенькую утилитку, лишающие файлы bom-ов при передаче. Либо отложить дельфи далеко в сторону.

так и сделаю. Но еще не помешал бы ключик для сборки свежих версий компилятора с поведением строк как в 2.6 иначе все форумы переполнятся подобными темами когда выйдет 2.8
zub
долгожитель
 
Сообщения: 2887
Зарегистрирован: 14.11.2005 23:51:26

Re: снова про строки в 2.7.1

Сообщение alexey38 » 10.01.2013 19:58:32

SSerge писал(а):если файл исходника с BOM, компилятор включает кодирование всех строковых констант в 16-битный уникод

Это временный глюк или постоянный? Ведь BOM для того и придуман, чтобы обозначать конкретный вариант кодировки. И мне кажется "товарищи из емберкадеры" вообще не причем, т.к. стандарты на то и стандарты, что их следует выполнять, тем более это на входе компилятора, т.е. учет BOM на мой взгляд очень прост.
alexey38
долгожитель
 
Сообщения: 1627
Зарегистрирован: 27.04.2011 19:42:31

Re: снова про строки в 2.7.1

Сообщение zub » 10.01.2013 23:36:04

alexey38
Мне это тоже кажется багом. ведь по сути файл с бомом и без не отличается и бом является лишним подтверждением utf8. Небудь этого "бага" никаких проблем бы небыло (былибы только утф8 строки и строки без кодировки) до появления в исходниках файла с другой кодировкой или прямого указания кодировки в исходниках.
zub
долгожитель
 
Сообщения: 2887
Зарегистрирован: 14.11.2005 23:51:26

Re: снова про строки в 2.7.1

Сообщение SSerge » 11.01.2013 05:04:19

alexey38 писал(а):Это временный глюк или постоянный? Ведь BOM для того и придуман, чтобы обозначать конкретный вариант кодировки.


Вот тут же два взаимных противоречия. Сами же пишете, что "BOM для того и придуман, чтобы обозначать конкретный вариант кодировки". Вот компилятор при наличии BOM и действует, как если бы ему влупили в исходник директиву {$codepage UTF8}. А вот то, что некоторые - читай разработчики lazarus - полностью игнорируют работу с кодировками, которую правильно поддерживает компилятор - и создает "странности". Однако, стоит к этому заметить, что текущий lazarus не предназначен к серьезной работе с компилятором 2.7.х, а только с 2.6, и по поводу BOM есть вполне определнные указания - де не должно присутствовать в исходниках. Точка. Как и директивы определения кодовых страниц.

Добавлено спустя 4 минуты 48 секунд:
BOM, кстати, отнюдь не обязательная метка юникодного файла. То, что ей принято метить файлы в продуктах Microsoft, не означает что "все делают так"

Зараз, если пошла такая тема, теоретически существует еще уникод с обратным расположением байтов, которое как раз BOM и показывает (и для чего он собственно и предназначен). Так вот, freepascal сам по себе, а также и строковые блблиотеки лазаруса сей факт признают несуществующим :D
SSerge
энтузиаст
 
Сообщения: 971
Зарегистрирован: 12.01.2012 05:34:14
Откуда: Барнаул

Re: снова про строки в 2.7.1

Сообщение alexey38 » 11.01.2013 07:40:32

SSerge писал(а):BOM, кстати, отнюдь не обязательная метка юникодного файла. То, что ей принято метить файлы в продуктах Microsoft, не означает что "все делают так"
Зараз, если пошла такая тема, теоретически существует еще уникод с обратным расположением байтов, которое как раз BOM и показывает (и для чего он собственно и предназначен). Так вот, freepascal сам по себе, а также и строковые блблиотеки лазаруса сей факт признают несуществующим

В любом текстовом файле может быть BOM. Читаешь первые несколько байт, смотришь соответствуют они одному из вариантов значений BOM. Если нет, то выбираешь кодировку по умолчанию. Если это BOM, то читаешь в той кодировке, в которой задано BOM. Если не умеешь читать и конвертировать некую кодировку, то выдаешь сообщение об ошибке компиляции, с сообщением, что исходный файл в конкретной кодировке не поддерживается, с предложением его перекодировать внешним инструментом, например, в UTF-8. На мой взгляд все очень просто. И такой анализ займет всего несколько строк кода в компиляторе, и такой код разработчиком пишется минут за 15, и не нужно даже влазить в дебри самого компилятора. А более правильный вариант, взял FileStream, если файл в не той кодировке, то создал MemoryStream и в него переконвертировал, в одну из поддерживаемых компилятором, далее уже в сам парсер компилятора передается просто Stream. Это немного больше, но на мой взгляд это также можно сделать за 1 день и на всегда закрыть проблему.
alexey38
долгожитель
 
Сообщения: 1627
Зарегистрирован: 27.04.2011 19:42:31

Re: снова про строки в 2.7.1

Сообщение SSerge » 11.01.2013 08:03:26

alexey38
Исходя из того, что сделано именно так, а не иначе можно сделать единственный вывод: разработчики fpc дословно копируют поведение компилятора Delphi, не больше и не меньше. Ньюанс лишь в том, что в дельфи все String=UnicodeString из-за чего в нем сей проблемы не заметно, а здесь - еще есть string в представлении turbo pascal и еще хрен знает каких реализаций паскаля. Поэтому компромисс и получается не очень. Плюс LCL, формально говоря, работающая "не по правилам".

Добавлено спустя 12 минут 41 секунду:
alexey38 писал(а):В любом текстовом файле может быть BOM. Читаешь первые несколько байт, смотришь соответствуют они одному из вариантов значений BOM. Если нет, то выбираешь кодировку по умолчанию. Если это BOM, то читаешь в той кодировке, в которой задано BOM. Если не умеешь читать и конвертировать некую кодировку, то выдаешь сообщение об ошибке компиляции, с сообщением, что исходный файл в конкретной кодировке не поддерживается, с предложением его перекодировать внешним инструментом, например, в UTF-8. На мой взгляд все очень просто. И такой анализ займет всего несколько строк кода в компиляторе, и такой код разработчиком пишется минут за 15, и не нужно даже влазить в дебри самого компилятора. А более правильный вариант, взял FileStream, если файл в не той кодировке, то создал MemoryStream и в него переконвертировал, в одну из поддерживаемых компилятором, далее уже в сам парсер компилятора передается просто Stream. Это немного больше, но на мой взгляд это также можно сделать за 1 день и на всегда закрыть проблему.


А чем отличается поведение компилятора от того, что вы тут описываете?
Он берет файл, находит в нем маркер UTF-8, перекодирует строки в свой внутренний формат и применяет их куда нужно. Если вы определили

Код: Выделить всё
     Var s:UnicodeString;
      s1:Utf8String;
      s2:AnsiString(1251);

...
    s:='строка';
    s1:='строка';
    s2:='строка';


- все присвоения будут правильными и в нужных кодировках.

Не находит маркера, - предполагает, что файл непонятно в какой кодировке и нужно во все переменные загрузить RawByte, то есть тот байтовый мусор, что есть в файле (если $codepage не определено) - вы же не сказали, к какой кодовой странице оно относится
SSerge
энтузиаст
 
Сообщения: 971
Зарегистрирован: 12.01.2012 05:34:14
Откуда: Барнаул

Re: снова про строки в 2.7.1

Сообщение alexey38 » 11.01.2013 08:54:35

SSerge писал(а):А чем отличается поведение компилятора от того, что вы тут описываете?

Если я правильно понял проблему, здесь описанную, что возникает конфликт между UTF-8 и UTF-16. И BOM в FPC определяет не только формат исходного файла, но и формат строк по умолчанию, хотя формат строк по умолчанию должен определяться параметрами и директивами компилятора, а не форматом исходного файла.
alexey38
долгожитель
 
Сообщения: 1627
Зарегистрирован: 27.04.2011 19:42:31

След.

Вернуться в Lazarus

Кто сейчас на конференции

Сейчас этот форум просматривают: Yandex [Bot] и гости: 240

Рейтинг@Mail.ru