perlunicode - Unicode support in Perl

目次

NAME 名前

perlunicode - Unicode support in Perl

perlunicode - Perl ユニコードサポート

DESCRIPTION 説明

Important Caveats 重要な警告

Unicode support is an extensive requirement. While Perl does not implement the Unicode standard or the accompanying technical reports from cover to cover, Perl does support many Unicode features.

ユニコードのサポートは大規模な要求です. Perl がユニコード標準を実装 しなかったりそれに伴うはじめから終わりまでの技術レポートを実装していな い一方で, Perl はユニコードの機能をサポートします.

Input and Output Layers

入出力レイヤ

Perl knows when a filehandle uses Perl's internal Unicode encodings (UTF-8, or UTF-EBCDIC if in EBCDIC) if the filehandle is opened 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. See open [CPAN].

もしファイルハンドルを ``:utf8'' レイヤで開いたのなら. Perl は ファイ ルハンドルが Perl の内部 Unicode エンコーディング(UTF-8, もしくは EBCDIC の時は UTF-EBCDIC)を使っている時を知っています. ほかのエンコー ディングでは入力時は Perl のエンコーディングへ, 出力時には Perl の内部 コードから ``:encoding(...)'' レイヤを使うことで変換されることができま す. open [CPAN]も参考にしてください.

To indicate that Perl source itself is using a particular encoding, see encoding [CPAN].

Perl のソースコード自身が特定のエンコーディングを使っていることを示 すためには, encoding [CPAN] を参照してください.

Regular Expressions

正規表現

The regular expression compiler produces polymorphic opcodes. That is, the pattern adapts to the data and automatically switches to the Unicode character scheme when presented with Unicode data--or instead uses a traditional byte scheme when presented with byte data.

正規表現コンパイラは多様なopコードを生成します. すなわち, パターンはデ ータに適合してユニコードデータで表現されている時は自動的にユニコード文 字のスキーマに切り替わります. また, バイトデータとして表現されている時 には伝統的なバイトスキーマを使います.

use utf8 still needed to enable UTF-8/UTF-EBCDIC in scripts

スクリプト中で UTF-8/UTF-EBCDIF を有効化するためには未だ use utf8 が必要です

As a compatibility measure, the use utf8 pragma must be explicitly included to enable recognition of UTF-8 in the Perl scripts themselves (in string or regular expression literals, or in identifier names) on ASCII-based machines or to recognize UTF-EBCDIC on EBCDIC-based machines. These are the only times when an explicit use utf8 is needed. See utf8 [CPAN].

互換措置として, Perl スクリプトの中で (文字列や正規表現リテラル, そし て識別子名として) UTF-8 を認めさせるためには use utf8 プ ラグマを明示的に含めなければなりません. (ASCII ベースのマシンでの話. EBCDIC ベースのマシン上では UTF-EBCDIC を認識するため, と読み替えてく ださい.) use utf8 が必要なのは唯一度のみです. utf8 [CPAN] も参照してください.

You can also use the encoding pragma to change the default encoding of the data in your script; see encoding [CPAN].

スクリプト中のデータのデフォルトのエンコーディングを変えるために encodiong プラグマを用いることもできます.encoding [CPAN] を参照してく ださい.

Byte and Character Semantics バイト(Byte) と文字(Character) の意味

Beginning with version 5.6, Perl uses logically-wide characters to represent strings internally.

Perl ではバージョン 5.6 から, 文字列の内部表現に論理的なワイド文字 を採用しています.

In future, Perl-level operations will be expected to work with characters rather than bytes.

将来的には, Perl レベルでの操作はバイト単位でなく文字単位で処理され ることが予期されています.

However, as an interim compatibility measure, Perl aims to provide a safe migration path from byte semantics to character semantics for programs. For operations where Perl can unambiguously decide that the input data are characters, Perl switches to character semantics. For operations where this determination cannot be made without additional information from the user, Perl decides in favor of compatibility and chooses to use byte semantics.

しかし, 一時的な互換措置として, Perl はバイトセマンティクスから文字 セマンティクスへの安全な移行を提供することを目指しています. Perl が入 力データは文字であると明白に決定することができる操作に対しては, 文字セ マンティクスへと切り替えます. この決定をユーザからの追加情報なしに決定 することができない操作に対しては, 互換を保つために, バイトセマンティク スの使用を選びます.

This behavior preserves compatibility with earlier versions of Perl, which allowed byte semantics in Perl operations only if none of the program's inputs were marked as being as source of Unicode character data. Such data may come from filehandles, from calls to external programs, from information provided by the system (such as %ENV), or from literals and constants in the source text.

