X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=blobdiff_plain;f=lib%2Futf8.pm;h=5a37aecba87ccc2d8d08c3387115da0cf7d8bcc9;hb=fd20da51661b685c54940aeb116a97beabf44d0f;hp=f9055b5dd907681889248d977d79218c41b9a9b6;hpb=4ac9195fe27b27610b09db5d1e9a4a36a7b59787;p=p5sagit%2Fp5-mst-13.2.git diff --git a/lib/utf8.pm b/lib/utf8.pm index f9055b5..5a37aec 100644 --- a/lib/utf8.pm +++ b/lib/utf8.pm @@ -1,7 +1,5 @@ package utf8; -if (ord('A') != 193) { # make things more pragmatic for EBCDIC folk - $utf8::hint_bits = 0x00800000; our $VERSION = '1.00'; @@ -21,14 +19,12 @@ sub AUTOLOAD { Carp::croak("Undefined subroutine $AUTOLOAD called"); } -} - 1; __END__ =head1 NAME -utf8 - Perl pragma to enable/disable UTF-8 in source code +utf8 - Perl pragma to enable/disable UTF-8 (or UTF-EBCDIC) in source code =head1 SYNOPSIS @@ -37,13 +33,10 @@ utf8 - Perl pragma to enable/disable UTF-8 in source code =head1 DESCRIPTION -WARNING: The implementation of Unicode support in Perl is incomplete. -See L for the exact details. - The C pragma tells the Perl parser to allow UTF-8 in the -program text in the current lexical scope. The C pragma -tells Perl to switch back to treating the source text as literal -bytes in the current lexical scope. +program text in the current lexical scope (allow UTF-EBCDIC on EBCDIC based +platforms). The C pragma tells Perl to switch back to treating +the source text as literal bytes in the current lexical scope. This pragma is primarily a compatibility device. Perl versions earlier than 5.6 allowed arbitrary bytes in source code, whereas @@ -51,36 +44,107 @@ in future we would like to standardize on the UTF-8 encoding for source text. Until UTF-8 becomes the default format for source text, this pragma should be used to recognize UTF-8 in the source. When UTF-8 becomes the standard source format, this pragma will -effectively become a no-op. This pragma already is a no-op on -EBCDIC platforms (where it is alright to code perl in EBCDIC -rather than UTF-8). +effectively become a no-op. For convenience in what follows the +term I is used to refer to UTF-8 on ASCII and ISO Latin based +platforms and UTF-EBCDIC on EBCDIC based platforms. -Enabling the C pragma has the following effects: +Enabling the C pragma has the following effect: =over 4 =item * Bytes in the source text that have their high-bit set will be treated -as being part of a literal UTF-8 character. This includes most literals -such as identifiers, string constants, constant regular expression patterns -and package names. +as being part of a literal UTF-8 character. This includes most +literals such as identifier names, string constants, and constant +regular expression patterns. -=item * +On EBCDIC platforms characters in the Latin 1 character set are +treated as being part of a literal UTF-EBCDIC character. -In the absence of inputs marked as UTF-8, regular expressions within the -scope of this pragma will default to using character semantics instead -of byte semantics. +=back + +Note that if you have bytes with the eighth bit on in your script +(for example embedded Latin-1 in your string literals), C +will be unhappy since the bytes are most probably not well-formed +UTF-8. If you want to have such bytes and use utf8, you can disable +utf8 until the end the block (or file, if at top level) by C. + +=head2 Utility functions + +The following functions are defined in the C package by the perl core. + +=over 4 - @bytes_or_chars = split //, $data; # may split to bytes if data - # $data isn't UTF-8 - { - use utf8; # force char semantics - @chars = split //, $data; # splits characters - } +=item * $num_octets = utf8::upgrade($string); + +Converts (in-place) internal representation of string to Perl's internal +I form. Returns the number of octets necessary to represent +the string as I. Can be used to make sure that the +UTF-8 flag is on, so that C<\w> or C work as expected on strings +containing characters in the range 0x80-0xFF. Note that this should +not be used to convert +a legacy byte encoding to Unicode: use Encode for that. Affected +by the encoding pragma. + +=item * utf8::downgrade($string[, FAIL_OK]) + +Converts (in-place) internal representation of string to be un-encoded +bytes. Returns true on success. On failure dies or, if the value of +FAIL_OK is true, returns false. Can be used to make sure that the +UTF-8 flag is off, e.g. when you want to make sure that the substr() +or length() function works with the usually faster byte algorithm. +Note that this should not be used to convert Unicode back to a legacy +byte encoding: use Encode for that. B affected by the encoding +pragma. + +=item * utf8::encode($string) + +Converts (in-place) I<$string> from logical characters to octet +sequence representing it in Perl's I encoding. Same as +Encode::encode_utf8(). Note that this should not be used to convert +a legacy byte encoding to Unicode: use Encode for that. + +=item * $flag = utf8::decode($string) + +Attempts to convert I<$string> in-place from Perl's I encoding +into logical characters. Same as Encode::decode_utf8(). Note that this +should not be used to convert Unicode back to a legacy byte encoding: +use Encode for that. + +=item * $flag = utf8::valid(STRING) + +[INTERNAL] Test whether STRING is in a consistent state. Will return +true if string is held as bytes, or is well-formed UTF-8 and has the +UTF-8 flag on. Main reason for this routine is to allow Perl's +testsuite to check that operations have left strings in a consistent +state. =back +C is like C, but the UTF8 flag is +cleared. See L for more on the UTF8 flag and the C API +functions C, C, C, +and C, which are wrapped by the Perl functions +C, C, C and +C. Note that in the Perl 5.8.0 implementation the +functions utf8::valid, utf8::encode, utf8::decode, utf8::upgrade, +and utf8::downgrade are always available, without a C +statement-- this may change in future releases. + +=head1 BUGS + +One can have Unicode in identifier names, but not in package/class or +subroutine names. While some limited functionality towards this does +exist as of Perl 5.8.0, that is more accidental than designed; use of +Unicode for the said purposes is unsupported. + +One reason of this unfinishedness is its (currently) inherent +unportability: since both package names and subroutine names may need +to be mapped to file and directory names, the Unicode capability of +the filesystem becomes important-- and there unfortunately aren't +portable answers. + =head1 SEE ALSO L, L