perllocale.1

视频监控网络部分的协议ddns,的模块的实现代码,请大家大胆指正.

Sunday = 1) and two more constants for the affirmative and negative
answers for a yes/no question in the current locale.
.PP
.Vb 1
\&    use I18N::Langinfo qw(langinfo ABDAY_1 YESSTR NOSTR);
\&
\&    my ($abday_1, $yesstr, $nostr) = map { langinfo } qw(ABDAY_1 YESSTR NOSTR);
\&
\&    print "$abday_1? [$yesstr/$nostr] ";
.Ve
.PP
In other words, in the \*(L"C\*(R" (or English) locale the above will probably
print something like:
.PP
.Vb 1
\&    Sun? [yes/no]
.Ve
.PP
See I18N::Langinfo for more information.
.SH "LOCALE CATEGORIES"
.IX Header "LOCALE CATEGORIES"
The following subsections describe basic locale categories.  Beyond these,
some combination categories allow manipulation of more than one
basic category at a time.  See \*(L"\s-1ENVIRONMENT\s0\*(R" for a discussion of these.
.Sh "Category \s-1LC_COLLATE:\s0 Collation"
.IX Subsection "Category LC_COLLATE: Collation"
In the scope of \f(CW\*(C`use\ locale\*(C'\fR, Perl looks to the \f(CW\*(C`LC_COLLATE\*(C'\fR
environment variable to determine the application's notions on collation
(ordering) of characters.  For example, 'b' follows 'a' in Latin
alphabets, but where do 'a\*'' and 'a\*o' belong?  And while
\&'color' follows 'chocolate' in English, what about in Spanish?
.PP
The following collations all make sense and you may meet any of them
if you \*(L"use locale\*(R".
.PP
.Vb 4
\&        A B C D E a b c d e
\&        A a B b C c D d E e
\&        a A b B c C d D e E
\&        a b c d e A B C D E
.Ve
.PP
Here is a code snippet to tell what \*(L"word\*(R"
characters are in the current locale, in that locale's order:
.PP
.Vb 2
\&        use locale;
\&        print +(sort grep /\ew/, map { chr } 0..255), "\en";
.Ve
.PP
Compare this with the characters that you see and their order if you
state explicitly that the locale should be ignored:
.PP
.Vb 2
\&        no locale;
\&        print +(sort grep /\ew/, map { chr } 0..255), "\en";
.Ve
.PP
This machine-native collation (which is what you get unless \f(CW\*(C`use\ locale\*(C'\fR has appeared earlier in the same block) must be used for
sorting raw binary data, whereas the locale-dependent collation of the
first example is useful for natural text.
.PP
As noted in \*(L"\s-1USING\s0 \s-1LOCALES\s0\*(R", \f(CW\*(C`cmp\*(C'\fR compares according to the current
collation locale when \f(CW\*(C`use locale\*(C'\fR is in effect, but falls back to a
char-by-char comparison for strings that the locale says are equal. You
can use \fIPOSIX::strcoll()\fR if you don't want this fall-back:
.PP
.Vb 3
\&        use POSIX qw(strcoll);
\&        $equal_in_locale =
\&            !strcoll("space and case ignored", "SpaceAndCaseIgnored");
.Ve
.PP
\&\f(CW$equal_in_locale\fR will be true if the collation locale specifies a
dictionary-like ordering that ignores space characters completely and
which folds case.
.PP
If you have a single string that you want to check for \*(L"equality in
locale\*(R" against several others, you might think you could gain a little
efficiency by using \fIPOSIX::strxfrm()\fR in conjunction with \f(CW\*(C`eq\*(C'\fR:
.PP
.Vb 8
\&        use POSIX qw(strxfrm);
\&        $xfrm_string = strxfrm("Mixed\-case string");
\&        print "locale collation ignores spaces\en"
\&            if $xfrm_string eq strxfrm("Mixed\-casestring");
\&        print "locale collation ignores hyphens\en"
\&            if $xfrm_string eq strxfrm("Mixedcase string");
\&        print "locale collation ignores case\en"
\&            if $xfrm_string eq strxfrm("mixed\-case string");
.Ve
.PP
\&\fIstrxfrm()\fR takes a string and maps it into a transformed string for use
in char-by-char comparisons against other transformed strings during
collation.  \*(L"Under the hood\*(R", locale-affected Perl comparison operators
call \fIstrxfrm()\fR for both operands, then do a char-by-char
comparison of the transformed strings.  By calling \fIstrxfrm()\fR explicitly
and using a non locale-affected comparison, the example attempts to save
a couple of transformations.  But in fact, it doesn't save anything: Perl
magic (see \*(L"Magic Variables\*(R" in perlguts) creates the transformed version of a
string the first time it's needed in a comparison, then keeps this version around
in case it's needed again.  An example rewritten the easy way with
\&\f(CW\*(C`cmp\*(C'\fR runs just about as fast.  It also copes with null characters
embedded in strings; if you call \fIstrxfrm()\fR directly, it treats the first
null it finds as a terminator.  don't expect the transformed strings
it produces to be portable across systems\*(--or even from one revision
of your operating system to the next.  In short, don't call \fIstrxfrm()\fR
directly: let Perl do it for you.
.PP
Note: \f(CW\*(C`use locale\*(C'\fR isn't shown in some of these examples because it isn't
needed: \fIstrcoll()\fR and \fIstrxfrm()\fR exist only to generate locale-dependent
results, and so always obey the current \f(CW\*(C`LC_COLLATE\*(C'\fR locale.
.Sh "Category \s-1LC_CTYPE:\s0 Character Types"
.IX Subsection "Category LC_CTYPE: Character Types"
In the scope of \f(CW\*(C`use\ locale\*(C'\fR, Perl obeys the \f(CW\*(C`LC_CTYPE\*(C'\fR locale
setting.  This controls the application's notion of which characters are
alphabetic.  This affects Perl's \f(CW\*(C`\ew\*(C'\fR regular expression metanotation,
which stands for alphanumeric characters\*(--that is, alphabetic,
numeric, and including other special characters such as the underscore or
hyphen.  (Consult perlre for more information about
regular expressions.)  Thanks to \f(CW\*(C`LC_CTYPE\*(C'\fR, depending on your locale
setting, characters like '\*(ae', '\*(d\-', '\*8', and
\&'o\*/' may be understood as \f(CW\*(C`\ew\*(C'\fR characters.
.PP
The \f(CW\*(C`LC_CTYPE\*(C'\fR locale also provides the map used in transliterating
characters between lower and uppercase.  This affects the case-mapping
functions\*(--\fIlc()\fR, lcfirst, \fIuc()\fR, and \fIucfirst()\fR; case-mapping
interpolation with \f(CW\*(C`\el\*(C'\fR, \f(CW\*(C`\eL\*(C'\fR, \f(CW\*(C`\eu\*(C'\fR, or \f(CW\*(C`\eU\*(C'\fR in double-quoted strings
and \f(CW\*(C`s///\*(C'\fR substitutions; and case-independent regular expression
pattern matching using the \f(CW\*(C`i\*(C'\fR modifier.
.PP
Finally, \f(CW\*(C`LC_CTYPE\*(C'\fR affects the \s-1POSIX\s0 character-class test
functions\*(--\fIisalpha()\fR, \fIislower()\fR, and so on.  For example, if you move
from the \*(L"C\*(R" locale to a 7\-bit Scandinavian one, you may find\*(--possibly
to your surprise\*(--that \*(L"|\*(R" moves from the \fIispunct()\fR class to \fIisalpha()\fR.
.PP
\&\fBNote:\fR A broken or malicious \f(CW\*(C`LC_CTYPE\*(C'\fR locale definition may result
in clearly ineligible characters being considered to be alphanumeric by
your application.  For strict matching of (mundane) letters and
digits\*(--for example, in command strings\*(--locale\-aware applications
should use \f(CW\*(C`\ew\*(C'\fR inside a \f(CW\*(C`no locale\*(C'\fR block.  See \*(L"\s-1SECURITY\s0\*(R".
.Sh "Category \s-1LC_NUMERIC:\s0 Numeric Formatting"
.IX Subsection "Category LC_NUMERIC: Numeric Formatting"
After a proper \fIPOSIX::setlocale()\fR call, Perl obeys the \f(CW\*(C`LC_NUMERIC\*(C'\fR
locale information, which controls an application's idea of how numbers
should be formatted for human readability by the \fIprintf()\fR, \fIsprintf()\fR, and
\&\fIwrite()\fR functions. String-to-numeric conversion by the \fIPOSIX::strtod()\fR
function is also affected.  In most implementations the only effect is to
change the character used for the decimal point\*(--perhaps from '.'  to ','.
These functions aren't aware of such niceties as thousands separation and
so on. (See \*(L"The localeconv function\*(R" if you care about these things.)
.PP
Output produced by \fIprint()\fR is also affected by the current locale: it
corresponds to what you'd get from \fIprintf()\fR in the \*(L"C\*(R" locale.  The
same is true for Perl's internal conversions between numeric and
string formats:
.PP
.Vb 1
\&        use POSIX qw(strtod setlocale LC_NUMERIC);
\&
\&        setlocale LC_NUMERIC, "";
\&
\&        $n = 5/2;   # Assign numeric 2.5 to $n
\&
\&        $a = " $n"; # Locale\-dependent conversion to string
\&
\&        print "half five is $n\en";       # Locale\-dependent output
\&
\&        printf "half five is %g\en", $n;  # Locale\-dependent output
\&
\&        print "DECIMAL POINT IS COMMA\en"
\&            if $n == (strtod("2,5"))[0]; # Locale\-dependent conversion
.Ve
.PP
See also I18N::Langinfo and \f(CW\*(C`RADIXCHAR\*(C'\fR.
.Sh "Category \s-1LC_MONETARY:\s0 Formatting of monetary amounts"
.IX Subsection "Category LC_MONETARY: Formatting of monetary amounts"
The C standard defines the \f(CW\*(C`LC_MONETARY\*(C'\fR category, but no function
that is affected by its contents.  (Those with experience of standards
committees will recognize that the working group decided to punt on the
issue.)  Consequently, Perl takes no notice of it.  If you really want
to use \f(CW\*(C`LC_MONETARY\*(C'\fR, you can query its contents\*(--see 
\&\*(L"The localeconv function\*(R"\-\-and use the information that it returns in your 
application's own formatting of currency amounts.  However, you may well 
find that the information, voluminous and complex though it may be, still 
does not quite meet your requirements: currency formatting is a hard nut 
to crack.
.PP
See also I18N::Langinfo and \f(CW\*(C`CRNCYSTR\*(C'\fR.
.Sh "\s-1LC_TIME\s0"
.IX Subsection "LC_TIME"
Output produced by \fIPOSIX::strftime()\fR, which builds a formatted
human-readable date/time string, is affected by the current \f(CW\*(C`LC_TIME\*(C'\fR
locale.  Thus, in a French locale, the output produced by the \f(CW%B\fR
format element (full month name) for the first month of the year would
be \*(L"janvier\*(R".  Here's how to get a list of long month names in the
current locale:
.PP
.Vb 5
\&        use POSIX qw(strftime);
\&        for (0..11) {
\&            $long_month_name[$_] =
\&                strftime("%B", 0, 0, 0, 1, $_, 96);
\&        }
.Ve
.PP
Note: \f(CW\*(C`use locale\*(C'\fR isn't needed in this example: as a function that
exists only to generate locale-dependent results, \fIstrftime()\fR always
obeys the current \f(CW\*(C`LC_TIME\*(C'\fR locale.
.PP
See also I18N::Langinfo and \f(CW\*(C`ABDAY_1\*(C'\fR..\f(CW\*(C`ABDAY_7\*(C'\fR, \f(CW\*(C`DAY_1\*(C'\fR..\f(CW\*(C`DAY_7\*(C'\fR,
\&\f(CW\*(C`ABMON_1\*(C'\fR..\f(CW\*(C`ABMON_12\*(C'\fR, and \f(CW\*(C`ABMON_1\*(C'\fR..\f(CW\*(C`ABMON_12\*(C'\fR.
.Sh "Other categories"
.IX Subsection "Other categories"
The remaining locale category, \f(CW\*(C`LC_MESSAGES\*(C'\fR (possibly supplemented
by others in particular implementations) is not currently used by
Perl\*(--except possibly to affect the behavior of library functions
called by extensions outside the standard Perl distribution and by the
operating system and its utilities.  Note especially that the string
value of \f(CW$!\fR and the error messages given by external utilities may
be changed by \f(CW\*(C`LC_MESSAGES\*(C'\fR.  If you want to have portable error
codes, use \f(CW\*(C`%!\*(C'\fR.  See Errno.
.SH "SECURITY"
.IX Header "SECURITY"
Although the main discussion of Perl security issues can be found in
perlsec, a discussion of Perl's locale handling would be incomplete
if it did not draw your attention to locale-dependent security issues.
Locales\*(--particularly on systems that allow unprivileged users to
build their own locales\*(--are untrustworthy.  A malicious (or just plain
broken) locale can make a locale-aware application give unexpected
results.  Here are a few possibilities:
.IP "\(bu" 4
Regular expression checks for safe file names or mail addresses using
\&\f(CW\*(C`\ew\*(C'\fR may be spoofed by an \f(CW\*(C`LC_CTYPE\*(C'\fR locale that claims that
characters such as \*(L">\*(R" and \*(L"|\*(R" are alphanumeric.
.IP "\(bu" 4
String interpolation with case-mapping, as in, say, \f(CW\*(C`$dest =
"C:\eU$name.$ext"\*(C'\fR, may produce dangerous results if a bogus \s-1LC_CTYPE\s0
case-mapping table is in effect.
.IP "\(bu" 4
A sneaky \f(CW\*(C`LC_COLLATE\*(C'\fR locale could result in the names of students with
\&\*(L"D\*(R" grades appearing ahead of those with \*(L"A\*(R"s.
.IP "\(bu" 4
An application that takes the trouble to use information in
\&\f(CW\*(C`LC_MONETARY\*(C'\fR may format debits as if they were credits and vice versa
if that locale has been subverted.  Or it might make payments in \s-1US\s0
dollars instead of Hong Kong dollars.
.IP "\(bu" 4
The date and day names in dates formatted by \fIstrftime()\fR could be
manipulated to advantage by a malicious user able to subvert the
\&\f(CW\*(C`LC_DATE\*(C'\fR locale.  (\*(L"Look\*(--it says I wasn't in the building on
Sunday.\*(R")
.PP
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.
.PP
Perl cannot protect you from all possibilities shown in the
examples\*(--there is no substitute for your own vigilance\*(--but, when
\&\f(CW\*(C`use locale\*(C'\fR is in effect, Perl uses the tainting mechanism (see
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:
.IP "\(bu" 4
\&\fBComparison operators\fR (\f(CW\*(C`lt\*(C'\fR, \f(CW\*(C`le\*(C'\fR, \f(CW\*(C`ge\*(C'\fR, \f(CW\*(C`gt\*(C'\fR and \f(CW\*(C`cmp\*(C'\fR):
.Sp
Scalar true/false (or less/equal/greater) result is never tainted.
.IP "\(bu" 4
\&\fBCase-mapping interpolation\fR (with \f(CW\*(C`\el\*(C'\fR, \f(CW\*(C`\eL\*(C'\fR, \f(CW\*(C`\eu\*(C'\fR or \f(CW\*(C`\eU\*(C'\fR)
.Sp
Result string containing interpolated material is tainted if
\&\f(CW\*(C`use locale\*(C'\fR is in effect.
.IP "\(bu" 4
\&\fBMatching operator\fR (\f(CW\*(C`m//\*(C'\fR):
.Sp
Scalar true/false result never tainted.