この振る舞いは, プログラムの入力に対して Unicode 文字のデータとして マークされているものがないならバイトセマンティクスのみを許す, いままで のバージョンとの互換性を保ちます. そのようなデータは, ファイルハンド ル, 外部プログラムの呼び出し, (%ENV の様な)システムからの提供, またソ ーステキスト内のリテラルや定数からくるでしょう.

On Windows platforms, if the -C command line switch is used or the ${^WIDE_SYSTEM_CALLS} global flag is set to 1, all system calls will use the corresponding wide-character APIs. This feature is available only on Windows to conform to the API standard already established for that platform--and there are very few non-Windows platforms that have Unicode-aware APIs.

Windows プラットホームにおいては, -C> コマンドラインスイッチが 使われているか, ${^WIDE_SYSTEM_CALLS} グローバルフラグが 1 に設定されてい るのなら, すべてのシステムコールは対応するワイド文字の API を使いま す. この機能は Windows のみにおいて, そこですでに確立している標準に従 うために使うことができます. また, ごく少数の Windows 以外の Unicode を 知っているAPI を持っている環境でも使えます.

The bytes pragma will always, regardless of platform, force byte semantics in a particular lexical scope. See bytes [CPAN].

The utf8 pragma is primarily a compatibility device that enables recognition of UTF-(8|EBCDIC) in literals encountered by the parser. Note that this pragma is only required while Perl defaults to byte semantics; when character semantics become the default, this pragma may become a no-op. See utf8 [CPAN].

Unless explicitly stated, Perl operators use character semantics for Unicode data and byte semantics for non-Unicode data. The decision to use character semantics is made transparently. If input data comes from a Unicode source--for example, if a character encoding layer is added to a filehandle or a literal Unicode string constant appears in a program--character semantics apply. Otherwise, byte semantics are in effect. The bytes pragma should be used to force byte semantics on Unicode data.

If strings operating under byte semantics and strings with Unicode character data are concatenated, the new string will be upgraded to ISO 8859-1 (Latin-1), even if the old Unicode string used EBCDIC. This translation is done without regard to the system's native 8-bit encoding, so to change this for systems with non-Latin-1 and non-EBCDIC native encodings use the encoding pragma. See encoding [CPAN].

Under character semantics, many operations that formerly operated on bytes now operate on characters. A character in Perl is logically just a number ranging from 0 to 2**31 or so. Larger characters may encode into longer sequences of bytes internally, but this internal detail is mostly hidden for Perl code. See perluniintro [CPAN] for more.

Effects of Character Semantics 文字セマンティクスの効果

Character semantics have the following effects:

Scripts スクリプト

The script names which can be used by \p{...} and \P{...}, such as in \p{Latin} or \p{Cyrillic}, are as follows: 

    Arabic
    Armenian
    Bengali
    Bopomofo
    Buhid
    CanadianAboriginal
    Cherokee
    Cyrillic
    Deseret
    Devanagari
    Ethiopic
    Georgian
    Gothic
    Greek
    Gujarati
    Gurmukhi
    Han
    Hangul
    Hanunoo
    Hebrew
    Hiragana
    Inherited
    Kannada
    Katakana
    Khmer
    Lao
    Latin
    Malayalam
    Mongolian
    Myanmar
    Ogham
    OldItalic
    Oriya
    Runic
    Sinhala
    Syriac
    Tagalog
    Tagbanwa
    Tamil
    Telugu
    Thaana
    Thai
    Tibetan
    Yi

Extended property classes can supplement the basic properties, defined by the PropList Unicode database: 

    ASCIIHexDigit
    BidiControl
    Dash
    Deprecated
    Diacritic
    Extender
    GraphemeLink
    HexDigit
    Hyphen
    Ideographic
    IDSBinaryOperator
    IDSTrinaryOperator
    JoinControl
    LogicalOrderException
    NoncharacterCodePoint
    OtherAlphabetic
    OtherDefaultIgnorableCodePoint
    OtherGraphemeExtend
    OtherLowercase
    OtherMath
    OtherUppercase
    QuotationMark
    Radical
    SoftDotted
    TerminalPunctuation
    UnifiedIdeograph
    WhiteSpace

and there are further derived properties: 

    Alphabetic      Lu + Ll + Lt + Lm + Lo + OtherAlphabetic
    Lowercase       Ll + OtherLowercase
    Uppercase       Lu + OtherUppercase
    Math            Sm + OtherMath

    ID_Start        Lu + Ll + Lt + Lm + Lo + Nl
    ID_Continue     ID_Start + Mn + Mc + Nd + Pc

    Any             Any character
    Assigned        Any non-Cn character (i.e. synonym for \P{Cn})
    Unassigned      Synonym for \p{Cn}
    Common          Any character (or unassigned code point)
                    not explicitly assigned to a script

