=head1 DESCRIPTION
-=head2 Important Caveat
+=head2 Important Caveats
-WARNING: The implementation of Unicode support in Perl is incomplete.
+WARNING: While the implementation of Unicode support in Perl is now fairly
+complete it is still evolving to some extent.
-The following areas need further work.
+In particular the way Unicode is handled on EBCDIC platforms is still rather
+experimental. On such a platform references to UTF-8 encoding in this
+document and elsewhere should be read as meaning UTF-EBCDIC as specified
+in Unicode Technical Report 16 unless ASCII vs EBCDIC issues are specifically
+discussed. There is no C<utfebcdic> pragma or ":utfebcdic" layer, rather
+"utf8" and ":utf8" are re-used to mean platform's "natural" 8-bit encoding
+of Unicode. See L<perlebcdic> for more discussion of the issues.
+
+The following areas are still under development.
=over 4
=item Input and Output Disciplines
-There is currently no easy way to mark data read from a file or other
-external source as being utf8. This will be one of the major areas of
-focus in the near future.
+A filehandle can be marked as containing perl's internal Unicode encoding
+(UTF-8 or UTF-EBCDIC) by opening it with the ":utf8" layer.
+Other encodings can be converted to perl's encoding on input, or from
+perl's encoding on output by use of the ":encoding()" layer.
+There is not yet a clean way to mark the perl source itself as being
+in an particular encoding.
=item Regular Expressions
-The existing regular expression compiler does not produce polymorphic
-opcodes. This means that the determination on whether to match Unicode
-characters is made when the pattern is compiled, based on whether the
-pattern contains Unicode characters, and not when the matching happens
-at run time. This needs to be changed to adaptively match Unicode if
-the string to be matched is Unicode.
+The regular expression compiler does now attempt to produce
+polymorphic opcodes. That is the pattern should now adapt to the data
+and automatically switch to the Unicode character scheme when presented
+with Unicode data, or a traditional byte scheme when presented with
+byte data. The implementation is still new and (particularly on
+EBCDIC platforms) may need further work.
=item C<use utf8> still needed to enable a few features
However, as a compatibility measure, this pragma must be explicitly used
to enable recognition of UTF-8 encoded literals and identifiers in the
-source text.
+source text on ASCII based machines or recognize UTF-EBCDIC encoded literals
+and identifiers on EBCDIC based machines.
=back
Beginning with version 5.6, Perl uses logically wide characters to
represent strings internally. This internal representation of strings
-uses the UTF-8 encoding.
+uses either the UTF-8 or the UTF-EBCDIC encoding.
In future, Perl-level operations can be expected to work with characters
rather than bytes, in general.
If the C<-C> command line switch is used, (or the ${^WIDE_SYSTEM_CALLS}
global flag is set to C<1>), all system calls will use the
corresponding wide character APIs. This is currently only implemented
-on Windows.
+on Windows since UNIXes lack API standard on this area.
Regardless of the above, the C<bytes> pragma can always be used to force
byte semantics in a particular lexical scope. See L<bytes>.
The C<utf8> pragma is primarily a compatibility device that enables
-recognition of UTF-8 in literals encountered by the parser. It may also
+recognition of UTF-(8|EBCDIC) in literals encountered by the parser. It may also
be used for enabling some of the more experimental Unicode support features.
Note that this pragma is only required until a future version of Perl
in which character semantics will become the default. This pragma may
no difference, because UTF-8 stores ASCII in single bytes, but for
any character greater than C<chr(127)>, the character may be stored in
a sequence of two or more bytes, all of which have the high bit set.
+For C1 controls or Latin 1 characters on an EBCDIC platform the character
+may be stored in a UTF-EBCDIC multi byte sequence.
But by and large, the user need not worry about this, because Perl
hides it from the user. A character in Perl is logically just a number
ranging from 0 to 2**32 or so. Larger characters encode to longer
larger than 255.
Presuming you use a Unicode editor to edit your program, such characters
-will typically occur directly within the literal strings as UTF-8
+will typically occur directly within the literal strings as UTF-(8|EBCDIC)
characters, but you can also specify a particular character with an
-extension of the C<\x> notation. UTF-8 characters are specified by
+extension of the C<\x> notation. UTF-X characters are specified by
putting the hexadecimal code within curlies after the C<\x>. For instance,
a Unicode smiley face is C<\x{263A}>.
classes via the new C<\p{}> (matches property) and C<\P{}> (doesn't
match property) constructs. For instance, C<\p{Lu}> matches any
character with the Unicode uppercase property, while C<\p{M}> matches
-any mark character. Single letter properties may omit the brackets, so
-that can be written C<\pM> also. Many predefined character classes are
-available, such as C<\p{IsMirrored}> and C<\p{InTibetan}>.
+any mark character. Single letter properties may omit the brackets,
+so that can be written C<\pM> also. Many predefined character classes
+are available, such as C<\p{IsMirrored}> and C<\p{InTibetan}>. The
+names of the C<In> classes are the official Unicode block names but
+with all non-alphanumeric characters removed, for example the block
+name C<"Latin-1 Supplement"> becomes C<\p{InLatin1Supplement}>.
=item *
=item *
+The bit string operators C<& | ^ ~> can operate on character data.
+However, for backward compatibility reasons (bit string operations
+when the characters all are less than 256 in ordinal value) one cannot
+mix C<~> (the bit complement) and characters both less than 256 and
+equal or greater than 256. Most importantly, the DeMorgan's laws
+(C<~($x|$y) eq ~$x&~$y>, C<~($x&$y) eq ~$x|~$y>) won't hold.
+Another way to look at this is that the complement cannot return
+B<both> the 8-bit (byte) wide bit complement, and the full character
+wide bit complement.
+
+=item *
+
And finally, C<scalar reverse()> reverses by character rather than by byte.
=back
=head2 Character encodings for input and output
-[XXX: This feature is not yet implemented.]
+See L<Encode>.
=head1 CAVEATS
As of yet, there is no method for automatically coercing input and
-output to some encoding other than UTF-8. This is planned in the near
-future, however.
+output to some encoding other than UTF-8 or UTF-EBCDIC. This is planned
+in the near future, however.
Whether an arbitrary piece of data will be treated as "characters" or
"bytes" by internal operations cannot be divined at the current time.
projects / p5sagit/p5-mst-13.2.git / blobdiff