appendices/migration71/windows-support.xml
3cd337b4dc91c827399961b9b45524ae4f2b50c9
...
...
@@ -4,6 +4,117 @@
4
4
<sect1 xml:id="migration71.windows-support" xmlns:xlink="http://www.w3.org/1999/xlink">
5
5
<title>Windows Support</title>
6
6

7
+
<sect2 xml:id="migration71.windows-support.long-and-utf8-path">
8
+
<title>Support for long and UTF-8 path</title>
9
+
<para>
10
+
If a web application is UTF-8 conform, no further action is required. For
11
+
applications depending on paths in non UTF-8 encodings for I/O, an explicit
12
+
INI directive has to be set. The encoding INI settings check relies on the
13
+
order in the core:
14
+
</para>
15
+
<itemizedlist>
16
+
<listitem>
17
+
<simpara>
18
+
internal_encoding
19
+
</simpara>
20
+
</listitem>
21
+
<listitem>
22
+
<simpara>
23
+
default_charset
24
+
</simpara>
25
+
</listitem>
26
+
<listitem>
27
+
<simpara>
28
+
zend.multibyte
29
+
</simpara>
30
+
</listitem>
31
+
</itemizedlist>
32
+
<para>
33
+
Several functions for codepage handling were introduced:
34
+
</para>
35
+
<itemizedlist>
36
+
<listitem>
37
+
<simpara>
38
+
sapi_windows_cp_set() to set the default codepage
39
+
</simpara>
40
+
</listitem>
41
+
<listitem>
42
+
<simpara>
43
+
sapi_windows_cp_get() to retrieve the current codepage
44
+
</simpara>
45
+
</listitem>
46
+
<listitem>
47
+
<simpara>
48
+
sapi_windows_cp_is_utf8()
49
+
</simpara>
50
+
</listitem>
51
+
<listitem>
52
+
<simpara>
53
+
sapi_windows_cp_conv() to convert between codepages, using iconv() compatible signature
54
+
</simpara>
55
+
</listitem>
56
+
</itemizedlist>
57
+
<para>
58
+
These functions are thread safe.
59
+
</para>
60
+
<para>
61
+
The console output codepage is adjusted depending on the encoding used in
62
+
PHP. Depending on the concrete system OEM codepage, the visible output
63
+
might or might be not correct. For example, in the default cmd.exe and on
64
+
a system with the OEM codepage 437, outputs in codepages 1251, 1252, 1253
65
+
and some others can be shown correctly when using UTF-8. On the same system,
66
+
chars in codepage like 20932 probably won't be shown correctly. This refers
67
+
to the particular system rules for codepage, font compatibility and the
68
+
particular console program used. PHP automatically sets the console codepage
69
+
according to the encoding rules from php.ini. Using alternative consoles
70
+
instead of cmd.exe directly might bring better experience in some cases.
71
+
</para>
72
+
<para>
73
+
Nevertheless be aware, runtime codepage switch after the request start
74
+
might bring unexpected side effects on CLI. The preferable way is php.ini,
75
+
When PHP CLI is used in a console emulator, that doesn't support Unicode,
76
+
it might possibly be required, to avoid changing the console codepage. The
77
+
best way to achieve it is by setting the default or internal encoding to
78
+
correspond the ANSI codepage. Another method is to set the INI directives
79
+
output_encoding and input_encoding to the required codepage, in which case
80
+
however the difference between internal and I/O codepage is likely to cause
81
+
mojibake. In rare cases, if PHP happens to crash gracefully, the original
82
+
console codepage might be not restored. In this case, the chcp command
83
+
can be used, to restore it manually.
84
+
</para>
85
+
<para>
86
+
Special awareness for the DBCS systems - the codepage switch on runtime
87
+
using <function>ini_set</function> is likely to cause display issues. The difference to the
88
+
non DBCS systems is, that the extended characters require two console cells
89
+
to be displayed. In certain case, only the mapping of the characters into
90
+
the glyph set of the font could happen, no actual font change. This is the
91
+
nature of DBCS systems, the most simple way to prevent display issues is
92
+
to avoid usage of <function>ini_set</function> for the codepage change.
93
+
</para>
94
+
<para>
95
+
As a result of UTF-8 support in the streams, PHP scripts are not limited
96
+
to ASCII or ANSI filenames anymore. This is supported out of the box on
97
+
CLI. For other SAPI, the documentation for the corresponding server
98
+
is useful.
99
+
</para>
100
+
<para>
101
+
Long paths support is transparent. Paths longer than 260 bytes get
102
+
automatically prefixed with <literal>\\?\</literal>. The max path length is limited to
103
+
2048 bytes. Be aware, that the path segment limit (basename length) still
104
+
persists.
105
+
</para>
106
+
<para>
107
+
For the best portability, it is strongely recommended to handle filenames,
108
+
I/O and other related topics UTF-8. Additionally, for the console applications,
109
+
the usage of a TrueType font is preferable and the usage of ini_set() for
110
+
the codepage change is discouraged.
111
+
</para>
112
+
<para>
113
+
</para>
114
+
<para>
115
+
</para>
116
+
</sect2>
117
+

7
118
<sect2 xml:id="migration71.windows-support.readline">
8
119
<title>readline</title>
9
120

...
...
@@ -15,6 +126,22 @@
15
126
</para>
16
127
</sect2>
17
128

129
+
<sect2 xml:id="migration71.windows-support.php-fcgi-children">
130
+
<title>PHP_FCGI_CHILDREN</title>
131
+
<para>
132
+
<varname>PHP_FCGI_CHILDREN</varname> is now respected. If this environment variable is
133
+
defined, the first <filename>php-cgi.exe</filename> process will exec the specified number
134
+
of children. These will share the same TCP socket.
135
+
</para>
136
+
</sect2>
137
+

138
+
<sect2 xml:id="migration71.windows-support.ftok">
139
+
<title>ftok()</title>
140
+
<para>
141
+
Added support for <function>ftok</function>
142
+
</para>
143
+
</sect2>
144
+

18
145
</sect1>
19
146

20
147
<!-- Keep this comment at the end of the file
21
148