Sign in Join
Wiki copytemporary

Unicode Support in Lazarus/ru: what changed

Revision 0 to 1. Removed lines have a minus sign; added lines have a plus sign.

Title: Unicode Support in Lazarus/ru

OldNewLine
1+# Введение
2+
3+Здесь описывается поддержка Unicode в «программах» Lazarus (консольных или серверных, без графического интерфейса) и «приложениях» (GUI с использованием LCL) при использовании особенностей FPC 3.0+.
4+
5+Решение является кросс-платформенным и использует кодировку UTF-8, которая отличается от UTF-16 Delphi, но вы можете написать код, полностью совместимый с Delphi на уровне исходного кода, запомнив лишь несколько правил.
6+
7+Поддержка Unicode включается автоматически для приложений LCL начиная с Lazarus 1.6.0 при компиляции с FPC 3.0+.
8+
9+Старый метод поддержки UTF-8 в LCL при использовании FPC версий до 2.6.4 включительно, описан здесь: [[LCL Unicode Support]]
10+
11+## RTL с кодовой страницей UTF-8 по умолчанию
12+
13+По умолчанию RTL использует системную кодовую страницу для AnsiStrings (в таких операциях, как например FileExists и TStringList.LoadFromFile). Под Windows это не-Unicode кодировка, поэтому могут использоваться только символы из текущей языковой группы (не более 256 символов). LCL, с другой стороны, работает с кодировкой UTF-8, охватывающей весь диапазон Unicode. Под Linux и macOS UTF-8 обычно является системной кодовой страницей, и здесь RTL использует по умолчанию CP_UTF8.
14+
15+FPC, начиная с версии 3.0, обеспечивает API для изменения кодовой страницы RTL по умолчанию на другое значение. Lazarus (конкретно пакет LazUtils) использует данный API и изменяет кодовую страницу RTL по умолчанию на UTF-8 (CP_UTF8). Это означает, что пользователи Windows также могут теперь использовать строки UTF-8 в RTL.
16+
17+- Например, FileExists и StringList.LoadFromFile(Filename) теперь имеют полную поддержку Unicode. См. Полный перечень функций, которые полносттью поддерживают Unicode, здесь:
18+
19+[[FPC Unicode support|RTL changes]]
20+
21+- *AnsiToUTF8, UTF8ToAnsi, SysToUTF8, UTF8ToSys* не работают (не изменяют передаваемых данных). Эти функции обычно использовались для упомянутых выше функций RTL, которые больше не нуждаются в преобразованиях. Относящееся к функциям WinAPI, см ниже.
22+- Многочисленные вызовы *UTF8Encode* и *UTF8Decode* больше не требуются, потому что такие действия при присваивании значений *UnicodeString* переменным типа String и наоборот компилятор делает автоматически.
23+- При работе с WinAPI необходимо использовать "W"-функции или пользоваться функциями **UTF8ToWinCP** и **WinCPToUTF8**. То же верно для библиотек, которые до сих пор используют Ansi WinAPI функции. Например, в FPC 3.0 и более ранних версиях в этом нуждается unit registry.
24+- "String" и "UTF8String" — различные типы. Если вы присваиваете значение *String* переменной типа *UTF8String*, компилятор добавляет код для проверки совпадения кодировок. Это будет стоить дополнительного времени исполнения и увеличит размер кода. Просто используйте *String* вместо *UTF8String*.
25+- Консоль Windows использует кодировку, которая может отличаться от системной (в случае русского языка это всегда именно так). **writeln** в FPC 3.0+ автоматически преобразует строки UTF-8 в кодовую страницу консоли. Некоторые консольные программы Windows ожидают на входе строки в кодировке консоли и результаты своей работы также выдают в кодовой странице консоли. Для соответствующего преобразования можно использовать функции **UTF8ToConsole** и **ConsoleToUTF8**.
26+
27+Дополнительная информация о новинках поддержки Unicode в FPC: [[FPC Unicode support]]
28+
29+# Использование
30+
31+Следуйте простым правилам:
32+
33+- Используйте как обычно тип "String" вместо UTF8String или UnicodeString.
34+- Всегда присваивайте константу переменной типа String.
35+- Используйте тип UnicodeString явно для вызовов API, когда это необходимо.
36+
37+Эти правила делают большую часть кода уже совместимым с Delphi при использовании настроек проекта по умолчанию.
38+
39+## Применение в Lazarus
40+
41+Новый режим включается автоматически при компиляции FPC 3.0+. Это поведение может быть отключено директивой компиляции **-dDisableUTF8RTL**, детали см. на странице [[Lazarus with FPC3.0 without UTF-8 mode]].
42+
43+Если вы используете строковые литералы в новом режиме, ваши исходники всегда должны быть в кодировке UTF-8. Однако, ключ **-FcUTF8** на самом деле обычно не требуется. Дополнительные сведения приведены ниже, в разделе "Строковые литералы".
44+
45+Что же на самом деле происходит в новом режиме? В секции предварительной инициализации вызываются две FPC функции, устанавливающие кодировку строк по умолчанию в исполняющих библиотеках FPC в UTF-8 :
46+
47+` SetMultiByteConversionCodePage(CP_UTF8);`\
48+` SetMultiByteRTLFileSystemCodePage(CP_UTF8);`
49+
50+Кроме того, функции UTF8...() из LazUTF8 (LazUtils) устанавливаются в качестве функций обратного вызова для функций RTL, имена которых начинаются с Ansi...().
51+
52+## Использование UTF-8 в программах без LCL
53+
54+В не LCL-проекте добавьте зависимость для пакета **LazUtils**. Затем добавьте модуль **LazUTF8** в секцию uses основного файла программы. Он должен быть в начале, сразу после критических менеджеров памяти и многопоточности (например, cmem, heaptrc, cthreads).
55+
56+# Вызов функций API, которые используют WideString или UnicodeString
57+
58+Если тип параметра WideString или UnicodeString, вы можете просто передать ему строку. Компилятор преобразует данные автоматически. Появится предупреждение о преобразовании из AnsiString в UnicodeString, которое можно либо проигнорировать, либо подавить, приведя тип String к UnicodeString.
59+
60+Переменная S в приведенных ниже примерах определяется как String, что здесь означает AnsiString.
61+
62+``` pascal
63+procedure ApiCall(aParam: UnicodeString); // Определение
64+ ...
65+ApiCall(S); // вызов со строкой S, игнорируя предупреждение.
66+ApiCall(UnicodeString(S)); // вызов со строкой S, подавляя предупреждение (приведение String к UnicodeString).
67+```
68+
69+Когда тип параметра является указателем PWideChar, вам нужна временная переменная UnicodeString. Присвойте ей свою строку. Затем компилятор преобразует эти данные. Затем введите временную переменную в PWideChar.
70+
71+``` pascal
72+procedure ApiCallP(aParamP: PWideChar); // Определение
73+ ...
74+var Tmp: UnicodeString; // Временная переменная
75+ ...
76+Tmp := S; // Присваиваем String -> UnicodeString.
77+ApiCallP(PWideChar(Tmp)); // Вызов переменной temp, приведение к указателю
78+```
79+
80+> **Note:** в обоих случаях код совместим с Delphi. Это означает, что вы можете скопировать/вставить его в Delphi, и он сработает на 100% правильно. В Delphi String проецируется в UnicodeString.
81+
82+Типичным случаем является вызов Windows API. Только должны вызываться их версии "W", потому что они поддерживают Unicode. Обычно используйте UnicodeString также с Windows API. WideString необходим только при программировании COM/OLE, где ОС заботится об управлении памятью.
83+
84+# Чтение / запись текстового файла с кодовой страницей Windows
85+
86+Это не совместимо ни с Delphi, ни с прежним кодом Lazarus. На практике вы должны инкапсулировать код, связанный с системной кодовой страницей, и преобразовать данные в UTF-8 как можно быстрее.
87+
88+**Либо используйте RawByteString и сделайте явное преобразование...**
89+
90+``` pascal
91+uses ... , LConvEncoding;
92+ ...
93+var
94+ StrIn: RawByteString;
95+ StrOut: String;
96+ ...
97+StrOut := CP1252ToUTF8(StrIn,true); // Использует фиксированную кодовую страницу
98+// или
99+StrOut := WinCPToUTF8(StrIn,true); // Использует системную кодовую страницу на этом конкретном компьютере
100+```
101+
102+**... или установите правильную кодовую страницу для существующей строки**
103+
104+``` pascal
105+var
106+ StrIn: String;
107+ ...
108+SetCodePage(RawByteString(StrIn), 1252, false); // Фиксированная 1252 (или Windows.GetACP())
109+```
110+
111+> **Note:** в строковой переменной должен быть какой-то текст. Пустая строка на самом деле является указателем Nil, и вы не можете установить ее кодовую страницу.
112+
113+Windows.GetACP() возвращает системную кодовую страницу Windows.
114+
115+# Код, который очень сильно зависит от кодовой страницы Windows
116+
117+Существует «план B» для кода, который очень сильно зависит от системной кодовой страницы Windows или должен записываться в консоль Windows за пределами кодовой страницы консоли.\
118+См.: [[Lazarus with FPC3.0 without UTF-8 mode|Lazarus с FPC3.0 без режима UTF-8]].\
119+К счастью, это нужно нечасто. В большинстве случаев проще конвертировать данные в UTF-8.
120+
121+## Запись в консоль
122+
123+Вывод консоли Windows работает корректно, **если** ваши символы принадлежат кодовой странице консоли. Например, символ для рисования рамки `'╩'` в кодовой странице CP437 составляет один байт **\#202** и часто используется так:
124+
125+``` pascal
126+write('╩');
127+```
128+
129+Когда вы конвертируете код в UTF-8, например, используя пункт всплывающего меню редактора исходного кода Lazarus **File Settings (Параметры файла) / Encoding (Кодировка) / UTF-8**, и нажимая кнопку диалога "Change file on disk" (Изменить файл на диске), символ `'╩'` становится 3-х байтным (#226#149#169), поэтому литерал становится *строкой*.
130+
131+Процедуры *write* и *writeln* преобразуют строку UTF-8 в текущую кодовую страницу консоли. Таким образом, ваша консольная программа теперь выводит `'╩'` в Windows с любой кодовой страницей (т.е. не только с CP437), и она даже работает в Linux и macOS. Вы также можете использовать `'╩'` в строках LCL, например, Memo1.Lines.Add(`'╩'`);
132+
133+Если ваши символы **не** принадлежат кодовой странице консоли, все усложняется. Тогда вы вообще не сможете использовать новую систему Unicode.\
134+См.: [[Lazarus with FPC3.0 without UTF-8 mode|Проблема Системной кодировки и Консольной кодировки (Windows)]]
135+
136+# Символы Юникода и кодовые точки в коде
137+
138+См. детали для UTF-8 в [[UTF8 strings and characters/ru|UTF8 strings and characters]].
139+
140+## Функции кодовых точек для кодирования независимого кода
141+
142+В пакете LazUtils есть **модуль LazUnicode** со специальными функциями для работы с кодовыми точками, независимо от кодировки. Они используют функции UTF8...() из LazUTF8 при использовании в режиме UTF-8, и функции UTF16...() из LazUTF16 при использовании в {\$ModeSwitch UnicodeStrings} FPC или в Delphi (да, Delphi поддерживается!).
143+
144+В настоящее время {\$ModeSwitch UnicodeStrings} можно протестировать, задав "UseUTF16". Также есть тестовая программа LazUnicodeTest в каталоге components/lazutils/test. Она имеет 2 режима сборки, UTF8 и UTF16, для удобства тестирования. Тестовая программа также поддерживает Delphi, тогда, очевидно, используется режим UTF-16.
145+
146+LazUnicode позволяет одному исходному коду работать между:
147+
148+- Lazarus с его UTF-8 решением.
149+- Будущие FPC и Lazarus с Delphi-совместимым решением UTF-16.
150+- Delphi, где String = UnicodeString.
151+
152+Это обеспечивается перечисленными ниже функциями, не зависящим от кодирования:
153+
154+- `CodePointCopy()` - аналогична `UTF8Copy()`
155+- `CodePointLength()` - аналогична `UTF8Length()`
156+- `CodePointPos()` - аналогична `UTF8Pos()`
157+- `CodePointSize()` - аналогична `UTF8CharacterLength()` (функция устарела. Вместо нее используйте `UTF8CodepointSize`. [См. подробнее](https://lazarus-ccr.sourceforge.io/docs/lazutils/lazutf8/utf8characterlength.html))
158+- `UnicodeToWinCP()` - аналогична `UTF8ToWinCP()`
159+- `WinCPToUnicode()` - аналогична `WinCPToUTF8()`
160+
161+Этот режим также предоставляет перечислитель для кодовых точек, который компилятор использует для цикла for-in. В результате, независимо от кодировки, этот код работает:
162+
163+``` pascal
164+ var s, ch: String;
165+ ...
166+ for ch in s do
167+ writeln('ch=',ch);
168+```
169+
170+Delphi не предоставляет аналогичные функции для CodePoints в своем решении UTF-16. Практически большая часть кода Delphi рассматривает UTF-16 как кодировку с фиксированной шириной, что привело к возникновению большого количества неработающего кода UTF-16. Это означает, что использование LazUnicode также для Delphi улучшит качество кода!
171+
172+Для использования Delphi необходимы оба модуля LazUnicode и LazUTF16.
173+
174+# Строковые литералы
175+
176+Исходный код должен сохраняться в кодировке UTF-8. Lazarus создает такие файлы по умолчанию. Вы можете изменять кодировку импортированных файлов, щелкая правой кнопкой мыши в редакторе исходного кода / File Settings (Настройки файла) / Encoding (Кодировка).
177+
178+Обычно директива `{$codepage utf8} / -FcUTF8` не требуется. Это довольно нелогично, поскольку значение этого флага заключается в обработке строковых литералов как UTF-8. Однако новый режим UTF-8 переключает кодирование во время выполнения, а константы оцениваются во время компиляции.
179+
180+Таким образом, без `-FcUTF8` компилятор (ошибочно) считает, что строковая константа кодируется системной кодовой страницей. Затем он видит переменную String с кодировкой по умолчанию (которая будет изменена на UTF-8 во время выполнения, но компилятор этого не знает). Таким образом, то же для кодировки по умолчанию, преобразование не требуется, компилятор с радостью копирует символы, и все идет хорошо, в то время как на самом деле его дважды обманывали в течение процесса.
181+
182+**Пример:**
183+
184+По правилу шаловливых ручек, используйте тип «String» и заставляйте литералы работать.
185+
186+``` pascal
187+const s1 = 'äй';
188+const s2: string = #$C3#$A4; // ä
189+var s3;
190+...
191+ s3 := 'äöü';
192+```
193+
194+> **Note:** Строка UTF-8 может состоять из чисел, как это продемонстрировано для s2.
195+
196+- Литералы AnsiString/String работают как с директивой {\$codepage utf8} / -FcUTF8 , так и без неё.
197+
198+``` pascal
199+const s: string = 'äй';
200+```
201+
202+- Литералы ShortString работоспособны только **без** указания директивы {\$codepage utf8} / -FcUTF8. Вы можете сделать следующее:
203+
204+``` pascal
205+unit unit1;
206+{$Mode ObjFPC}{$H+}
207+{$modeswitch systemcodepage} // прекращает действие директивы -FcUTF8
208+interface
209+const s: string[15] = 'äй';
210+end.
211+```
212+
213+В качестве альтернативы, возможно использовать строки shortstring с включенной директивой \$codepage путем прямого присвоения кодов символов:
214+
215+``` pascal
216+unit unit1;
217+{$Mode ObjFPC}{$H+}
218+{$codepage utf8}
219+interface
220+const s: String[15] = #$C3#$A4; // ä
221+end.
222+```
223+
224+- WideString/UnicodeString/UTF8String работают только **с** {\$codepage utf8} / -FcUTF8.
225+
226+``` pascal
227+unit unit1;
228+{$Mode ObjFPC}{$H+}
229+{$codepage utf8}
230+interface
231+const ws: WideString = 'äй';
232+end.
233+```
234+
235+Присвоение строкового литерала другим строковым типам, кроме простого «String», более мудрено. Смотрите таблицы, что работает, а что нет.
236+
237+## Присвоение строковых литералов различным типам строк
238+
239+Здесь *работает* означает правильную кодовую страницу и правильные кодовые точки. Кодовая страница 0 или кодовая страница 65001 - обе являются правильными, они означают UTF-8.\
240+
241+### Без {\$codepage utf8} или переключателя компилятора -FcUTF8
242+
243+| Тип String, исходник в UTF-8 | Пример | Const (в исходнике) | Присвоение String | Присвоение UTF8String | Присвоение UnicodeString | Присвоение CP1252String | Присвоение RawByteString | Присвоение ShortString | Присвоение PChar |
244+|----|----|----|----|----|----|----|----|----|----|
245+| const | const s = 'äöü'; | working | working | wrong | wrong | wrong | working | working | working |
246+| String | const s: String = 'äöü'; | working | working | working | working | working | working | working | working |
247+| ShortString | const s: String\[15\] = 'äöü'; | working | working | working | working | wrong encoded | working | working | not available |
248+| UTF8String | const s: UTF8String = 'äöü'; | wrong | wrong | wrong | wrong | wrong | wrong | wrong | wrong |
249+| UnicodeString | const s: UnicodeString = 'äöü'; | wrong | wrong | wrong | wrong | wrong | wrong | wrong | wrong |
250+| String с объявленной кодовой страницей | type CP1252String = type AnsiString(1252); | wrong | wrong | wrong | wrong | wrong | wrong | wrong | wrong |
251+| RawbyteString | const s: RawbyteString = 'äöü'; | working | working | working | working | to codepage 0 changed | working | working | working |
252+| PChar | const c: PChar = 'äöü'; | working | working | working | working | wrong | working | working | working |
253+
254+### С {\$codepage utf8} или переключателем компилятора -FcUTF8
255+
256+| Тип String, исходник в UTF-8 | Пример | Const (в исходнике) | Присвоение String | Присвоение UTF8String | Присвоение UnicodeString | Присвоение CP1252String | Присвоение RawByteString | Присвоение ShortString | Присвоение PChar |
257+|----|----|----|----|----|----|----|----|----|----|
258+| const | const s = 'äöü'; | UTF-16 encoded | working | working | working | working | working | working | working |
259+| String | const s: String = 'äöü'; | working | working | working | working | working | working | working | working |
260+| ShortString | const s: String\[15\] = 'äöü'; | wrong | wrong | wrong | wrong | wrong | wrong | wrong | not available |
261+| UTF8String | const s: UTF8String = 'äöü'; | working | working | working | working | working | working | working | working |
262+| UnicodeString | const s: UnicodeString = 'äöü'; | working | working | working | working | working | working | working | wrong |
263+| String с объявленной кодовой страницей | type CP1252String = type AnsiString(1252); | working | working | working | working | working | working | wrong | wrong |
264+| RawbyteString | const s: RawbyteString = 'äöü'; | working | working | working | working | to codepage 0 changed | working | working | working |
265+| PChar | const c: PChar = 'äöü'; | wrong | wrong | wrong | wrong | wrong | wrong | wrong | wrong |
266+
267+Помните, что присваивание между переменными разных типов строк всегда работает благодаря их динамическому кодированию в FPC 3+. Данные конвертируются автоматически при необходимости.\
268+Только строковые литералы являются проблемой.
269+
270+# Переход из более старых версий Lazarus + LCL
271+
272+Ранее (до 1.6.0) LCL поддерживал Unicode с выделенными функциями UTF8. Код не был совместим с Delphi.
273+
274+Сейчас многие старые приложения LCL продолжают работать без изменений. Однако имеет смысл очистить код, чтобы сделать его более простым и более совместимым с Delphi. Код, который читает/записывает данные с использованием кодировки системной кодовой страницы Windows, нарушается и должен быть изменен. (См. [[Unicode Support in Lazarus/ru|Чтение / запись текстового файла с кодовой страницей Windows]]).
275+
276+Явные функции преобразования необходимы только для ввода-вывода с данными кодовой страницы Windows или при вызове функций Windows Ansi. В противном случае FPC позаботится о автоматическом преобразовании кодировок. Для преобразования вашего старого кода предусмотрены пустые функции преобразования.
277+
278+- UTF8Decode, UTF8Encode - Почти все можно удалить.
279+- UTF8ToAnsi, AnsiToUTF8 - Почти все можно удалить.
280+- UTF8ToSys, SysToUTF8 - Почти все можно удалить. Теперь они являются пустышками и возвращают только свои параметры.
281+
282+Файловые функции в RTL теперь заботятся о кодировке имен файлов. Все (?) связанные с именем файла функции ...UTF8() можно заменить на Delphi-совместимую функцию без суффикса UTF8. Например, FileExistsUTF8 можно заменить на FileExists.
283+
284+Большинство строковых функций UTF8...() можно заменить на совместимые с Delphi функции Ansi...(). Например, UTF8UpperCase() -\> AnsiUpperCase().
285+
286+Теперь Unicode работает и в программах без GUI. Требуется только зависимость от LazUtils и размещение модуля LazUTF8 в разделе uses основного файла программы.
287+
288+Для исторической справки, это была старая поддержка Unicode в LCL: [[Old LCL Unicode Support]]
289+
290+# Техническая реализация
291+
292+Что на самом деле происходит в системе Unicode? Эти 2 функции FPC вызываются в разделе ранней инициализации, устанавливая кодировку String по умолчанию в FPC в UTF-8:
293+
294+` SetMultiByteConversionCodePage(CP_UTF8);`\
295+` SetMultiByteRTLFileSystemCodePage(CP_UTF8);`
296+
297+В Windows функции UTF8...() в LazUTF8 (LazUtils) устанавливаются в качестве бэкэндов для строковых функций RTL Ansi...(). Таким образом, эти функции работают совместимым с Delphi способом.
298+
299+# Кодовые страницы FPC
300+
301+Компилятор (FPC) поддерживает указание кодовой страницы, которое может быть записано через опцию командной строки *-Fc* (т.е. *-Fcutf8*) или эквивалентную директиве *codepage* (т.е. *{\$codepage utf8}*). В этом случае, перед тем, как копировать байты, представляющие строковые константы в тексте вашей программы, компилятор будет интерпретировать все символьные данные в соответствии с указанной кодовой страницей. Есть две вещи, которые не стоит упускать из виду:
302+
303+- На платформах Unix, менеджер широких строк должен быть обязательно включен добавлением юнита *cwstring* в перечень uses. Без него программа не сможет правильно преобразовывать строковые данные во время исполнения.
304+
305+Менеджер широких строк добавляется по умолчанию в новом режиме UTF-8 RTL, однако это делает программу зависимой от libc и усложняет кросс-компиляцию.
306+
307+- Компилятор преобразует все строковые константы, содержащие символы, не относящиеся к ASCII, в константы типа widestring. Затем они автоматически преобразуются обратно в ansistring (либо во время компиляции, либо во время исполнения), но это может привести к искажениям, если вы попытаетесь смешать в одной строковой константе символы, напечатанные в тексте исходника и символы, заданные числовым представлением:
308+
309+Например:
310+
311+``` pascal
312+program project1;
313+{$codepage utf8}
314+{$mode objfpc}{$H+}
315+{$ifdef unix}
316+uses cwstring;
317+{$endif}
318+var
319+ a,b,c: string;
320+begin
321+ a:='ä';
322+ b:='='#$C3#$A4; // #$C3#$A4 - закодированный в UTF-8 символ ä
323+ c:='ä='#$C3#$A4; // после не относящегося к ascii 'ä' компилятор интерпретирует #$C3 в качестве отдельного widechar.
324+ writeln(a,b); // выводит ä=ä
325+ writeln(c); // выводит ä=ä
326+end.
327+```
328+
329+После компиляции и исполнения программа выведет:
330+
331+``` pascal
332+ä=ä
333+ä=ä
334+```
335+
336+Причина в том, что после того как в строке обнаружен символ *ä*, как упоминалось выше, оставшаяся часть строковой константы, присваиваемой переменной 'c', будет обработана как widestring. В результате \#\$C3 и \#\$A4 интерпретируются как widechar(#\$C3) и widechar(#\$A4), вместо прямой трансляции в байтовое представление.
337+
338+# Открытые вопросы
339+
340+- Символьные переменные в **TFormatSettings** (баг [27086](http://bugs.freepascal.org/view.php?id=27086)): например: **ThousandSeparator**, **DecimalSeparator**, **DateSeparator**, **TimeSeparator**, **ListSeparator**. Эти поля должны быть заменены на строки для корректной поддержки UTF-8. Например, под Linux с установками LC_NUMERIC=ru_RU.utf8 разделитель тысяч состоит из двух байт nbsp/160.
341+ - **Обход проблемы:** использовать только одиночные символы пробелов вместо того, что должно быть на самом деле, как это сделано в патче на баг [27099](http://bugs.freepascal.org/view.php?id=27099)
342+
343+### Вызовы функций WinAPI в библиотеках FPC
344+
345+- Unit registry, TRegistry - этот unit использует Ansi функции Windows API и поэтому вам придётся пользоваться UTF8ToWinCP, WinCPToUTF8. Раньше для этого требовался вызов UTF8ToSys.
346+- Все вызовы Windows функций с Ansi API в библиотеках FPC должны быть заменены версией W-API. Это в любом случае будет сделано для будущей поддержки UTF-16, поэтому никакого конфликта интересов нет. (прим. перев. - однако, эти действия означают декларированный отказ от дальнейшей поддержки версий Windows с неполной поддержкой Unicode - Windows 98, 95 и более ранних, а также некоторых мобильных и встроенных)
347+- **TProcess** - под Windows TProcess FPC 3.0 поддерживает только системную кодовую страницу. Необходимо либо использовать TProcessUTF8 из unit **utf8process** или патчить FPC, см. баг [29136](http://bugs.freepascal.org/view.php?id=29136)
348+
349+ToDo: Перечислить все относящиеся к багтрекеру FPC проблемы и патчи, которые могут эти проблемы решить.
350+
351+# Будущее
352+
353+Целью проекта FPC является создание решения, базирующегося на Delphi-совместимом UnicodeString (UTF-16), но пока мы к этому не готовы. Потребуется длительное время для такой реализации.
354+
355+Реализацию LCL на базе UTF-8 в её имеющемся виде необходимо рассматривать как временное решение. В будущем, когда в FPC будет полная поддержка UnicodeString как в RTL, так и в FCL, проект Lazarus обеспечит решения для LCL, использующее эти возможности. В то же время целью является и сохранение поддержки UTF-8, несмотря на то, что это может потребовать изменения в строковых типах или чего-то ещё. Деталей пока не знает никто. Мы обязательно сообщим вам о них, когда станет известно...
356+
357+В сущности, LCL скорее всего придётся в будущем разделиться на две версии - одну для UTF-8, и другую для UTF-16.
358+
359+# ЧаВо
360+
361+## Что насчет режима DelphiUnicode?
362+
363+**{\$Mode delphiunicode}** был добавлен в FPC 2.7.1 и похож на *{\$Mode Delphi}* с *{\$ModeSwitch UnicodeStrings}*. Смотрите следующий вопрос о *ModeSwitch UnicodeStrings*.
364+
365+## Как насчет ModeSwitch UnicodeStrings?
366+
367+**{\$ModeSwitch UnicodeStrings}** был добавлен в FPC 2.7.1 и определяет «String» как «UnicodeString» (UTF-16), «Char» как «WideChar», «PChar» как «PWideChar» и так далее. Это влияет только на текущий модуль. Другие модули, в том числе используемые этим модулем, имеют свое собственное определение «String». Многие строки и типы RTL (например, TStringList) используют 8-битные строки, которые требуют преобразования из/в UnicodeString, которые автоматически добавляются компилятором. LCL использует строки UTF-8. Рекомендуется использовать исходники в кодировке UTF-8 с или без "-FcUTF8".
368+
369+## Почему бы не использовать UTF8String в Lazarus?
370+
371+Кратко: потому что FCL не использует его.
372+
373+Исчерпывающе: **UTF8String** определен в модуле **system** как
374+
375+``` pascal
376+UTF8String = type AnsiString(CP_UTF8);
377+```
378+
379+Компилятор всегда предполагает, что он имеет кодировку UTF-8 (CP_UTF8), которая является многобайтовой кодировкой (то есть 1-4 байта на кодовую точку). Обратите внимание, что оператор \[\] обращается к байтам, а не к символам или кодовым точкам. То же самое для UnicodeString, но только слова вместо байтов. С другой стороны, предполагается, что **String** во время компиляции имеет *DefaultSystemCodePage* (CP_ACP). *DefaultSystemCodePage* определяется во время выполнения, поэтому компилятор консервативно полагает, что *String* и *UTF8String* имеют разные кодировки. Когда вы присваиваете или комбинируете *String* и *UTF8String*, компилятор вставляет код преобразования. То же самое для *ShortString* и *UTF8String*.
380+
381+Lazarus использует FCL, который использует *String*, поэтому использование *UTF8String* добавит конверсии. Если *DefaultSystemCodePage* не UTF-8, вы теряете символы. Если это UTF-8, то нет смысла использовать *UTF8String*.
382+
383+*UTF8String* станет полезным, когда в конце концов появится FCL UTF-16.
384+
385+## Почему UTF8String показывает странные символы, а String работает
386+
387+Например
388+
389+``` pascal
390+var s: UTF8String = 'ä';// с флагами по умолчанию (т.е. нет -Fc) это создает мусор
391+ // даже в системе UTF-8 Linux
392+```
393+
394+Вопрос: это ошибка? Ответ: Нет, потому что это работает как задокументировано.
395+
396+FPC игнорирует переменную LANG для создания в каждой системе одинакового результата. По историческим причинам/Delphi-совместимости он использует ISO-8859-1 по умолчанию. Lazarus предпочитает UTF-8.
397+
398+- Исходники UTF-8 работают со *String*, потому что
399+ 1. FPC по умолчанию не добавляет код преобразования для обычных строковых литералов.
400+ 2. *Исходная кодовая страница* равна *кодовой странице времени выполнения*. В Windows LazUTF8 устанавливает значение CP_UTF8.
401+- UTF8String требует исходников UTF-8. Начиная с FPC 3.0 для UTF8String вы должны сообщать компилятору, что исходник является UTF8 (*-FcUTF8*, *{\$codepage UTF8}* или сохранять файл как UTF-8 с BOM).
402+
403+> **Note:** Если вы сообщаете компилятору исходную кодировку UTF-8, он заменяет все строковые литералы ASCII этого модуля на UTF-16, увеличивая размер двоичного файла, добавляя некоторые служебные данные, и PChar для литералов требует явного преобразования. Вот почему Lazarus не добавляет его по умолчанию.
404+
405+## Что случится, если я использую {\$codepage utf8}?
406+
407+FPC имеет очень ограниченную поддержку UTF-8. Фактически, FPC поддерживает хранение литералов только как 8-битные строки с кодировкой «по умолчанию» или как widestrings (широкие строки). Поэтому любая кодовая страница не по умолчанию преобразуется в widestrings, даже если это системная кодовая страница. Например, большинство Linux/Mac/BSD используют UTF-8 в качестве системной кодовой страницы. Передача -Fcutf8 в компилятор сохранит строковый литерал как widestrings.
408+
409+Во время выполнения widestring литерал конвертируется. Когда вы присваиваете литерал AnsiString, widestring литерал преобразуется с помощью widestringmanager в кодировку системы. По умолчанию widestringmanager под Unix просто конвертирует widechars в символы, уничтожая любые символы не ASCII. Вы должны использовать widestringmanager, например, cwstring, чтобы получить правильное преобразование. Модуль LazUTF8 делает это.
410+
411+# См. также
412+
413+Информация о Unicode, кодовых страницах, строковых типах и RTL в FPC.\
414+Обратите внимание, что эта информация не совсем полезна для системы Lazarus UTF-8, потому что с точки зрения FPC она является хаком и меняет кодовую страницу по умолчанию.\
415+[[FPC Unicode support/ru|Поддержка Юникода в FPC]]
416+
417+---
418+*From the Free Pascal wiki, page "Unicode Support in Lazarus/ru", as it stood on 2020-03-02 after a change by Trev, out of the wiki's dump of 2024-05-26. Copyright stays with the author who wrote it, according to the old wiki's [[Licensing]] page. If you have concerns about this material, [message the admin](/wiki-contact).*

Back to history