Unicode Support in Lazarus/ru: what changed

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

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