Строки в Unicode-версиях FreePascal

[SSerge]

Я, наконец, сделал это!

прошу заценить содержимое:
http://sirserge.altai.info/articles/?id=44

боюсь, многих ждут серьезные раздумья о путях эволюции и пройденных путях.

Если видите логические (не орфографические!) ошибки, прошу комментировать.

Черт его знает, может быть не там искал, но я этого в приложении именно к FreePascal нигде найти не мог, пришлось самому изыскивать.

[hinst]

наконец-то дельная статья по юникоду во фрипаскале.
//у меня FPC 2.7.1 иногда падает с Internal Error

[SSerge]

Никто ляпов не заметил?
Я два незначительных заметил, устранил.
Теперь можно что ль продвигать текст к публикации на freepascal.ru?

[Павел Ишенин]

Можно на lazarus.freepascal.org

[Vadim]

SSerge
Я читал по быстрому, вроде нормально.

[Aleksey Elin]

Я правильно понял из статьи, что строки RawByteString вовсе не "raw byte" а всего лишь строки с одноразовой инициализацией? Если это так, то очень грустно
Попутно второй вопрос, если в строку UTF8String "запихать случайные байты" (нарушающие спецификацию UTF8) а затем склить ее с другой строкой UTF8String и присвоить третей строке UTF8String - будет ли эксепшен? Т.е. проверются ли данные при операциях со строками одной кодировки?
Если нет, то получается если использовать во всей программе только строки UTF8String - они будут вести себя как "raw byte"?

[SSerge]

Я правильно понял из статьи, что строки RawByteString вовсе не "raw byte" а всего лишь строки с одноразовой инициализацией?

Алексей, мне сложно судить о том, что должно быть "истинным raw byte".
Но в fpc это отнюдь не строки с одноразовой инициализацией. Более того, это единственный строковый тип, к содержимому которого вы можете применить процедуру замены кодовой страницы - SetCodePage - с конверсией содержимого или без оного. Другое дело, что при операциях присвоения они сохраняют эту самую установленную кодовую страницу (если она установлена).

Попутно второй вопрос, если в строку UTF8String "запихать случайные байты" (нарушающие спецификацию UTF8) а затем склить ее с другой строкой UTF8String и присвоить третей строке UTF8String - будет ли эксепшен? Т.е. проверются ли данные при операциях со строками одной кодировки?

Данные строк при операциях конкантенации imho вообще никак не контролируются. Если же в процессе будет задействованы операции преобразования кодовой страницы, то безусловно, ваши неправильные UTF8String будут в результате искажены. Но в вашем примере - просто будут слиты со всеми ошибками кодирования utf; exception, останавливающей программу, не будет в любом случае. Данные портятся тихо и незаметно.

[Aleksey Elin]

Алексей, мне сложно судить о том, что должно быть "истинным raw byte".

"raw byte" переводится как "сырые байты", "сырые данные". Логично было бы ожидать что RawByteString строка без какой либо кодировки вообще (т.е. аналог "классической" AnisString).

Но в fpc это отнюдь не строки с одноразовой инициализацией. Более того, это единственный строковый тип, к содержимому которого вы можете применить процедуру замены кодовой страницы

Получается что:
- RowByteString - это единственная строка с "переменной" кодировкой.
- AnsiString - это строка с фиксированной кодировкой получаемой при присовении.
- "Пользовательские" строки - строки с фиксированной кодировкой получаемой при объявлени.

Данные строк при операциях конкантенации imho вообще никак не контролируются... ...Данные портятся тихо и незаметно.

Т.е. если использовать во всей программе единый пользовательский тип (лучший вариант по видимому UTF8String), то проблем со старым кодом быть не должно.
Надо лишь не забывать конвертировать данные на "входе" и не присваивать "некорректные" данные UnicodeString-ам.

[SSerge]

Логично было бы ожидать что RawByteString строка без какой либо кодировки вообще (т.е. аналог "классической" AnisString).

Структурный тип, описывающий строку AnsiString, в уникодных версиях rtl всегда соедржит поле, описывающее кодировку. Если кодировки нет - это CP_NONE. Если установлена эта кодировка, символы не преобразуются при применении операторов read/write на консоль и в файл. Я имел в виду то, что я не исследовал поведения RawByteString в дельфи, т.е. в прототипе, поведение которого старательно копируется.

Получается что:
- RowByteString - это единственная строка с "переменной" кодировкой.
- AnsiString - это строка с фиксированной кодировкой получаемой при присовении.

Нет. RawByteString = AnsiString(CP_NONE). Если в нее копируется строка с установленным флагом кодовой страницы, она в дальнейшем приобретает эту кодовую страницу и работает с ней, если флаг не сбросить через SetCodePage опять же в CP_NONE.

Т.е. если использовать во всей программе единый пользовательский тип (лучший вариант по видимому UTF8String), то проблем со старым кодом быть не должно.

проблем со старым кодом и так в основном быть не должно, если не инициализировать "механизм уникодности" прямым указанием компилятору, с текстом в какой кодовой странице он работает. На чем и основано функционирование, например, лазаруса. Его библиотеки UnicodeStings и кодовые страницы AnsiStrings тихо игнорируют, и обычно это не отражается чем то необычным. Опять же, смотрим прототип. В Delphi XE2 String==UnicodeString. К вопросу о "лучшем варианте". UTF8String отнюдь не лучший выбор для будущего, ибо не позволяет индексирования лексических единиц в строке стандартными средствами. Нет, работать с символами UTF8 можно, но - это функционал библиотек LCL а не FPC, и сильно страдает читабельность кода.

[Aleksey Elin]

Структурный тип, описывающий строку AnsiString, в уникодных версиях rtl всегда соедржит поле, описывающее кодировку.

Да, я это понимаю.

RawByteString = AnsiString(CP_NONE). Если в нее копируется строка с установленным флагом кодовой страницы, она в дальнейшем приобретает эту кодовую страницу и работает с ней, если флаг не сбросить через SetCodePage опять же в CP_NONE.

Да, спасибо, я примерно так и понял.

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

Я часто использую AsniString для обработки текста в неизвестных и/или еще не определенных кодировках, для первоначального парсинга бинарных/смешанных файлов и т.п. "Классические" AnsiString для этого очнь удобны. Теперь придется учитывать что Ansi-строка может содержать информацию о кодировке, что изменяет семантику кода (к сожалению ).
Но в целом как с этим "боротся" примерно понятно.

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

Конечно! Речь в основном о старом коде и "сырых" данных. И о том чтобы избежать "автоматических перекодировок" в этом старом коде на которые он никак не расчитан.
Для обработки готового текста предпочтительным естетсвенно является UnicodeString.

Большое спасибо за разъяснения.