perllocale.pod

MSYS在windows下模拟了一个类unix的终端

=item *

The date and day names in dates formatted by strftime() could be
manipulated to advantage by a malicious user able to subvert the
C<LC_DATE> locale.  ("Look--it says I wasn't in the building on
Sunday.")

=back

Such dangers are not peculiar to the locale system: any aspect of an
application's environment which may be modified maliciously presents
similar challenges.  Similarly, they are not specific to Perl: any
programming language that allows you to write programs that take
account of their environment exposes you to these issues.

Perl cannot protect you from all possibilities shown in the
examples--there is no substitute for your own vigilance--but, when
C<use locale> is in effect, Perl uses the tainting mechanism (see
L<perlsec>) to mark string results that become locale-dependent, and
which may be untrustworthy in consequence.  Here is a summary of the
tainting behavior of operators and functions that may be affected by
the locale:

=over 4

=item  *

B<Comparison operators> (C<lt>, C<le>, C<ge>, C<gt> and C<cmp>):

Scalar true/false (or less/equal/greater) result is never tainted.

=item  *

B<Case-mapping interpolation> (with C<\l>, C<\L>, C<\u> or C<\U>)

Result string containing interpolated material is tainted if
C<use locale> is in effect.

=item  *

B<Matching operator> (C<m//>):

Scalar true/false result never tainted.

Subpatterns, either delivered as a list-context result or as $1 etc.
are tainted if C<use locale> is in effect, and the subpattern regular
expression contains C<\w> (to match an alphanumeric character), C<\W>
(non-alphanumeric character), C<\s> (white-space character), or C<\S>
(non white-space character).  The matched-pattern variable, $&, $`
(pre-match), $' (post-match), and $+ (last match) are also tainted if
C<use locale> is in effect and the regular expression contains C<\w>,
C<\W>, C<\s>, or C<\S>.

=item  *

B<Substitution operator> (C<s///>):

Has the same behavior as the match operator.  Also, the left
operand of C<=~> becomes tainted when C<use locale> in effect
if modified as a result of a substitution based on a regular
expression match involving C<\w>, C<\W>, C<\s>, or C<\S>; or of
case-mapping with C<\l>, C<\L>,C<\u> or C<\U>.

=item  *

B<Output formatting functions> (printf() and write()):

Results are never tainted because otherwise even output from print,
for example C<print(1/7)>, should be tainted if C<use locale> is in
effect.

=item  *

B<Case-mapping functions> (lc(), lcfirst(), uc(), ucfirst()):

Results are tainted if C<use locale> is in effect.

=item  *

B<POSIX locale-dependent functions> (localeconv(), strcoll(),
strftime(), strxfrm()):

Results are never tainted.

=item  *

B<POSIX character class tests> (isalnum(), isalpha(), isdigit(),
isgraph(), islower(), isprint(), ispunct(), isspace(), isupper(),
isxdigit()):

True/false results are never tainted.

=back

Three examples illustrate locale-dependent tainting.
The first program, which ignores its locale, won't run: a value taken
directly from the command line may not be used to name an output file
when taint checks are enabled.

        #/usr/local/bin/perl -T
        # Run with taint checking

        # Command line sanity check omitted...
        $tainted_output_file = shift;

        open(F, ">$tainted_output_file")
            or warn "Open of $untainted_output_file failed: $!\n";

The program can be made to run by "laundering" the tainted value through
a regular expression: the second example--which still ignores locale
information--runs, creating the file named on its command line
if it can.

        #/usr/local/bin/perl -T

        $tainted_output_file = shift;
        $tainted_output_file =~ m%[\w/]+%;
        $untainted_output_file = $&;

        open(F, ">$untainted_output_file")
            or warn "Open of $untainted_output_file failed: $!\n";

Compare this with a similar but locale-aware program:

        #/usr/local/bin/perl -T

        $tainted_output_file = shift;
        use locale;
        $tainted_output_file =~ m%[\w/]+%;
        $localized_output_file = $&;

        open(F, ">$localized_output_file")
            or warn "Open of $localized_output_file failed: $!\n";

This third program fails to run because $& is tainted: it is the result
of a match involving C<\w> while C<use locale> is in effect.

=head1 ENVIRONMENT

=over 12

=item PERL_BADLANG

A string that can suppress Perl's warning about failed locale settings
at startup.  Failure can occur if the locale support in the operating
system is lacking (broken) in some way--or if you mistyped the name of
a locale when you set up your environment.  If this environment
variable is absent, or has a value that does not evaluate to integer
zero--that is, "0" or ""-- Perl will complain about locale setting
failures.

B<NOTE>: PERL_BADLANG only gives you a way to hide the warning message.
The message tells about some problem in your system's locale support,
and you should investigate what the problem is.

=back

The following environment variables are not specific to Perl: They are
part of the standardized (ISO C, XPG4, POSIX 1.c) setlocale() method
for controlling an application's opinion on data.

=over 12

=item LC_ALL

C<LC_ALL> is the "override-all" locale environment variable. If
set, it overrides all the rest of the locale environment variables.

=item LANGUAGE

B<NOTE>: C<LANGUAGE> is a GNU extension, it affects you only if you
are using the GNU libc.  This is the case if you are using e.g. Linux.
If you are using "commercial" UNIXes you are most probably I<not>
using GNU libc and you can ignore C<LANGUAGE>.

However, in the case you are using C<LANGUAGE>: it affects the
language of informational, warning, and error messages output by
commands (in other words, it's like C<LC_MESSAGES>) but it has higher
priority than L<LC_ALL>.  Moreover, it's not a single value but
instead a "path" (":"-separated list) of I<languages> (not locales).
See the GNU C<gettext> library documentation for more information.

=item LC_CTYPE

In the absence of C<LC_ALL>, C<LC_CTYPE> chooses the character type
locale.  In the absence of both C<LC_ALL> and C<LC_CTYPE>, C<LANG>
chooses the character type locale.

=item LC_COLLATE

In the absence of C<LC_ALL>, C<LC_COLLATE> chooses the collation
(sorting) locale.  In the absence of both C<LC_ALL> and C<LC_COLLATE>,
C<LANG> chooses the collation locale.

=item LC_MONETARY

In the absence of C<LC_ALL>, C<LC_MONETARY> chooses the monetary
formatting locale.  In the absence of both C<LC_ALL> and C<LC_MONETARY>,
C<LANG> chooses the monetary formatting locale.

=item LC_NUMERIC

In the absence of C<LC_ALL>, C<LC_NUMERIC> chooses the numeric format
locale.  In the absence of both C<LC_ALL> and C<LC_NUMERIC>, C<LANG>
chooses the numeric format.

=item LC_TIME

In the absence of C<LC_ALL>, C<LC_TIME> chooses the date and time
formatting locale.  In the absence of both C<LC_ALL> and C<LC_TIME>,
C<LANG> chooses the date and time formatting locale.

=item LANG

C<LANG> is the "catch-all" locale environment variable. If it is set, it
is used as the last resort after the overall C<LC_ALL> and the
category-specific C<LC_...>.

=back

=head1 NOTES

=head2 Backward compatibility

Versions of Perl prior to 5.004 B<mostly> ignored locale information,
generally behaving as if something similar to the C<"C"> locale were
always in force, even if the program environment suggested otherwise
(see L<The setlocale function>).  By default, Perl still behaves this
way for backward compatibility.  If you want a Perl application to pay
attention to locale information, you B<must> use the S<C<use locale>>
pragma (see L<The use locale pragma>) to instruct it to do so.

Versions of Perl from 5.002 to 5.003 did use the C<LC_CTYPE>
information if available; that is, C<\w> did understand what
were the letters according to the locale environment variables.
The problem was that the user had no control over the feature:
if the C library supported locales, Perl used them.

=head2 I18N:Collate obsolete

In versions of Perl prior to 5.004, per-locale collation was possible
using the C<I18N::Collate> library module.  This module is now mildly
obsolete and should be avoided in new applications.  The C<LC_COLLATE>
functionality is now integrated into the Perl core language: One can
use locale-specific scalar data completely normally with C<use locale>,
so there is no longer any need to juggle with the scalar references of
C<I18N::Collate>.

=head2 Sort speed and memory use impacts

Comparing and sorting by locale is usually slower than the default
sorting; slow-downs of two to four times have been observed.  It will
also consume more memory: once a Perl scalar variable has participated
in any string comparison or sorting operation obeying the locale
collation rules, it will take 3-15 times more memory than before.  (The
exact multiplier depends on the string's contents, the operating system
and the locale.) These downsides are dictated more by the operating
system's implementation of the locale system than by Perl.

=head2 write() and LC_NUMERIC

Formats are the only part of Perl that unconditionally use information
from a program's locale; if a program's environment specifies an
LC_NUMERIC locale, it is always used to specify the decimal point
character in formatted output.  Formatted output cannot be controlled by
C<use locale> because the pragma is tied to the block structure of the
program, and, for historical reasons, formats exist outside that block
structure.

=head2 Freely available locale definitions

There is a large collection of locale definitions at
C<ftp://dkuug.dk/i18n/WG15-collection>.  You should be aware that it is
unsupported, and is not claimed to be fit for any purpose.  If your
system allows installation of arbitrary locales, you may find the
definitions useful as they are, or as a basis for the development of
your own locales.

=head2 I18n and l10n

"Internationalization" is often abbreviated as B<i18n> because its first
and last letters are separated by eighteen others.  (You may guess why
the internalin ... internaliti ... i18n tends to get abbreviated.)  In
the same way, "localization" is often abbreviated to B<l10n>.

=head2 An imperfect standard

Internationalization, as defined in the C and POSIX standards, can be
criticized as incomplete, ungainly, and having too large a granularity.
(Locales apply to a whole process, when it would arguably be more useful
to have them apply to a single thread, window group, or whatever.)  They
also have a tendency, like standards groups, to divide the world into
nations, when we all know that the world can equally well be divided
into bankers, bikers, gamers, and so on.  But, for now, it's the only
standard we've got.  This may be construed as a bug.

=head1 BUGS

=head2 Broken systems

In certain systems, the operating system's locale support
is broken and cannot be fixed or used by Perl.  Such deficiencies can
and will result in mysterious hangs and/or Perl core dumps when the
C<use locale> is in effect.  When confronted with such a system,
please report in excruciating detail to <F<[e-mail]>>, and
complain to your vendor: bug fixes may exist for these problems
in your operating system.  Sometimes such bug fixes are called an
operating system upgrade.

=head1 SEE ALSO

L<POSIX/isalnum>, L<POSIX/isalpha>, L<POSIX/isdigit>, 
L<POSIX/isgraph>, L<POSIX/islower>, L<POSIX/isprint>, 
L<POSIX/ispunct>, L<POSIX/isspace>, L<POSIX/isupper>, 
L<POSIX/isxdigit>, L<POSIX/localeconv>, L<POSIX/setlocale>, 
L<POSIX/strcoll>, L<POSIX/strftime>, L<POSIX/strtod>, 
L<POSIX/strxfrm>.

=head1 HISTORY

Jarkko Hietaniemi's original F<perli18n.pod> heavily hacked by Dominic
Dunlop, assisted by the perl5-porters.  Prose worked over a bit by
Tom Christiansen.

Last update: Thu Jun 11 08:44:13 MDT 1998