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

[zub]

Код: Выделить всё

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)

[Padre_Mortius]

а если использовать UTF8Copy?

[zub]

в смысле так?

Код: Выделить всё

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));

Ну и хрень((

[SSerge]

Ну и хрень((

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

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

[zub]

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

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

>>Не зря сказано: такое не делать!
Не нашел как в delphi xe эту фишку отключить, исходники редактируются то там, то в лазаре.
но насколько понял в данном случае мне должна помочь {$modeswitch systemcodepage-}?

[SSerge]

интересно зачем? исходники та в UTF8

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

мне должна помочь {$modeswitch systemcodepage-}?

Вряд ли.

[zub]

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

кодирование всех строковых констант в 16-битный уникод

исходники та что с бом что без бом остаются утф8, логичнее маркировать как utf8. Наличие бом легко не заметить (я заметил случайно что бом появился после сохранения файла в дельфи ) и сидеть гадать что за глюки.

[SSerge]

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

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

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

[zub]

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

так и сделаю. Но еще не помешал бы ключик для сборки свежих версий компилятора с поведением строк как в 2.6 иначе все форумы переполнятся подобными темами когда выйдет 2.8

[alexey38]

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

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

[zub]

alexey38
Мне это тоже кажется багом. ведь по сути файл с бомом и без не отличается и бом является лишним подтверждением utf8. Небудь этого "бага" никаких проблем бы небыло (былибы только утф8 строки и строки без кодировки) до появления в исходниках файла с другой кодировкой или прямого указания кодировки в исходниках.

[SSerge]

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

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

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

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

[alexey38]

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

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

[SSerge]

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

Добавлено спустя 12 минут 41 секунду:

В любом текстовом файле может быть 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 не определено) - вы же не сказали, к какой кодовой странице оно относится

[alexey38]

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

Если я правильно понял проблему, здесь описанную, что возникает конфликт между UTF-8 и UTF-16. И BOM в FPC определяет не только формат исходного файла, но и формат строк по умолчанию, хотя формат строк по умолчанию должен определяться параметрами и директивами компилятора, а не форматом исходного файла.