For backward compatibility (with Perl 5.6), all properties mentioned so far may have Is prepended to their name, so \P{IsLu}, for example, is equal to \P{Lu}.

Blocks ブロック

In addition to scripts, Unicode also defines blocks of characters. The difference between scripts and blocks is that the concept of scripts is closer to natural languages, while the concept of blocks is more of an artificial grouping based on groups of 256 Unicode characters. For example, the Latin script contains letters from many blocks but does not contain all the characters from those blocks. It does not, for example, contain digits, because digits are shared across many scripts. Digits and similar groups, like punctuation, are in a category called Common.

For more about scripts, see the UTR #24: 

   http://www.unicode.org/unicode/reports/tr24/

For more about blocks, see: 

   http://www.unicode.org/Public/UNIDATA/Blocks.txt

Block names are given with the In prefix. For example, the Katakana block is referenced via \p{InKatakana}. The In prefix may be omitted if there is no naming conflict with a script or any other property, but it is recommended that In always be used for block tests to avoid confusion.

These block names are supported: 

    InAlphabeticPresentationForms
    InArabic
    InArabicPresentationFormsA
    InArabicPresentationFormsB
    InArmenian
    InArrows
    InBasicLatin
    InBengali
    InBlockElements
    InBopomofo
    InBopomofoExtended
    InBoxDrawing
    InBraillePatterns
    InBuhid
    InByzantineMusicalSymbols
    InCJKCompatibility
    InCJKCompatibilityForms
    InCJKCompatibilityIdeographs
    InCJKCompatibilityIdeographsSupplement
    InCJKRadicalsSupplement
    InCJKSymbolsAndPunctuation
    InCJKUnifiedIdeographs
    InCJKUnifiedIdeographsExtensionA
    InCJKUnifiedIdeographsExtensionB
    InCherokee
    InCombiningDiacriticalMarks
    InCombiningDiacriticalMarksforSymbols
    InCombiningHalfMarks
    InControlPictures
    InCurrencySymbols
    InCyrillic
    InCyrillicSupplementary
    InDeseret
    InDevanagari
    InDingbats
    InEnclosedAlphanumerics
    InEnclosedCJKLettersAndMonths
    InEthiopic
    InGeneralPunctuation
    InGeometricShapes
    InGeorgian
    InGothic
    InGreekExtended
    InGreekAndCoptic
    InGujarati
    InGurmukhi
    InHalfwidthAndFullwidthForms
    InHangulCompatibilityJamo
    InHangulJamo
    InHangulSyllables
    InHanunoo
    InHebrew
    InHighPrivateUseSurrogates
    InHighSurrogates
    InHiragana
    InIPAExtensions
    InIdeographicDescriptionCharacters
    InKanbun
    InKangxiRadicals
    InKannada
    InKatakana
    InKatakanaPhoneticExtensions
    InKhmer
    InLao
    InLatin1Supplement
    InLatinExtendedA
    InLatinExtendedAdditional
    InLatinExtendedB
    InLetterlikeSymbols
    InLowSurrogates
    InMalayalam
    InMathematicalAlphanumericSymbols
    InMathematicalOperators
    InMiscellaneousMathematicalSymbolsA
    InMiscellaneousMathematicalSymbolsB
    InMiscellaneousSymbols
    InMiscellaneousTechnical
    InMongolian
    InMusicalSymbols
    InMyanmar
    InNumberForms
    InOgham
    InOldItalic
    InOpticalCharacterRecognition
    InOriya
    InPrivateUseArea
    InRunic
    InSinhala
    InSmallFormVariants
    InSpacingModifierLetters
    InSpecials
    InSuperscriptsAndSubscripts
    InSupplementalArrowsA
    InSupplementalArrowsB
    InSupplementalMathematicalOperators
    InSupplementaryPrivateUseAreaA
    InSupplementaryPrivateUseAreaB
    InSyriac
    InTagalog
    InTagbanwa
    InTags
    InTamil
    InTelugu
    InThaana
    InThai
    InTibetan
    InUnifiedCanadianAboriginalSyllabics
    InVariationSelectors
    InYiRadicals
    InYiSyllables

User-Defined Character Properties ユーザ定義の文字属性

