1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
|
<?xml version="1.0" encoding="utf-8"?>
<!-- $Revision$ -->
<sect1 xml:id="migration71.windows-support" xmlns:xlink="http://www.w3.org/1999/xlink">
<title>Windows Support</title>
<sect2 xml:id="migration71.windows-support.long-and-utf8-path">
<title>Support for long and UTF-8 path</title>
<para>
If a web application is UTF-8 conform, no further action is required. For
applications depending on paths in non UTF-8 encodings for I/O, an explicit
INI directive has to be set. The encoding INI settings check relies on the
order in the core:
</para>
<itemizedlist>
<listitem>
<simpara>
internal_encoding
</simpara>
</listitem>
<listitem>
<simpara>
default_charset
</simpara>
</listitem>
<listitem>
<simpara>
zend.multibyte
</simpara>
</listitem>
</itemizedlist>
<para>
Several functions for codepage handling were introduced:
</para>
<itemizedlist>
<listitem>
<simpara>
sapi_windows_cp_set() to set the default codepage
</simpara>
</listitem>
<listitem>
<simpara>
sapi_windows_cp_get() to retrieve the current codepage
</simpara>
</listitem>
<listitem>
<simpara>
sapi_windows_cp_is_utf8()
</simpara>
</listitem>
<listitem>
<simpara>
sapi_windows_cp_conv() to convert between codepages, using iconv() compatible signature
</simpara>
</listitem>
</itemizedlist>
<para>
These functions are thread safe.
</para>
<para>
The console output codepage is adjusted depending on the encoding used in
PHP. Depending on the concrete system OEM codepage, the visible output
might or might be not correct. For example, in the default cmd.exe and on
a system with the OEM codepage 437, outputs in codepages 1251, 1252, 1253
and some others can be shown correctly when using UTF-8. On the same system,
chars in codepage like 20932 probably won't be shown correctly. This refers
to the particular system rules for codepage, font compatibility and the
particular console program used. PHP automatically sets the console codepage
according to the encoding rules from php.ini. Using alternative consoles
instead of cmd.exe directly might bring better experience in some cases.
</para>
<para>
Nevertheless be aware, runtime codepage switch after the request start
might bring unexpected side effects on CLI. The preferable way is php.ini,
When PHP CLI is used in a console emulator, that doesn't support Unicode,
it might possibly be required, to avoid changing the console codepage. The
best way to achieve it is by setting the default or internal encoding to
correspond the ANSI codepage. Another method is to set the INI directives
output_encoding and input_encoding to the required codepage, in which case
however the difference between internal and I/O codepage is likely to cause
mojibake. In rare cases, if PHP happens to crash gracefully, the original
console codepage might be not restored. In this case, the chcp command
can be used, to restore it manually.
</para>
<para>
Special awareness for the DBCS systems - the codepage switch on runtime
using <function>ini_set</function> is likely to cause display issues. The difference to the
non DBCS systems is, that the extended characters require two console cells
to be displayed. In certain case, only the mapping of the characters into
the glyph set of the font could happen, no actual font change. This is the
nature of DBCS systems, the most simple way to prevent display issues is
to avoid usage of <function>ini_set</function> for the codepage change.
</para>
<para>
As a result of UTF-8 support in the streams, PHP scripts are not limited
to ASCII or ANSI filenames anymore. This is supported out of the box on
CLI. For other SAPI, the documentation for the corresponding server
is useful.
</para>
<para>
Long paths support is transparent. Paths longer than 260 bytes get
automatically prefixed with <literal>\\?\</literal>. The max path length is limited to
2048 bytes. Be aware, that the path segment limit (basename length) still
persists.
</para>
<para>
For the best portability, it is strongely recommended to handle filenames,
I/O and other related topics UTF-8. Additionally, for the console applications,
the usage of a TrueType font is preferable and the usage of ini_set() for
the codepage change is discouraged.
</para>
<para>
</para>
<para>
</para>
</sect2>
<sect2 xml:id="migration71.windows-support.readline">
<title>readline</title>
<para>
The <link linkend="book.readline">readline extension</link> is supported
through the <link xlink:href="&url.readline.windows;">WinEditLine
library</link>. Thereby, the interactive <acronym>CLI</acronym> shell is
supported as well (<literal>php.exe -a</literal>).
</para>
</sect2>
<sect2 xml:id="migration71.windows-support.php-fcgi-children">
<title>PHP_FCGI_CHILDREN</title>
<para>
<varname>PHP_FCGI_CHILDREN</varname> is now respected. If this environment variable is
defined, the first <filename>php-cgi.exe</filename> process will exec the specified number
of children. These will share the same TCP socket.
</para>
</sect2>
<sect2 xml:id="migration71.windows-support.ftok">
<title>ftok()</title>
<para>
Added support for <function>ftok</function>
</para>
</sect2>
</sect1>
<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-omittag:t
sgml-shorttag:t
sgml-minimize-attributes:nil
sgml-always-quote-attributes:t
sgml-indent-step:1
sgml-indent-data:t
indent-tabs-mode:nil
sgml-parent-document:nil
sgml-default-dtd-file:"~/.phpdoc/manual.ced"
sgml-exposed-tags:nil
sgml-local-catalogs:nil
sgml-local-ecat-files:nil
End:
vim600: syn=xml fen fdm=syntax fdl=2 si
vim: et tw=78 syn=sgml
vi: ts=1 sw=1
-->
|
