снова про строки в 2.7.1
Модератор: Модераторы
Re: снова про строки в 2.7.1
Описанная здесь проблема возникает из-за отсутствия поддержки в LCL строк с маркированной кодовой страницей и типа UnicodeString. Остальное - мыслепоток по поводу "почемубыне"
Re: снова про строки в 2.7.1
Для справки, BOM для UTF-8/16/32 свои и вполне определённые:
Код: Выделить всё
UTF-8 EF BB BF
UTF-16 (BE) FE FF
UTF-16 (LE) FF FE
UTF-32 (BE) 00 00 FE FF
UTF-32 (LE) FF FE 00 00
Re: снова про строки в 2.7.1
SSerge писал(а):Описанная здесь проблема возникает из-за отсутствия поддержки в LCL строк с маркированной кодовой страницей и типа UnicodeString.
А мне кажется, что вся проблема в том, что компилятор ошибочно использует формат исходного файла как признак типа строковых переменных. Мне кажется, что именно этот способ дефолтного задания типа - и есть причина всех косяков. В файле с ANSI кодировкой в тексте программы в ковычках может быть указана строка - 'строка', но компилятор ее должен воспринимать и перекодировать на этапе чтения файла, например, в UTF8, если этот тип строк для компилятора является дефолтным.
Re: снова про строки в 2.7.1
alexey38
Для того, чтобы лазарус и его строковые библиотеки работали, на текущий момент компилятор должен строки передавать "как есть", без попыток преобразовать во что-то, тем более UTF8 его кодировкой по умолчанию, тем более внутренним представлением данных, не является; когда начинаются перекодировки, строки, инициализированные в модулях с указанием кодовой страницы, приобретают признак кодовой страницы и начинается скрытое конвертирование при присвоениях другим строковым переменным из одной кодировки в другую, что приводит к неприемлемым результатам.
Вот это http://sirserge.altai.info/articles/?id=45 может наконец стоит прочитать, там детально разобрано, как обходить механизм конверсии
Для того, чтобы лазарус и его строковые библиотеки работали, на текущий момент компилятор должен строки передавать "как есть", без попыток преобразовать во что-то, тем более UTF8 его кодировкой по умолчанию, тем более внутренним представлением данных, не является; когда начинаются перекодировки, строки, инициализированные в модулях с указанием кодовой страницы, приобретают признак кодовой страницы и начинается скрытое конвертирование при присвоениях другим строковым переменным из одной кодировки в другую, что приводит к неприемлемым результатам.
Вот это http://sirserge.altai.info/articles/?id=45 может наконец стоит прочитать, там детально разобрано, как обходить механизм конверсии
Re: снова про строки в 2.7.1
SSerge писал(а):Вот это http://sirserge.altai.info/articles/?id=45 может наконец стоит прочитать, там детально разобрано, как обходить механизм конверсии
Так я и говорю, что это сделано плохо, т.е. ошибочно по самой философии. То есть первый косяк в том, что директива {$codepage} относится к любым строковым константам, хотя по смыслу должна была относится сугубо к обозначению кодовой страницы типа AnsiString и т.п. строк. К строкам типа UTF8, UTF16, UCS2 (UnicodeString, UTF8String) - такая директива не должна применяться.
Второй косяк в том, что BOM по какой-то странной логике носит тот же смысл что и директива {$codepage}.
Понятно, что если сегодня именно так, то то так. Вопрос - это на всегда, или это временно? Если временно - то можно подождать и не заморачиваться. Если это на всегда - то кроме Delphi ничего другое не применимо для работы с уникодом. По крайней мере мой опыт работы с дельфями говорит, что строковые типы там приводятся, как и любые другие типы, по типу получателя. Работая одновременно и с UnicodeString и AnsiString не возникает ни каких проблем, вне зависимости ни от формата файла (BOM), ни от чего-то другого. По крайней мере сообщения компилятора про преобразования строк разного типа не возникают в этом случае.