You can define your own character properties by defining subroutines whose names begin with "In" or "Is". The subroutines must be visible in the package that uses the properties. The user-defined properties can be used in the regular expression \p and \P constructs.

The subroutines must return a specially-formatted string, with one or more newline-separated lines. Each line must be one of the following:

For example, to define a property that covers both the Japanese syllabaries (hiragana and katakana), you can define 

    sub InKana {
	return <<END;
    3040\t309F
    30A0\t30FF
    END
    }

Imagine that the here-doc end marker is at the beginning of the line. Now you can use \p{InKana} and \P{InKana}.

You could also have used the existing block property names: 

    sub InKana {
	return <<'END';
    +utf8::InHiragana
    +utf8::InKatakana
    END
    }

Suppose you wanted to match only the allocated characters, not the raw block ranges: in other words, you want to remove the non-characters: 

    sub InKana {
	return <<'END';
    +utf8::InHiragana
    +utf8::InKatakana
    -utf8::IsCn
    END
    }

The negation is useful for defining (surprise!) negated classes. 

    sub InNotKana {
	return <<'END';
    !utf8::InHiragana
    -utf8::InKatakana
    +utf8::IsCn
    END
    }

Character Encodings for Input and Output 入出力の文字エンコーディング

See Encode [CPAN].

Unicode Regular Expression Support Level ユニコード正規表現のサポート状況

The following list of Unicode support for regular expressions describes all the features currently supported. The references to "Level N" and the section numbers refer to the Unicode Technical Report 18, "Unicode Regular Expression Guidelines".

Unicode Encodings ユニコードエンコーディング

Unicode characters are assigned to code points, which are abstract numbers. To use these numbers, various encodings are needed.

Security Implications of Unicode ユニコードのセキュリティ暗示

Unicode in Perl on EBCDIC EBCDIC 上での Perl でのユニコード

The way Unicode is handled on EBCDIC platforms is still experimental. On such platforms, references to UTF-8 encoding in this document and elsewhere should be read as meaning the UTF-EBCDIC specified in Unicode Technical Report 16, unless ASCII vs. EBCDIC issues are specifically discussed. There is no utfebcdic pragma or ":utfebcdic" layer; rather, "utf8" and ":utf8" are reused to mean the platform's "natural" 8-bit encoding of Unicode. See perlebcdic [CPAN] for more discussion of the issues.

Locales ロケール

Usually locale settings and Unicode do not affect each other, but there are a couple of exceptions:

Using Unicode in XS XSでのユニコードの使用

If you want to handle Perl Unicode in XS extensions, you may find the following C APIs useful. See perlapi [CPAN] for details.

もし XS 拡張で Perl Unicode を扱いたいのなら, 以下の役に立つ C API を見つけるでしょう. 詳細は, perlapi [CPAN] を参照してください.

For more information, see perlapi [CPAN], and utf8.c and utf8.h in the Perl source code distribution.

これ以上の情報は, perlapi [CPAN] 及び, Perl のソースコードに含まれている utf8.c と utf8.h を参照してください.

BUGS バグ

Interaction with Locales ロケールとの相互作用

Use of locales with Unicode data may lead to odd results. Currently, Perl attempts to attach 8-bit locale info to characters in the range 0..255, but this technique is demonstrably incorrect for locales that use characters above that range when mapped into Unicode. Perl's Unicode support will also tend to run slower. Use of locales with Unicode is discouraged.

Interaction with Extensions 拡張との相互作用

When Perl exchanges data with an extension, the extension should be able to understand the UTF-8 flag and act accordingly. If the extension doesn't know about the flag, it's likely that the extension will return incorrectly-flagged data.

So if you're working with Unicode data, consult the documentation of every module you're using if there are any issues with Unicode data exchange. If the documentation does not talk about Unicode at all, suspect the worst and probably look at the source to learn how the module is implemented. Modules written completely in Perl shouldn't cause problems. Modules that directly or indirectly access code written in other programming languages are at risk.

For affected functions, the simple strategy to avoid data corruption is to always make the encoding of the exchanged data explicit. Choose an encoding that you know the extension can handle. Convert arguments passed to the extensions to that encoding and convert results back from that encoding. Write wrapper functions that do the conversions for you, so you can later change the functions when the extension catches up.

To provide an example, let's say the popular Foo::Bar::escape_html function doesn't deal with Unicode data yet. The wrapper function would convert the argument to raw UTF-8 and convert the result back to Perl's internal representation like so: 

    sub my_escape_html ($) {
      my($what) = shift;
      return unless defined $what;
      Encode::decode_utf8(Foo::Bar::escape_html(Encode::encode_utf8($what)));
    }

