FPC Unicode support/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		До FPC 2.6.x включительно, RTL базировалась на своих аналогах в Turbo Pascal и Delphi 7. Это значит, что её функциональность была в основном построена на обработке строковых типов shortstring, ansistring и pchar. Ни один из этих типов не несёт какой либо информации о кодировке, связанной с ним, но неявно подразумевается, что строки находятся в "кодировке системы по умолчанию" и могут быть переданы на вызовы API операционной системы без преобразований.
4	4
5	5		В Delphi 2009, Embarcadero полностью переключил RTL на тип UnicodeString, использующий представление строк UTF-16. Дополнительно были введены типы AnsiString, содержащие маркировку кодовой страницы. Это означает, что строковые переменные AnsiStrings, относящиеся к таким типам, всегда содержат информацию о кодовой странице, указывающую, как данные должны быть интерпретированы.
6	6
7	7		Поддержка на уровне языка в FPC для таких строковых типов на настоящий момент уже доступна в текущих версиях компилятора "для разработчиков" (FPC 2.7.1/trunk). Поддержка на уровне RTL на настоящий момент неполная. На данной странице представлен обзор поведения таких строковых типов в отношении кодовых страниц, текущий уровень поддержки в RTL, а также возможные будущие пути, которыми эта поддержка может быть улучшена.
8	8
9	9		# Обратная совместимость
10	10
11	11		Весь существующий код, работающий в рамках стандартного подхода (*), предназначенный для предыдущих версий FPC, изменений не потребует. Он должен продолжать работать без каких либо модификаций под новыми версиями FPC. Условия этого "стандартного" использования множества переменных с кодовой страницей по умолчанию и их значений описаны ниже.
12	12
13	13		(*) это в первую очередь означает: вы никогда не сохраняете данные в ansistring-ах с маркировкой кодовой страницы, отличающейся от системной кодовой страницы по умолчанию, и последовательно передаете строку в неизменном виде процедуре из FPC RTL. Например, в текущем коде Lazarus обычно производится вызов UTF8ToAnsi() перед передачей его строк подпрограммам FPC RTL.
14	14
15	15		# Кодовые страницы
16	16
17	17		Кодовая страница определяет, как именно индивидуальные байты строки должны интерпретироваться, т.е. какая буква, символ или иной графический примитив соответствует каждому байту или последовательности байтов.
18	18
19	19		## Идентификаторы кодовых страниц
20	20
21	21		Идентификатор кодовой страницы всегда хранится как значение типа TSystemCodePage, являющимся псевдонимом (alias) для [[Word]]. Значение представляет собой соответствующую кодовую страницу, как это определено в \[<http://msdn.microsoft.com/en-us/library/windows/desktop/dd317756(v=vs.85>).aspx Microsoft Windows\]. Дополнительно используются следующие три специальных значения кодовых страниц:
22	22
23	23		- CP_ACP: это значение представляет собой текущий набор "системной кодовой страницы по умолчанию". См. дополнительную информацию в разделе #Настройки кодовой страницы.
24	24		- CP_OEM: это значение представляет собой кодовую страницу OEM. На платформе Windows оно соответствует кодовой странице, используемой консолью (т.е. окном программы cmd.exe). На других платформах это значение интерпретируется точно так же, как CP_ACP.
25	25		- CP_NONE: это значение указывает, что никакая информация о кодовой странице не ассоциирована со строковыми данными. Результат любой прямой или косвенной операции по конвертированию этих данных в другую кодовую страницу не определён.
26	26
27	27		Примечание: идентификаторы кодовых страниц отличаются от имён кодовых страниц, используемых в директивах [{\$codepage xxx}](http://www.freepascal.org/docs-html/prog/progsu88.html) (доступных и в текущем стабильном FPC). Имена кодовых страниц для директивы берутся из специального перечня, в котором представлены такие идентификаторы, как cp866, cp1251 и utf8.
28	28
29	29		## Настройки кодовой страницы
30	30
31	31		Модуль system содержит глобальные переменные, указывающих кодовую страницу по умолчанию, использующуюся для некоторых операций.
32	32
33	33		### DefaultSystemCodePage
34	34
35	35		- Назначение: определяет, как интерпретируется CP_ACP
36	36		- Начальное значение:
37	37		- Windows: результат системного вызова GetACP, который возвращает кодовую страницу Windows ANSI.
38	38		- iOS: UTF-8
39	39		- Unix (кроме iOS): Базируется на текущих установках переменных окружения LANG или LC_CTYPE. Обычно это UTF-8, но нет никаких гарантий этого.
40	40		- Другие платформы: CP_ACP (эти платформы на настоящий момент не поддерживают несколько кодовых страниц, и жестко привязаны к использованию своих, специфичных для операционной системы кодовых страниц во всех случаях)
41	41		- Модификация: Можно изменить значение переменной вызовом SetMultiByteConversionCodePage(CodePage: TSystemCodePage)
42	42		- Примечания: Поскольку значение этой переменной может быть изменено, не стоит полагаться на неё для определения действительной "системной кодовой страницы по умолчанию" операционной системы (даже в случае, если вы делаете это непосредственно после запуска программы, вы не можете быть уверены, что какие либо модули (unit) не внесли изменения в эту переменную при выполнении своих блоков инициализации).
43	43
44	44		### DefaultFileSystemCodePage
45	45
46	46		- Назначение: определяет кодовую страницу, на которую переводятся имена файлов, каталогов и путей доступа перед вызовами API операционной системы, *если* RTL использует однобайтовый OS API для этих целей на текущей платформе. Эта кодовая страница также используется для промежуточных операций, касающих файловых путей внутри RTL перед тем, как сделать вызов OS API. Эта переменная отсутствует в Delphi и была введена в FPC для того, чтобы сделать возможным изменение значения DefaultSystemCodePage без разрушения интерфейсов RTL с вызовами функций API ОС, касающихся файловой системы.
47	47		- Начальное значение:
48	48		- Windows: UTF-8, поскольку RTL использует вызовы API операционной системы в кодировке UTF-16 (при этом данные не теряются в операциях промежуточного преобразования).
49	49		- macOS и iOS: UTF-8 (так определено Apple)
50	50		- Unix (исключая macOS и iOS): DefaultSystemCodePage, поскольку кодировка имён файлов не определена на платформах Unix (имена файлов являются нетипизированным байтовым массивом, который может быть интерпретирован любым способом; не гарантируется, что это правильный UTF-8)
51	51		- Другие платформы: то же самое, что в DefaultSystemCodePage
52	52		- Модификация: можно изменить это значение вызовом SetMultiByteFileSystemCodePage(CodePage: TSystemCodePage)
53	53		- Примечания: настройки Unix/macOS/iOS учитываются только в случае, когда установлен менеджер широких строк cwstring, иначе DefaultFileSystemCodePage после запуска программы будет иметь то же значение, что и DefaultSystemCodePage.
54	54
55	55		### DefaultRTLFileSystemCodePage
56	56
57	57		- Назначение: определяет кодовую страницу, в кодировку которой транслируются имена файлов/путей перед тем, как они будут возвращены из процедур RTL, возвращающих строки формата RawByteString. Например, эта переменная используется для преобразования имён файлов/путей, возвращаемых RawbyteString-версиями функций SysUtils.FindFirst и System.GetDir. Основная причина их существования - обеспечение обратной совместимости с ранними версиями FPC, в которых всегда возвращались строки в кодировке, используемой для вызова функций API операционной системы, работающими с однобайтовой кодировкой (значение этой кодировки сейчас сохранено в DefaultSystemCodePage).
58	58		- Начальное значение
59	59		- Windows: DefaultSystemCodePage, для совместимости с предыдущими версиями.
60	60		- macOS и iOS: UTF-8, для совместимости с предыдущими версиями (на самом деле оно и раньше было UTF-8, результаты вызовов файлового API операционной системы не подвергались преобразованию).
61	61		- Unix (кроме macOS и iOS): DefaultSystemCodePage, по той же причине, что обозначена для DefaultFileSystemCodePage. Установка значения, отличающегося от DefaultFileSystemCodePage - очень плохая идея для этих платформ, любое преобразование кодовых страниц может разрушить строки, поскольку их начальная кодировка неизвестна.
62	62		- Модификация: можно изменить значение этой переменной вызовом SetMultiByteRTLFileSystemCodePage(CodePage: TSystemCodePage)
63	63		- Замечания: те же, что и для DefaultFileSystemCodePage.
64	64
65	65		# Строки
66	66
67	67		## Строковые/символьные типы
68	68
69	69		### Shortstring
70	70
71	71		Кодовая страница данных типа shortstring неявно подразумевается как CP_ACP и, следовательно, будет равна текущему значению переменной DefaultSystemCodePage.
72	72
73	73		### PAnsiChar/AnsiChar
74	74
75	75		Эти типы - то же самое, что и старые типы PChar/Char. Во всех режимах компилятора, кроме {\$mode delphiunicode}, PChar/Char по-прежнему остаются псевдонимами для PAnsiChar/AnsiChar. Кодовая страница таких строк неявно подразумевается CP_ACP и, следовательно, будет равна текущему значению переменной DefaultSystemCodePage.
76	76
77	77		### PWideChar/PUnicodeChar и WideChar/UnicodeChar
78	78
79	79		Эти типы остались неизменными. WideChar/UnicodeChar могут содержать одиночную кодовую единицу UTF-16, в то время как PWideChar/PUnicodeChar указывают либо на одну кодовую единицу, либо на массив кодовых единиц UTF-16.
80	80
81	81		В режиме {\$mode delphiunicode}, PChar будет псевдонимом для PWideChar/PUnicodeChar и Char будет псевдонимом для WideChar/UnicodeChar.
82	82
83	83		### UnicodeString/WideString
84	84
85	85		Эти типы остались такими же, как и в предыдущих версиях:
86	86
87	87		- Widestring - то же самое что и "COM BSTR" под Windows, и алиас для UnicodeString для всех других платформ. Строковые данные этого типа представлены с использованием UTF-16.
88	88		- UnicodeString - строка со счётчиком ссылок и максимальной длиной high(SizeInt) кодовых единиц UTF-16.
89	89
90	90		### Ansistring
91	91
92	92		Семейство AnsiString - строковые типы со счетчиком ссылок и максимальной длиной high(SizeInt) байт. Кроме того, для каждой переменной такого типа сейчас сохраняется информация о кодовой странице, ассоциированной с данными.
93	93
94	94		Важнее всего понять, новое для переменной типа AnsiString в том, что она одновременно может обладать декларированной/статической/основной/по умолчанию кодовой страницей (далее по тексту статической кодовой страницей) и динамической кодовой страницей. Статическая кодовая страница сообщает компилятору, что при присвоении какого либо значения переменной типа AnsiString, он должен сначала конвертировать данные в эту статическую кодовую страницу (кроме случая, когда она CP_NONE, см. ниже раздел #RawByteString). Динамическая кодовая страница является характеристикой каждого отдельного экземпляра переменной типа AnsiString, такой же, как длина и счетчик ссылок - она определяет действительную кодовую страницу строковых данных, в текущий момент содержащихся в переменной типа AnsiString.
95	95
96	96		#### Статическая кодовая страница
97	97
98	98		Статическая кодовая страница для AnsiString может быть назначена единственным способом - объявлением нового типа:
99	99
100	100		``` pascal
101	101		type
102	102		CP866String = type AnsiString(866); // обратите внимание на добавочное "type"
103	103		```
104	104
105	105		Статическая кодовая страница переменной, объявленной просто как AnsiString (без указания кодовой страницы) - будет CP_ACP. По сути, тип AnsiString теперь семантически определён в unit System следующим образом:
106	106
107	107		``` pascal
108	108		type
109	109		AnsiString = type AnsiString(CP_ACP);
110	110		```
111	111
112	112		Еще одним предопределённым типом для AnsiString(X) в unit System является UTF8String:
113	113
114	114		``` pascal
115	115		type
116	116		UTF8String = type AnsiString(CP_UTF8);
117	117		```
118	118
119	119		После того, как вы объявили собственный тип AnsiString(X), вы можете использовать его наименование для объявления переменных, параметров, полей и т. д. как обычно.
120	120
121	121		Обратите внимание, что CP_UTF16 и CP_UTF16BE не будут допустимыми кодовыми страницами для строк AnsiString. Результат объявления AnsiString с такими кодовыми страницами не определён.
122	122
123	123		#### Динамическая кодовая страница
124	124
125	125		Если строка со статической кодовой страницей X1 присваивается строке со статической кодовой страницей X2, и X1 не равно X2, строковые данные обычно сначала конвертируются в кодовую страницу X2 перед присвоением, и результирующая динамическая кодовая страница строки-результата будет X2. При присвоении строки переменной типа AnsiString с неуказанной кодовой страницей (= AnsiString(CP_ACP)) или ShortString, строковые данные будут конвертированы в DefaultSystemCodePage. Динамическая кодовая страница такой переменной типа AnsiString(CP_ACP) с момента присвоения поменяется на текущее значение DefaultSystemCodePage (например, 1251 для кодовой страницы Windows-1251), несмотря на то, что статическая кодовая страница такой переменной CP_ACP (Константа, обозначающая которую, не равна 1251). Это только один из примеров случая, когда статическая кодовая страница может отличаться от динамической кодовой страницы. В последующие разделах будет описано больше таких сценариев.
126	126
127	127		Внимание: как объяснялось выше, произойдет или нет возможное преобразование кодовых страниц, зависит только от значения статических кодовых страниц строк, участвующих в операции. Это значит, что если вы присваиваете одну переменную типа AnsiString(X) другой переменной типа AnsiString(X) и динамическая кодовая страница присваиваемой строки отличается от X, строковые данные не будут конвертированы в кодовую страницу X перед присваиванием.
128	128
129	129		#### RawByteString
130	130
131	131		Тип RawByteString объявлен следующим образом:
132	132
133	133		``` pascal
134	134		type
135	135		RawByteString = type AnsiString(CP_NONE);
136	136		```
137	137
138	138		Как объяснено ранее, результат конверсии из/в кодовую страницу CP_NONE не определён. Поскольку нет смысла объявлять в RTL тип, поведение которого не определено, поведение строк типа RawByteString несколько отличается от других типов семейства AnsiString(X).
139	139
140	140		При первом приближении, RawByteString можно рассматривать как "нетипизированный AnsiString": присваивание переменной типа RawByteString строки типа AnsiString(X) будет выглядеть так же, как если переменной типа AnsiString(X) присвоить другую переменную AnsiString(X) с тем же самым значением X: никаких преобразований кодовых страниц или копирования не произойдёт, просто увеличится счетчик ссылок.
141	141
142	142		Не так бросается в глаза, что в случае, когда переменная типа RawByteString присваивается переменной типа AnsiString(X), случится следующее: никакого копирования или преобразования кодовых страниц не происходит, лишь увеличится счётчик ссылок. Обратите внимание, это означает, что результаты функций, возвращающих RawByteString никогда не преобразуются в статическую кодовую страницу переменной-назначения. Это - еще один пример случая, когда динамическая кодовая страница AnsiString(X) принимает значение, не совпадающее с её статической кодовой страницей.
143	143
144	144		Данный тип преимущественно используется, чтобы объявить const, constref и значения параметров, ожидающих любое значение типа AnsiString(X) без его преобразования в предопределённую статическую кодовую страницу. Обратите внимание, что если вы это сделаете, процедура, принимающая такие параметры, должна быть в состоянии обработать строки любой допустимой динамической кодовой страницы.
145	145
146	146		Параметры var и out также могут быть объявлены как RawByteString, но в этом случае компилятор выдаст ошибку, если на эти параметры будет отображена переменная типа AnsiString(X), чья статическая кодовая страница отличается от CP_NONE. Такое поведение согласуется в целом с трактовкой параметров var и out: они требуют полного совпадения типов переменных, передаваемых им. Вы можете заключить аргумент в декларацию явного приведения типов RawByteString() для того, чтобы воспрепятствовать появлению сообщения об ошибке, но при этом должны быть готовы к тому, что возвращаемая строка может иметь любую динамическую кодовую страницу.
147	147
148	148		------------------------------------------------------------------------
149	149
150		-	Прим.перев.: Как можно так запутать такие простые вещи?! Весьма простое определение дается в небезызвестной статье на сайте Эмбаркадеро [Delphi в мире Юникода, часть II: новые возможности RTL и классы для поддержки Юникода](https://edn.embarcadero.com/article/38582#9%D0%94%D1%80%D1%83%D0%B3%D0%B8%D0%B5%D0%B2%D0%BE%D0%B7%D0%BC%D0%BE%D0%B6%D0%BD%D0%BE%D1%81%D1%82%D0%B8RTL%D0%B4%D0%BB%D1%8F%D0%AE%D0%BD%D0%B8%D0%BA%D0%BE%D0%B4%D0%B0):<i>"... в RTL введен тип RawByteString, который представляет собой строку, не связанную с какой-либо кодировкой... Назначение типа RawByteString – сделать возможной передачу строковых данных для любой кодовой страницы без каких-либо преобразований кодировки. Это очень полезно для подпрограмм, для которых кодировка не имеет значения, вроде побайтового поиска в строке."</i>
	150	+	Прим.перев.: Как можно так запутать такие простые вещи?! Весьма простое определение дается в небезызвестной статье на сайте Эмбаркадеро [Delphi в мире Юникода, часть II: новые возможности RTL и классы для поддержки Юникода](https://edn.embarcadero.com/article/38582#9%D0%94%D1%80%D1%83%D0%B3%D0%B8%D0%B5%D0%B2%D0%BE%D0%B7%D0%BC%D0%BE%D0%B6%D0%BD%D0%BE%D1%81%D1%82%D0%B8RTL%D0%B4%D0%BB%D1%8F%D0%AE%D0%BD%D0%B8%D0%BA%D0%BE%D0%B4%D0%B0):"... в RTL введен тип RawByteString, который представляет собой строку, не связанную с какой-либо кодировкой... Назначение типа RawByteString – сделать возможной передачу строковых данных для любой кодовой страницы без каких-либо преобразований кодировки. Это очень полезно для подпрограмм, для которых кодировка не имеет значения, вроде побайтового поиска в строке."
151	151
152	152		------------------------------------------------------------------------
153	153
154	154		## Сцепление (конкантенации) строк
155	155
156	156		Как правило, в Паскале тип результата выражения не зависит от того, как этот результат используется впоследствии. Так, умножение двух чисел longint на 32-битной платформе и присваивание результата переменной типа int64 означает выполнение умножения с использованием 32-битной арифметики, и лишь конечный результат конвертируется в 64 бита.
157	157
158	158		Для строк с маркировкой кодовой страницы это правило не действует: сцепление двух или более строк всегда производится без каких либо потерь данных, и лишь после завершения операции строка-результат конвертируется в статическую кодовую страницу назначения (что может привести к потере данных).
159	159
160	160		Присвоение результата конкантенации переменной типа RawByteString производится особым образом:
161	161
162	162		- если все строки, участвующие в операции, имели одинаковую динамическую кодовую страницу, результат также будет иметь эту кодовую страницу
163	163		- в иных случаях результат будет преобразован в CP_ACP (возможно, в будущем такое поведение изменится, так как оно выглядит не очень практичным)
164	164
165	165		## Строковые константы
166	166
167	167		Строковые константы обрабатываются FPC следующим образом:
168	168
169	169		- Если в файле есть директива {\$codepage xxx} (Например, `{$codepage UTF8}`), тогда строковые константы интерпретируются в соответствии с этой кодовой страницей, иначе:
170	170		- Если файл начинается с маркировки UTF-8 BOM, тогда строковые константы интерпретируются в качестве строк UTF-8, иначе:
171	171		- строковые константы копируются без каких либо преобразований во внутренний буфер и интерпретируются в виде символов с использованием следующих кодовых страниц:
172	172		- DefaultSystemCodePage *компьютера, на котором компилятор запущен, когда директива {\$modeswitch systemcodepage}* активна (то есть, компилирование одного и того же исходного кода на различных системах может приводить к тому, что строковые константы будут интерпретированы по разному; упомянутая директива введена для совместимости с Delphi и находится в состоянии «включено» по умолчанию в режиме {\$mode delphiunicode})
173	173		- CP_ACP в случае, когда директива {\$modeswitch systemcodepage} не активна (для совместимости с предыдущими версиями FPC)
174	174
175	175		Во всех случаях, кроме последнего, действительная кодовая страница файла-исходника известна. Эта информация используется, когда компилятор вынужден конвертировать строковые константы в другую кодовую страницу. Для последнего же случая по умолчанию предполагается следующее: подразумевается, что строки принадлежат к кодовой странице 28591 (ISO 8859-1 Latin 1; Western European). Это предположение, или, в противоположность ему, фактическая кодовая страница и есть термин, обозначенный в тексте ниже как кодовая страница исходника.
176	176
177	177		Когда строковая константа присваивается переменной типа AnsiString(X) в программном коде или как часть типизированной константы или при инициализации переменной, тогда
178	178
179	179		- если X = CP_NONE (т. е. результат - переменная типа RawByteString), результат будет таким же, как если бы строковая константа была назначена переменной типа AnsiString(CP_ACP)
180	180		- если X = CP_ACP и кодовая страница строковой константы отличается от CP_ACP, строковая константа конвертируется во время компиляции в кодовую страницу исходника. Если кодовая страница исходника также CP_ACP, строка будет сохранена в программе в неизменной форме с маркёром кодовой страницы CP_ACP, и следовательно, ее значение и интерпретация будут зависеть от действующего значения глобальной переменной DefaultSystemCodePage во время исполнения. Это обеспечивает совместимость со старыми версиями FPC при присвоении строковых констант переменным типа AnsiString без использования директивы {\$codepage xxx} или маркировки UTF-8 BOM.
181	181		- при других значениях X строковая константа конвертируется во время компиляции в кодовую страницу X
182	182
183	183		Аналогично, если строковая константа присваивается переменной типа UnicodeString, она конвертируется во время компиляции из кодовой страницы исходника в UTF-16.
184	184
185	185		При присвоении переменным типов ShortString и PChar выполняются те же действия, что и для переменной типа AnsiString(CP_ACP).
186	186
187	187		Обратите внимание, что именованные строковые константы будут подвержены конверсии во время компиляции при каждом присвоении переменным строковых типов, в зависимости от кодовой страницы, которую эти переменные используют. Что означает отсутствие выигрыша в скорости компиляции при использовании одной и той же строковой константы в различных кодовых страницах и строковых контекстах, экономия будет крайне незначительной.
188	188
189	189		Из сказанного выше следует, что для обеспечения предсказуемой интерпретации строковых констант в исходном коде, лучше всего включить явную директиву {\$codepage xxx} (или использовать ее эквивалент в командной строке -Fc), или сохранять файлы с исходниками в UTF-8, с маркировкой BOM в начале файла.
190	190
191	191		## Индексация строк
192	192
193	193		Никаких изменений в индексацию строк не добавилось. Каждый элемент строки типа UnicodeString/WideString - это два байта, каждый элемент строки всех других строковых типов - один байт. Механизм индексации строк полностью игнорирует кодовые страницы и композиционные кодовые точки.
194	194
195	195		# Изменения в RTL
196	196
197	197		Для того, чтобы полностью гарантировать целостность данных в присутствии строк, маркированных кодовой страницей, все процедуры в RTL и пакетах, допускающие параметры типа AnsiString, должны быть адаптированы. Причина в том, что если их параметры останутся просто типа AnsiString, то любая строка с отличающейся статической кодовой страницей будет сконвертирована в DefaultSystemCodePage при передаче в эти параметры. Это может привести к искажению и потере данных.
198	198
199	199		На настоящее время, основные процедуры, работающие с доступом к файловой системе, были обновлены с целью предотвращения искажения и потери данных. Ниже приведен полный список всех процедур, сохраняющих кодировку строк в FPC 2.7.1 и более поздних. Если иное не указано особо, все эти процедуры также имеют перегруженные (overload) версии, воспринимающие параметры типа 'UnicodeString''.
200	200
201	201		- System: FExpand, LowerCase, UpperCase, GetDir, MKDir, ChDir, RMDir, Assign, Erase, Rename, процедуры стандартного ввода/вывода (Read/Write/Readln/Writeln/Readstr/Writestr), Insert, Copy, Delete, SetString
202	202		- ObjPas (автоматически подключается в режимах Delphi и ObjFPC): AssignFile
203	203		- SysUtils: FileCreate, FileOpen, FileExists, DirectoryExists, FileSetDate, FileGetAttr, FileSetAttr, DeleteFile, RenameFile, FileSearch, ExeSearch, FindFirst, FindNext, FindClose, FileIsReadOnly, GetCurrentDir, SetCurrentDir, ChangeFileExt, ExtractFilePath, ExtractFileDrive, ExtractFileName, ExtractFileExt, ExtractFileDir, ExtractShortPathName, ExpandFileName, ExpandFileNameCase, ExpandUNCFileName, ExtractRelativepath, IncludeTrailingPathDelimiter, IncludeTrailingBackslash, ExcludeTrailingBackslash, ExcludeTrailingPathDelimiter, IncludeLeadingPathDelimiter, ExcludeLeadingPathDelimiter, IsPathDelimiter, DoDirSeparators, SetDirSeparators, GetDirs, ConcatPaths, GetEnvironmentVariable
204	204		- Unix: процедуры fp(), относящиеся к операциям с файловой системой (не имеют перегруженных экземпляров с параметрами типа UnicodeString*), POpen
205	205		- DynLibs: все процедуры
206	206
207	207		# Что необходимо сделать с RTL
208	208
209	209		Поскольку приведённый выше перечень содержит все процедуры, подвергшиеся модификации, остальные процедуры RTL еще не поддерживают произвольные кодовые страницы. Этот раздел содержит перечень подводных камней, найденных отдельными людьми, и если это возможно, обходных путей. Обратите внимание, что процедуры, не попавшие ни в этот список, ни в список выше, использовать столь же опасно, как и перечисленные здесь.
210	210
211	211		## TFormatSettings и DefaultFormatSettings
212	212
213	213		Тип аргументов ThousandSeparator и DecimalSeparator - AnsiChar. Это означает, что если переменная DefaultSystemCodePage имеет значение UTF-8 и разделитель текущей локали более одного байта длиной в этой кодировке, такие поля недостаточны для его представления. В качестве примера можно привести символы неразрывных пробелов, используемые во французской и русской локали для отображения ThousandSeparator.
214	214
215	215		# Старые/устаревшие разделы
216	216
217	217		> Warning: Эти разделы сохранены в исторических целях - пожалуйста обновите разделы выше с этой информацией, если она до сих пор используется. Начиная с FPC 2.7 (текущая разрабатываемая версия), расширенная поддержка Unicode была реализована.
218	218
219	219		## Изменения, видимые пользователям
220	220
221	221		Полная поддержка строк, маркированных кодовой страницей невозможна без нарушения существующего кода. Ниже приведен список, который пытается обобщить наиболее важные изменения, видимые для пользователя.
222	222
223	223		- Заголовок строки получил два новых поля: кодировка и размер элемента. На 32-битных платформах это увеличило размер заголовка на 4 байта, на 64-битных платформах - на 8 байт.
224	224		- WideCharLenToString, UnicodeCharLenToString, WideCharToString, UnicodeCharToString и OleStrToString теперь возвращают UnicodeString вместо Ansistring, как было ранее.
225	225		- тип параметра dest функций WideCharLenToString и UnicodeCharLenToString изменён с Ansistring на Unicodestring
226	226		- UTF8ToAnsi и AnsiToUTF8 теперь принимают RawByteString
227	227
228	228		# См. также
229	229
230	230		- [[Character and string types/ru\|Символьные и строковые типы]]
231	231		- [[unicode use cases]]
232	232		- [[LCL Unicode Support/ru\|Поддержка Юникода в Lazarus]]
233	233		- Предложение: [[not Delphi compatible enhancement for Unicode Support]]
234	234
235	235		---
236	236		From the Free Pascal wiki, page "FPC Unicode support/ru", as it stood on 2019-12-22 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).
237	237		Category: FPC/ru
238	238		Category: Russian
239	239		Category: Unicode/ru

Back to history