Sometimes, when the extension does not convert data but just stores and retrieves them, you will be in a position to use the otherwise dangerous Encode::_utf8_on() function. Let's say the popular Foo::Bar extension, written in C, provides a param method that lets you store and retrieve data according to these prototypes: 

    $self->param($name, $value);            # set a scalar
    $value = $self->param($name);           # retrieve a scalar

If it does not yet provide support for any encoding, one could write a derived class with such a param method: 

    sub param {
      my($self,$name,$value) = @_;
      utf8::upgrade($name);     # make sure it is UTF-8 encoded
      if (defined $value)
        utf8::upgrade($value);  # make sure it is UTF-8 encoded
        return $self->SUPER::param($name,$value);
      } else {
        my $ret = $self->SUPER::param($name);
        Encode::_utf8_on($ret); # we know, it is UTF-8 encoded
        return $ret;
      }
    }

Some extensions provide filters on data entry/exit points, such as DB_File::filter_store_key and family. Look out for such filters in the documentation of your extensions, they can make the transition to Unicode data much easier.

Speed 速度

Some functions are slower when working on UTF-8 encoded strings than on byte encoded strings. All functions that need to hop over characters such as length(), substr() or index() can work much faster when the underlying data are byte-encoded. Witness the following benchmark: 

  % perl -e '
  use Benchmark;
  use strict;
  our $l = 10000;
  our $u = our $b = "x" x $l;
  substr($u,0,1) = "\x{100}";
  timethese(-2,{
  LENGTH_B => q{ length($b) },
  LENGTH_U => q{ length($u) },
  SUBSTR_B => q{ substr($b, $l/4, $l/2) },
  SUBSTR_U => q{ substr($u, $l/4, $l/2) },
  });
  '
  Benchmark: running LENGTH_B, LENGTH_U, SUBSTR_B, SUBSTR_U for at least 2 CPU seconds...
    LENGTH_B:  2 wallclock secs ( 2.36 usr +  0.00 sys =  2.36 CPU) @ 5649983.05/s (n=13333960)
    LENGTH_U:  2 wallclock secs ( 2.11 usr +  0.00 sys =  2.11 CPU) @ 12155.45/s (n=25648)
    SUBSTR_B:  3 wallclock secs ( 2.16 usr +  0.00 sys =  2.16 CPU) @ 374480.09/s (n=808877)
    SUBSTR_U:  2 wallclock secs ( 2.11 usr +  0.00 sys =  2.11 CPU) @ 6791.00/s (n=14329)

The numbers show an incredible slowness on long UTF-8 strings. You should carefully avoid using these functions in tight loops. If you want to iterate over characters, the superior coding technique would split the characters into an array instead of using substr, as the following benchmark shows: 

  % perl -e '
  use Benchmark;
  use strict;
  our $l = 10000;
  our $u = our $b = "x" x $l;
  substr($u,0,1) = "\x{100}";
  timethese(-5,{
  SPLIT_B => q{ for my $c (split //, $b){}  },
  SPLIT_U => q{ for my $c (split //, $u){}  },
  SUBSTR_B => q{ for my $i (0..length($b)-1){my $c = substr($b,$i,1);} },
  SUBSTR_U => q{ for my $i (0..length($u)-1){my $c = substr($u,$i,1);} },
  });
  '
  Benchmark: running SPLIT_B, SPLIT_U, SUBSTR_B, SUBSTR_U for at least 5 CPU seconds...
     SPLIT_B:  6 wallclock secs ( 5.29 usr +  0.00 sys =  5.29 CPU) @ 56.14/s (n=297)
     SPLIT_U:  5 wallclock secs ( 5.17 usr +  0.01 sys =  5.18 CPU) @ 55.21/s (n=286)
    SUBSTR_B:  5 wallclock secs ( 5.34 usr +  0.00 sys =  5.34 CPU) @ 123.22/s (n=658)
    SUBSTR_U:  7 wallclock secs ( 6.20 usr +  0.00 sys =  6.20 CPU) @  0.81/s (n=5)

Even though the algorithm based on substr() is faster than split() for byte-encoded data, it pales in comparison to the speed of split() when used with UTF-8 data.

SEE ALSO 関連項目

perluniintro [CPAN], encoding [CPAN], Encode [CPAN], open [CPAN], utf8 [CPAN], bytes [CPAN], perlretut [CPAN], perlvar 内 "${^WIDE_SYSTEM_CALLS}" [CPAN]

perlunicode - Unicode support in Perl

索引

perlunicode - Unicode support in Perl