Commit | Line | Data |
---|---|---|
ba62762e JH |
1 | =head1 NAME |
2 | ||
07fcf8ff | 3 | perluniintro - Perl Unicode introduction |
ba62762e JH |
4 | |
5 | =head1 DESCRIPTION | |
6 | ||
7 | This document gives a general idea of Unicode and how to use Unicode | |
c8695642 KW |
8 | in Perl. See L</Further Resources> for references to more in-depth |
9 | treatments of Unicode. | |
ba62762e JH |
10 | |
11 | =head2 Unicode | |
12 | ||
376d9008 | 13 | Unicode is a character set standard which plans to codify all of the |
ba62762e JH |
14 | writing systems of the world, plus many other symbols. |
15 | ||
c8695642 KW |
16 | Unicode and ISO/IEC 10646 are coordinated standards that unify |
17 | almost all other modern character set standards, | |
18 | covering more than 80 writing systems and hundreds of languages, | |
376d9008 | 19 | including all commercially-important modern languages. All characters |
ba62762e JH |
20 | in the largest Chinese, Japanese, and Korean dictionaries are also |
21 | encoded. The standards will eventually cover almost all characters in | |
22 | more than 250 writing systems and thousands of languages. | |
c8695642 | 23 | Unicode 1.0 was released in October 1991, and 6.0 in October 2010. |
ba62762e JH |
24 | |
25 | A Unicode I<character> is an abstract entity. It is not bound to any | |
376d9008 JB |
26 | particular integer width, especially not to the C language C<char>. |
27 | Unicode is language-neutral and display-neutral: it does not encode the | |
e1b711da | 28 | language of the text, and it does not generally define fonts or other graphical |
ba62762e JH |
29 | layout details. Unicode operates on characters and on text built from |
30 | those characters. | |
31 | ||
32 | Unicode defines characters like C<LATIN CAPITAL LETTER A> or C<GREEK | |
376d9008 JB |
33 | SMALL LETTER ALPHA> and unique numbers for the characters, in this |
34 | case 0x0041 and 0x03B1, respectively. These unique numbers are called | |
c8695642 KW |
35 | I<code points>. A code point is essentially the position of the |
36 | character within the set of all possible Unicode characters, and thus in | |
37 | Perl, the term I<ordinal> is often used interchangeably with it. | |
ba62762e JH |
38 | |
39 | The Unicode standard prefers using hexadecimal notation for the code | |
4c496f0c JH |
40 | points. If numbers like C<0x0041> are unfamiliar to you, take a peek |
41 | at a later section, L</"Hexadecimal Notation">. The Unicode standard | |
42 | uses the notation C<U+0041 LATIN CAPITAL LETTER A>, to give the | |
43 | hexadecimal code point and the normative name of the character. | |
ba62762e JH |
44 | |
45 | Unicode also defines various I<properties> for the characters, like | |
376d9008 | 46 | "uppercase" or "lowercase", "decimal digit", or "punctuation"; |
ba62762e JH |
47 | these properties are independent of the names of the characters. |
48 | Furthermore, various operations on the characters like uppercasing, | |
376d9008 | 49 | lowercasing, and collating (sorting) are defined. |
ba62762e | 50 | |
0111a78f KW |
51 | A Unicode I<logical> "character" can actually consist of more than one internal |
52 | I<actual> "character" or code point. For Western languages, this is adequately | |
c670e63a | 53 | modelled by a I<base character> (like C<LATIN CAPITAL LETTER A>) followed |
0111a78f | 54 | by one or more I<modifiers> (like C<COMBINING ACUTE ACCENT>). This sequence of |
376d9008 | 55 | base character and modifiers is called a I<combining character |
0111a78f | 56 | sequence>. Some non-western languages require more complicated |
c8695642 KW |
57 | models, so Unicode created the I<grapheme cluster> concept, which was |
58 | later further refined into the I<extended grapheme cluster>. For | |
59 | example, a Korean Hangul syllable is considered a single logical | |
60 | character, but most often consists of three actual | |
c670e63a KW |
61 | Unicode characters: a leading consonant followed by an interior vowel followed |
62 | by a trailing consonant. | |
0111a78f KW |
63 | |
64 | Whether to call these extended grapheme clusters "characters" depends on your | |
65 | point of view. If you are a programmer, you probably would tend towards seeing | |
c8695642 KW |
66 | each element in the sequences as one unit, or "character". However from |
67 | the user's point of view, the whole sequence could be seen as one | |
68 | "character" since that's probably what it looks like in the context of the | |
69 | user's language. In this document, we take the programmer's point of | |
70 | view: one "character" is one Unicode code point. | |
71 | ||
72 | For some combinations of base character and modifiers, there are | |
73 | I<precomposed> characters. There is a single character equivalent, for | |
4d2d7a4c | 74 | example, for the sequence C<LATIN CAPITAL LETTER A> followed by |
c8695642 KW |
75 | C<COMBINING ACUTE ACCENT>. It is called C<LATIN CAPITAL LETTER A WITH |
76 | ACUTE>. These precomposed characters are, however, only available for | |
77 | some combinations, and are mainly meant to support round-trip | |
78 | conversions between Unicode and legacy standards (like ISO 8859). Using | |
79 | sequences, as Unicode does, allows for needing fewer basic building blocks | |
80 | (code points) to express many more potential grapheme clusters. To | |
81 | support conversion between equivalent forms, various I<normalization | |
82 | forms> are also defined. Thus, C<LATIN CAPITAL LETTER A WITH ACUTE> is | |
83 | in I<Normalization Form Composed>, (abbreviated NFC), and the sequence | |
84 | C<LATIN CAPITAL LETTER A> followed by C<COMBINING ACUTE ACCENT> | |
85 | represents the same character in I<Normalization Form Decomposed> (NFD). | |
ba62762e JH |
86 | |
87 | Because of backward compatibility with legacy encodings, the "a unique | |
376d9008 JB |
88 | number for every character" idea breaks down a bit: instead, there is |
89 | "at least one number for every character". The same character could | |
90 | be represented differently in several legacy encodings. The | |
91a927c1 | 91 | converse is not true: some code points do not have an assigned |
376d9008 JB |
92 | character. Firstly, there are unallocated code points within |
93 | otherwise used blocks. Secondly, there are special Unicode control | |
94 | characters that do not represent true characters. | |
ba62762e | 95 | |
e9078126 KW |
96 | When Unicode was first conceived, it was thought that all the world's |
97 | characters could be represented using a 16-bit word; that is a maximum of | |
91a927c1 KW |
98 | C<0x10000> (or 65,536) characters would be needed, from C<0x0000> to |
99 | C<0xFFFF>. This soon proved to be wrong, and since Unicode 2.0 (July | |
4c496f0c | 100 | 1996), Unicode has been defined all the way up to 21 bits (C<0x10FFFF>), |
e9078126 KW |
101 | and Unicode 3.1 (March 2001) defined the first characters above C<0xFFFF>. |
102 | The first C<0x10000> characters are called the I<Plane 0>, or the | |
103 | I<Basic Multilingual Plane> (BMP). With Unicode 3.1, 17 (yes, | |
104 | seventeen) planes in all were defined--but they are nowhere near full of | |
105 | defined characters, yet. | |
106 | ||
107 | When a new language is being encoded, Unicode generally will choose a | |
108 | C<block> of consecutive unallocated code points for its characters. So | |
109 | far, the number of code points in these blocks has always been evenly | |
110 | divisible by 16. Extras in a block, not currently needed, are left | |
111 | unallocated, for future growth. But there have been occasions when | |
30189633 | 112 | a later release needed more code points than the available extras, and a |
82aed44a KW |
113 | new block had to allocated somewhere else, not contiguous to the initial |
114 | one, to handle the overflow. Thus, it became apparent early on that | |
fc273927 | 115 | "block" wasn't an adequate organizing principle, and so the C<Script> |
82aed44a KW |
116 | property was created. (Later an improved script property was added as |
117 | well, the C<Script_Extensions> property.) Those code points that are in | |
118 | overflow blocks can still | |
e9078126 KW |
119 | have the same script as the original ones. The script concept fits more |
120 | closely with natural language: there is C<Latin> script, C<Greek> | |
121 | script, and so on; and there are several artificial scripts, like | |
122 | C<Common> for characters that are used in multiple scripts, such as | |
123 | mathematical symbols. Scripts usually span varied parts of several | |
124 | blocks. For more information about scripts, see L<perlunicode/Scripts>. | |
1bfb14c4 | 125 | The division into blocks exists, but it is almost completely |
e9078126 KW |
126 | accidental--an artifact of how the characters have been and still are |
127 | allocated. (Note that this paragraph has oversimplified things for the | |
128 | sake of this being an introduction. Unicode doesn't really encode | |
129 | languages, but the writing systems for them--their scripts; and one | |
130 | script can be used by many languages. Unicode also encodes things that | |
131 | aren't really about languages, such as symbols like C<BAGGAGE CLAIM>.) | |
ba62762e JH |
132 | |
133 | The Unicode code points are just abstract numbers. To input and | |
4c496f0c JH |
134 | output these abstract numbers, the numbers must be I<encoded> or |
135 | I<serialised> somehow. Unicode defines several I<character encoding | |
91a927c1 KW |
136 | forms>, of which I<UTF-8> is the most popular. UTF-8 is a |
137 | variable length encoding that encodes Unicode characters as 1 to 4 | |
e1b711da | 138 | bytes. Other encodings |
4c496f0c | 139 | include UTF-16 and UTF-32 and their big- and little-endian variants |
f321be7e | 140 | (UTF-8 is byte-order independent). The ISO/IEC 10646 defines the UCS-2 |
4c496f0c | 141 | and UCS-4 encoding forms. |
ba62762e | 142 | |
376d9008 JB |
143 | For more information about encodings--for instance, to learn what |
144 | I<surrogates> and I<byte order marks> (BOMs) are--see L<perlunicode>. | |
ba62762e JH |
145 | |
146 | =head2 Perl's Unicode Support | |
147 | ||
c2fb32ed BF |
148 | Starting from Perl v5.6.0, Perl has had the capacity to handle Unicode |
149 | natively. Perl v5.8.0, however, is the first recommended release for | |
376d9008 JB |
150 | serious Unicode work. The maintenance release 5.6.1 fixed many of the |
151 | problems of the initial Unicode implementation, but for example | |
1bfb14c4 | 152 | regular expressions still do not work with Unicode in 5.6.1. |
c2fb32ed | 153 | Perl v5.14.0 is the first release where Unicode support is |
f1460a66 | 154 | (almost) seamlessly integratable without some gotchas. (There are a few |
d6c970c7 AC |
155 | exceptions. Firstly, some differences in L<quotemeta|perlfunc/quotemeta> |
156 | were fixed starting in Perl 5.16.0. Secondly, some differences in | |
157 | L<the range operator|perlop/Range Operators> were fixed starting in | |
20ae58f7 AC |
158 | Perl 5.26.0. Thirdly, some differences in L<split|perlfunc/split> were fixed |
159 | started in Perl 5.28.0.) | |
d6c970c7 AC |
160 | |
161 | To enable this | |
c8695642 KW |
162 | seamless support, you should C<use feature 'unicode_strings'> (which is |
163 | automatically selected if you C<use 5.012> or higher). See L<feature>. | |
164 | (5.14 also fixes a number of bugs and departures from the Unicode | |
165 | standard.) | |
166 | ||
c2fb32ed | 167 | Before Perl v5.8.0, the use of C<use utf8> was used to declare |
ba62762e | 168 | that operations in the current block or file would be Unicode-aware. |
376d9008 | 169 | This model was found to be wrong, or at least clumsy: the "Unicodeness" |
1bfb14c4 | 170 | is now carried with the data, instead of being attached to the |
c8695642 | 171 | operations. |
c2fb32ed | 172 | Starting with Perl v5.8.0, only one case remains where an explicit C<use |
c8695642 KW |
173 | utf8> is needed: if your Perl script itself is encoded in UTF-8, you can |
174 | use UTF-8 in your identifier names, and in string and regular expression | |
376d9008 | 175 | literals, by saying C<use utf8>. This is not the default because |
8f8cf39c | 176 | scripts with legacy 8-bit data in them would break. See L<utf8>. |
ba62762e JH |
177 | |
178 | =head2 Perl's Unicode Model | |
179 | ||
376d9008 | 180 | Perl supports both pre-5.6 strings of eight-bit native bytes, and |
c8695642 KW |
181 | strings of Unicode characters. The general principle is that Perl tries |
182 | to keep its data as eight-bit bytes for as long as possible, but as soon | |
183 | as Unicodeness cannot be avoided, the data is transparently upgraded | |
c2fb32ed | 184 | to Unicode. Prior to Perl v5.14.0, the upgrade was not completely |
c8695642 KW |
185 | transparent (see L<perlunicode/The "Unicode Bug">), and for backwards |
186 | compatibility, full transparency is not gained unless C<use feature | |
187 | 'unicode_strings'> (see L<feature>) or C<use 5.012> (or higher) is | |
188 | selected. | |
ba62762e | 189 | |
4192de81 | 190 | Internally, Perl currently uses either whatever the native eight-bit |
376d9008 JB |
191 | character set of the platform (for example Latin-1) is, defaulting to |
192 | UTF-8, to encode Unicode strings. Specifically, if all code points in | |
193 | the string are C<0xFF> or less, Perl uses the native eight-bit | |
194 | character set. Otherwise, it uses UTF-8. | |
4192de81 | 195 | |
7ca610e8 | 196 | A user of Perl does not normally need to know nor care how Perl |
20ba30f4 | 197 | happens to encode its internal strings, but it becomes relevant when |
ac036724 | 198 | outputting Unicode strings to a stream without a PerlIO layer (one with |
199 | the "default" encoding). In such a case, the raw bytes used internally | |
7ca610e8 JH |
200 | (the native character set or UTF-8, as appropriate for each string) |
201 | will be used, and a "Wide character" warning will be issued if those | |
202 | strings contain a character beyond 0x00FF. | |
4192de81 JH |
203 | |
204 | For example, | |
205 | ||
ae5648b3 | 206 | perl -e 'print "\x{DF}\n", "\x{0100}\x{DF}\n"' |
4192de81 JH |
207 | |
208 | produces a fairly useless mixture of native bytes and UTF-8, as well | |
1bfb14c4 | 209 | as a warning: |
4192de81 | 210 | |
1bfb14c4 JH |
211 | Wide character in print at ... |
212 | ||
740d4bb2 | 213 | To output UTF-8, use the C<:encoding> or C<:utf8> output layer. Prepending |
4192de81 JH |
214 | |
215 | binmode(STDOUT, ":utf8"); | |
216 | ||
376d9008 | 217 | to this sample program ensures that the output is completely UTF-8, |
1bfb14c4 | 218 | and removes the program's warning. |
ba62762e | 219 | |
8aa8f774 JH |
220 | You can enable automatic UTF-8-ification of your standard file |
221 | handles, default C<open()> layer, and C<@ARGV> by using either | |
222 | the C<-C> command line switch or the C<PERL_UNICODE> environment | |
028611fa DB |
223 | variable, see L<perlrun|perlrun/-C [numberE<sol>list]> for the |
224 | documentation of the C<-C> switch. | |
8aa8f774 | 225 | |
c8695642 KW |
226 | Note that this means that Perl expects other software to work the same |
227 | way: | |
8aa8f774 | 228 | if Perl has been led to believe that STDIN should be UTF-8, but then |
c8695642 KW |
229 | STDIN coming in from another command is not UTF-8, Perl will likely |
230 | complain about the malformed UTF-8. | |
b310b053 | 231 | |
ec71e770 JH |
232 | All features that combine Unicode and I/O also require using the new |
233 | PerlIO feature. Almost all Perl 5.8 platforms do use PerlIO, though: | |
234 | you can see whether yours is by running "perl -V" and looking for | |
235 | C<useperlio=define>. | |
236 | ||
64c66fb6 JH |
237 | =head2 Unicode and EBCDIC |
238 | ||
0145df7d KW |
239 | Perl 5.8.0 added support for Unicode on EBCDIC platforms. This support |
240 | was allowed to lapse in later releases, but was revived in 5.22. | |
241 | Unicode support is somewhat more complex to implement since additional | |
242 | conversions are needed. See L<perlebcdic> for more information. | |
64c66fb6 | 243 | |
64c66fb6 | 244 | On EBCDIC platforms, the internal Unicode encoding form is UTF-EBCDIC |
376d9008 JB |
245 | instead of UTF-8. The difference is that as UTF-8 is "ASCII-safe" in |
246 | that ASCII characters encode to UTF-8 as-is, while UTF-EBCDIC is | |
0145df7d KW |
247 | "EBCDIC-safe", in that all the basic characters (which includes all |
248 | those that have ASCII equivalents (like C<"A">, C<"0">, C<"%">, I<etc.>) | |
249 | are the same in both EBCDIC and UTF-EBCDIC. Often, documentation | |
250 | will use the term "UTF-8" to mean UTF-EBCDIC as well. This is the case | |
251 | in this document. | |
ba62762e JH |
252 | |
253 | =head2 Creating Unicode | |
254 | ||
0145df7d KW |
255 | This section applies fully to Perls starting with v5.22. Various |
256 | caveats for earlier releases are in the L</Earlier releases caveats> | |
257 | subsection below. | |
ba62762e | 258 | |
0145df7d KW |
259 | To create Unicode characters in literals, |
260 | use the C<\N{...}> notation in double-quoted strings: | |
ba62762e | 261 | |
0145df7d KW |
262 | my $smiley_from_name = "\N{WHITE SMILING FACE}"; |
263 | my $smiley_from_code_point = "\N{U+263a}"; | |
ba62762e | 264 | |
0145df7d | 265 | Similarly, they can be used in regular expression literals |
ba62762e | 266 | |
0145df7d KW |
267 | $smiley =~ /\N{WHITE SMILING FACE}/; |
268 | $smiley =~ /\N{U+263a}/; | |
ba62762e | 269 | |
673c254b KW |
270 | or, starting in v5.32: |
271 | ||
272 | $smiley =~ /\p{Name=WHITE SMILING FACE}/; | |
273 | $smiley =~ /\p{Name=whitesmilingface}/; | |
274 | ||
0145df7d | 275 | At run-time you can use: |
ba62762e | 276 | |
0145df7d KW |
277 | use charnames (); |
278 | my $hebrew_alef_from_name | |
279 | = charnames::string_vianame("HEBREW LETTER ALEF"); | |
280 | my $hebrew_alef_from_code_point = charnames::string_vianame("U+05D0"); | |
ba62762e | 281 | |
376d9008 JB |
282 | Naturally, C<ord()> will do the reverse: it turns a character into |
283 | a code point. | |
ba62762e | 284 | |
0145df7d KW |
285 | There are other runtime options as well. You can use C<pack()>: |
286 | ||
287 | my $hebrew_alef_from_code_point = pack("U", 0x05d0); | |
288 | ||
289 | Or you can use C<chr()>, though it is less convenient in the general | |
290 | case: | |
291 | ||
292 | $hebrew_alef_from_code_point = chr(utf8::unicode_to_native(0x05d0)); | |
293 | utf8::upgrade($hebrew_alef_from_code_point); | |
294 | ||
295 | The C<utf8::unicode_to_native()> and C<utf8::upgrade()> aren't needed if | |
296 | the argument is above 0xFF, so the above could have been written as | |
297 | ||
298 | $hebrew_alef_from_code_point = chr(0x05d0); | |
ba62762e | 299 | |
0145df7d | 300 | since 0x5d0 is above 255. |
ba62762e | 301 | |
0145df7d KW |
302 | C<\x{}> and C<\o{}> can also be used to specify code points at compile |
303 | time in double-quotish strings, but, for backward compatibility with | |
304 | older Perls, the same rules apply as with C<chr()> for code points less | |
305 | than 256. | |
ba62762e | 306 | |
0145df7d KW |
307 | C<utf8::unicode_to_native()> is used so that the Perl code is portable |
308 | to EBCDIC platforms. You can omit it if you're I<really> sure no one | |
309 | will ever want to use your code on a non-ASCII platform. Starting in | |
310 | Perl v5.22, calls to it on ASCII platforms are optimized out, so there's | |
311 | no performance penalty at all in adding it. Or you can simply use the | |
312 | other constructs that don't require it. | |
ba62762e | 313 | |
0145df7d KW |
314 | See L</"Further Resources"> for how to find all these names and numeric |
315 | codes. | |
ba62762e | 316 | |
0145df7d | 317 | =head3 Earlier releases caveats |
8a5e5dd5 | 318 | |
0145df7d KW |
319 | On EBCDIC platforms, prior to v5.22, using C<\N{U+...}> doesn't work |
320 | properly. | |
1eda90df | 321 | |
0145df7d KW |
322 | Prior to v5.16, using C<\N{...}> with a character name (as opposed to a |
323 | C<U+...> code point) required a S<C<use charnames :full>>. | |
771cd3b2 | 324 | |
0145df7d KW |
325 | Prior to v5.14, there were some bugs in C<\N{...}> with a character name |
326 | (as opposed to a C<U+...> code point). | |
327 | ||
328 | C<charnames::string_vianame()> was introduced in v5.14. Prior to that, | |
329 | C<charnames::vianame()> should work, but only if the argument is of the | |
330 | form C<"U+...">. Your best bet there for runtime Unicode by character | |
331 | name is probably: | |
332 | ||
333 | use charnames (); | |
334 | my $hebrew_alef_from_name | |
335 | = pack("U", charnames::vianame("HEBREW LETTER ALEF")); | |
1eda90df | 336 | |
ba62762e JH |
337 | =head2 Handling Unicode |
338 | ||
339 | Handling Unicode is for the most part transparent: just use the | |
340 | strings as usual. Functions like C<index()>, C<length()>, and | |
341 | C<substr()> will work on the Unicode characters; regular expressions | |
342 | will work on the Unicode characters (see L<perlunicode> and L<perlretut>). | |
343 | ||
0111a78f KW |
344 | Note that Perl considers grapheme clusters to be separate characters, so for |
345 | example | |
ba62762e | 346 | |
9ba22424 KW |
347 | print length("\N{LATIN CAPITAL LETTER A}\N{COMBINING ACUTE ACCENT}"), |
348 | "\n"; | |
ba62762e JH |
349 | |
350 | will print 2, not 1. The only exception is that regular expressions | |
c8695642 KW |
351 | have C<\X> for matching an extended grapheme cluster. (Thus C<\X> in a |
352 | regular expression would match the entire sequence of both the example | |
353 | characters.) | |
ba62762e | 354 | |
376d9008 JB |
355 | Life is not quite so transparent, however, when working with legacy |
356 | encodings, I/O, and certain special cases: | |
ba62762e JH |
357 | |
358 | =head2 Legacy Encodings | |
359 | ||
c8695642 KW |
360 | When you combine legacy data and Unicode, the legacy data needs |
361 | to be upgraded to Unicode. Normally the legacy data is assumed to be | |
362 | ISO 8859-1 (or EBCDIC, if applicable). | |
ba62762e | 363 | |
376d9008 | 364 | The C<Encode> module knows about many encodings and has interfaces |
ba62762e JH |
365 | for doing conversions between those encodings: |
366 | ||
2c9359a2 | 367 | use Encode 'decode'; |
2426b0d3 | 368 | $data = decode("iso-8859-3", $data); # convert from legacy |
ba62762e JH |
369 | |
370 | =head2 Unicode I/O | |
371 | ||
8baee566 | 372 | Normally, writing out Unicode data |
ba62762e | 373 | |
8baee566 | 374 | print FH $some_string_with_unicode, "\n"; |
ba62762e | 375 | |
8baee566 | 376 | produces raw bytes that Perl happens to use to internally encode the |
376d9008 JB |
377 | Unicode string. Perl's internal encoding depends on the system as |
378 | well as what characters happen to be in the string at the time. If | |
379 | any of the characters are at code points C<0x100> or above, you will get | |
380 | a warning. To ensure that the output is explicitly rendered in the | |
381 | encoding you desire--and to avoid the warning--open the stream with | |
382 | the desired encoding. Some examples: | |
ba62762e | 383 | |
ec90690f TS |
384 | open FH, ">:utf8", "file"; |
385 | ||
386 | open FH, ">:encoding(ucs2)", "file"; | |
387 | open FH, ">:encoding(UTF-8)", "file"; | |
388 | open FH, ">:encoding(shift_jis)", "file"; | |
1d7919c5 | 389 | |
376d9008 | 390 | and on already open streams, use C<binmode()>: |
1d7919c5 JH |
391 | |
392 | binmode(STDOUT, ":utf8"); | |
393 | ||
ec90690f TS |
394 | binmode(STDOUT, ":encoding(ucs2)"); |
395 | binmode(STDOUT, ":encoding(UTF-8)"); | |
396 | binmode(STDOUT, ":encoding(shift_jis)"); | |
397 | ||
b5d8778e | 398 | The matching of encoding names is loose: case does not matter, and |
fae2c0fb | 399 | many encodings have several aliases. Note that the C<:utf8> layer |
1bfb14c4 | 400 | must always be specified exactly like that; it is I<not> subject to |
c8695642 | 401 | the loose matching of encoding names. Also note that currently C<:utf8> is unsafe for |
740d4bb2 | 402 | input, because it accepts the data without validating that it is indeed valid |
f34228d6 | 403 | UTF-8; you should instead use C<:encoding(UTF-8)> (with or without a |
367b3305 | 404 | hyphen). |
b5d8778e | 405 | |
376d9008 JB |
406 | See L<PerlIO> for the C<:utf8> layer, L<PerlIO::encoding> and |
407 | L<Encode::PerlIO> for the C<:encoding()> layer, and | |
408 | L<Encode::Supported> for many encodings supported by the C<Encode> | |
409 | module. | |
ba62762e | 410 | |
a5f0baef | 411 | Reading in a file that you know happens to be encoded in one of the |
1bfb14c4 JH |
412 | Unicode or legacy encodings does not magically turn the data into |
413 | Unicode in Perl's eyes. To do that, specify the appropriate | |
fae2c0fb | 414 | layer when opening files |
ba62762e | 415 | |
6d8e7450 | 416 | open(my $fh,'<:encoding(UTF-8)', 'anything'); |
8baee566 JF |
417 | my $line_of_unicode = <$fh>; |
418 | ||
ec90690f | 419 | open(my $fh,'<:encoding(Big5)', 'anything'); |
8baee566 | 420 | my $line_of_unicode = <$fh>; |
ba62762e | 421 | |
fae2c0fb | 422 | The I/O layers can also be specified more flexibly with |
376d9008 | 423 | the C<open> pragma. See L<open>, or look at the following example. |
ba62762e | 424 | |
6d8e7450 P |
425 | use open ':encoding(UTF-8)'; # input/output default encoding will be |
426 | # UTF-8 | |
1d7919c5 JH |
427 | open X, ">file"; |
428 | print X chr(0x100), "\n"; | |
ba62762e | 429 | close X; |
1d7919c5 | 430 | open Y, "<file"; |
ba62762e JH |
431 | printf "%#x\n", ord(<Y>); # this should print 0x100 |
432 | close Y; | |
433 | ||
fae2c0fb | 434 | With the C<open> pragma you can use the C<:locale> layer |
ba62762e | 435 | |
12f98225 | 436 | BEGIN { $ENV{LC_ALL} = $ENV{LANG} = 'ru_RU.KOI8-R' } |
9e5bbba0 KW |
437 | # the :locale will probe the locale environment variables like |
438 | # LC_ALL | |
ba62762e JH |
439 | use open OUT => ':locale'; # russki parusski |
440 | open(O, ">koi8"); | |
441 | print O chr(0x430); # Unicode CYRILLIC SMALL LETTER A = KOI8-R 0xc1 | |
442 | close O; | |
443 | open(I, "<koi8"); | |
444 | printf "%#x\n", ord(<I>), "\n"; # this should print 0xc1 | |
445 | close I; | |
446 | ||
8baee566 JF |
447 | These methods install a transparent filter on the I/O stream that |
448 | converts data from the specified encoding when it is read in from the | |
a5f0baef | 449 | stream. The result is always Unicode. |
ba62762e JH |
450 | |
451 | The L<open> pragma affects all the C<open()> calls after the pragma by | |
fae2c0fb RGS |
452 | setting default layers. If you want to affect only certain |
453 | streams, use explicit layers directly in the C<open()> call. | |
ba62762e JH |
454 | |
455 | You can switch encodings on an already opened stream by using | |
8baee566 | 456 | C<binmode()>; see L<perlfunc/binmode>. |
ba62762e | 457 | |
c2fb32ed | 458 | The C<:locale> does not currently work with |
1ecefa54 | 459 | C<open()> and C<binmode()>, only with the C<open> pragma. The |
8baee566 | 460 | C<:utf8> and C<:encoding(...)> methods do work with all of C<open()>, |
1ecefa54 | 461 | C<binmode()>, and the C<open> pragma. |
ba62762e | 462 | |
fae2c0fb | 463 | Similarly, you may use these I/O layers on output streams to |
a5f0baef JH |
464 | automatically convert Unicode to the specified encoding when it is |
465 | written to the stream. For example, the following snippet copies the | |
466 | contents of the file "text.jis" (encoded as ISO-2022-JP, aka JIS) to | |
467 | the file "text.utf8", encoded as UTF-8: | |
ba62762e | 468 | |
c722ef0a JH |
469 | open(my $nihongo, '<:encoding(iso-2022-jp)', 'text.jis'); |
470 | open(my $unicode, '>:utf8', 'text.utf8'); | |
0cf8a8d9 | 471 | while (<$nihongo>) { print $unicode $_ } |
ba62762e JH |
472 | |
473 | The naming of encodings, both by the C<open()> and by the C<open> | |
2575c402 JW |
474 | pragma allows for flexible names: C<koi8-r> and C<KOI8R> will both be |
475 | understood. | |
ba62762e JH |
476 | |
477 | Common encodings recognized by ISO, MIME, IANA, and various other | |
8baee566 | 478 | standardisation organisations are recognised; for a more detailed |
1bfb14c4 | 479 | list see L<Encode::Supported>. |
ba62762e JH |
480 | |
481 | C<read()> reads characters and returns the number of characters. | |
ee329aef TC |
482 | C<seek()> and C<tell()> operate on byte counts, as does C<sysseek()>. |
483 | ||
484 | C<sysread()> and C<syswrite()> should not be used on file handles with | |
485 | character encoding layers, they behave badly, and that behaviour has | |
486 | been deprecated since perl 5.24. | |
ba62762e | 487 | |
8baee566 | 488 | Notice that because of the default behaviour of not doing any |
fae2c0fb | 489 | conversion upon input if there is no default layer, |
ba62762e | 490 | it is easy to mistakenly write code that keeps on expanding a file |
1bfb14c4 | 491 | by repeatedly encoding the data: |
ba62762e JH |
492 | |
493 | # BAD CODE WARNING | |
494 | open F, "file"; | |
8baee566 | 495 | local $/; ## read in the whole file of 8-bit characters |
ba62762e JH |
496 | $t = <F>; |
497 | close F; | |
6d8e7450 | 498 | open F, ">:encoding(UTF-8)", "file"; |
8baee566 | 499 | print F $t; ## convert to UTF-8 on output |
ba62762e JH |
500 | close F; |
501 | ||
502 | If you run this code twice, the contents of the F<file> will be twice | |
6d8e7450 | 503 | UTF-8 encoded. A C<use open ':encoding(UTF-8)'> would have avoided the |
740d4bb2 | 504 | bug, or explicitly opening also the F<file> for input as UTF-8. |
ba62762e | 505 | |
0c901d84 | 506 | B<NOTE>: the C<:utf8> and C<:encoding> features work only if your |
cdf6c183 TH |
507 | Perl has been built with L<PerlIO>, which is the default |
508 | on most systems. | |
0c901d84 | 509 | |
1ecefa54 JH |
510 | =head2 Displaying Unicode As Text |
511 | ||
512 | Sometimes you might want to display Perl scalars containing Unicode as | |
8baee566 | 513 | simple ASCII (or EBCDIC) text. The following subroutine converts |
1ecefa54 | 514 | its argument so that Unicode characters with code points greater than |
1bfb14c4 JH |
515 | 255 are displayed as C<\x{...}>, control characters (like C<\n>) are |
516 | displayed as C<\x..>, and the rest of the characters as themselves: | |
1ecefa54 | 517 | |
9e5bbba0 | 518 | sub nice_string { |
96cfa1df KW |
519 | join("", |
520 | map { $_ > 255 # if wide character... | |
521 | ? sprintf("\\x{%04X}", $_) # \x{...} | |
522 | : chr($_) =~ /[[:cntrl:]]/ # else if control character... | |
523 | ? sprintf("\\x%02X", $_) # \x.. | |
524 | : quotemeta(chr($_)) # else quoted or as themselves | |
525 | } unpack("W*", $_[0])); # unpack Unicode characters | |
58c274a1 JF |
526 | } |
527 | ||
528 | For example, | |
529 | ||
530 | nice_string("foo\x{100}bar\n") | |
531 | ||
d0551e73 | 532 | returns the string |
58c274a1 | 533 | |
d0551e73 JH |
534 | 'foo\x{0100}bar\x0A' |
535 | ||
536 | which is ready to be printed. | |
1ecefa54 | 537 | |
0145df7d KW |
538 | (C<\\x{}> is used here instead of C<\\N{}>, since it's most likely that |
539 | you want to see what the native values are.) | |
540 | ||
ba62762e JH |
541 | =head2 Special Cases |
542 | ||
543 | =over 4 | |
544 | ||
545 | =item * | |
546 | ||
fac71630 KW |
547 | Starting in Perl 5.28, it is illegal for bit operators, like C<~>, to |
548 | operate on strings containing code points above 255. | |
ba62762e | 549 | |
fac71630 KW |
550 | =item * |
551 | ||
552 | The vec() function may produce surprising results if | |
1bfb14c4 JH |
553 | used on strings containing characters with ordinal values above |
554 | 255. In such a case, the results are consistent with the internal | |
555 | encoding of the characters, but not with much else. So don't do | |
fac71630 KW |
556 | that, and starting in Perl 5.28, a deprecation message is issued if you |
557 | do so, becoming illegal in Perl 5.32. | |
ba62762e JH |
558 | |
559 | =item * | |
560 | ||
8baee566 JF |
561 | Peeking At Perl's Internal Encoding |
562 | ||
563 | Normal users of Perl should never care how Perl encodes any particular | |
a5f0baef | 564 | Unicode string (because the normal ways to get at the contents of a |
376d9008 | 565 | string with Unicode--via input and output--should always be via |
fae2c0fb | 566 | explicitly-defined I/O layers). But if you must, there are two |
a5f0baef | 567 | ways of looking behind the scenes. |
ba62762e JH |
568 | |
569 | One way of peeking inside the internal encoding of Unicode characters | |
f337b084 TH |
570 | is to use C<unpack("C*", ...> to get the bytes of whatever the string |
571 | encoding happens to be, or C<unpack("U0..", ...)> to get the bytes of the | |
572 | UTF-8 encoding: | |
ba62762e | 573 | |
8baee566 | 574 | # this prints c4 80 for the UTF-8 bytes 0xc4 0x80 |
f337b084 | 575 | print join(" ", unpack("U0(H2)*", pack("U", 0x100))), "\n"; |
ba62762e JH |
576 | |
577 | Yet another way would be to use the Devel::Peek module: | |
578 | ||
579 | perl -MDevel::Peek -e 'Dump(chr(0x100))' | |
580 | ||
1e54db1a | 581 | That shows the C<UTF8> flag in FLAGS and both the UTF-8 bytes |
376d9008 | 582 | and Unicode characters in C<PV>. See also later in this document |
8800c35a | 583 | the discussion about the C<utf8::is_utf8()> function. |
ba62762e JH |
584 | |
585 | =back | |
586 | ||
587 | =head2 Advanced Topics | |
588 | ||
589 | =over 4 | |
590 | ||
591 | =item * | |
592 | ||
593 | String Equivalence | |
594 | ||
595 | The question of string equivalence turns somewhat complicated | |
376d9008 | 596 | in Unicode: what do you mean by "equal"? |
ba62762e | 597 | |
07698885 RGS |
598 | (Is C<LATIN CAPITAL LETTER A WITH ACUTE> equal to |
599 | C<LATIN CAPITAL LETTER A>?) | |
ba62762e | 600 | |
a5f0baef JH |
601 | The short answer is that by default Perl compares equivalence (C<eq>, |
602 | C<ne>) based only on code points of the characters. In the above | |
376d9008 | 603 | case, the answer is no (because 0x00C1 != 0x0041). But sometimes, any |
c8695642 | 604 | CAPITAL LETTER A's should be considered equal, or even A's of any case. |
ba62762e JH |
605 | |
606 | The long answer is that you need to consider character normalization | |
e1b711da | 607 | and casing issues: see L<Unicode::Normalize>, Unicode Technical Report #15, |
ad37daf5 | 608 | L<Unicode Normalization Forms|https://www.unicode.org/reports/tr15> and |
30659cfd | 609 | sections on case mapping in the L<Unicode Standard|https://www.unicode.org>. |
ba62762e | 610 | |
1bfb14c4 | 611 | As of Perl 5.8.0, the "Full" case-folding of I<Case |
afba1538 | 612 | Mappings/SpecialCasing> is implemented, but bugs remain in C<qr//i> with them, |
4d2d7a4c | 613 | mostly fixed by 5.14, and essentially entirely by 5.18. |
ba62762e JH |
614 | |
615 | =item * | |
616 | ||
617 | String Collation | |
618 | ||
376d9008 | 619 | People like to see their strings nicely sorted--or as Unicode |
ba62762e JH |
620 | parlance goes, collated. But again, what do you mean by collate? |
621 | ||
07698885 RGS |
622 | (Does C<LATIN CAPITAL LETTER A WITH ACUTE> come before or after |
623 | C<LATIN CAPITAL LETTER A WITH GRAVE>?) | |
ba62762e | 624 | |
58c274a1 | 625 | The short answer is that by default, Perl compares strings (C<lt>, |
ba62762e | 626 | C<le>, C<cmp>, C<ge>, C<gt>) based only on the code points of the |
1bfb14c4 | 627 | characters. In the above case, the answer is "after", since |
da76a1f4 | 628 | C<0x00C1> > C<0x00C0>. |
ba62762e JH |
629 | |
630 | The long answer is that "it depends", and a good answer cannot be | |
631 | given without knowing (at the very least) the language context. | |
632 | See L<Unicode::Collate>, and I<Unicode Collation Algorithm> | |
ad37daf5 | 633 | L<https://www.unicode.org/reports/tr10/> |
ba62762e JH |
634 | |
635 | =back | |
636 | ||
637 | =head2 Miscellaneous | |
638 | ||
639 | =over 4 | |
640 | ||
641 | =item * | |
642 | ||
3ff56b75 | 643 | Character Ranges and Classes |
ba62762e | 644 | |
0eb9ada1 KW |
645 | Character ranges in regular expression bracketed character classes ( e.g., |
646 | C</[a-z]/>) and in the C<tr///> (also known as C<y///>) operator are not | |
647 | magically Unicode-aware. What this means is that C<[A-Za-z]> will not | |
648 | magically start to mean "all alphabetic letters" (not that it does mean that | |
649 | even for 8-bit characters; for those, if you are using locales (L<perllocale>), | |
650 | use C</[[:alpha:]]/>; and if not, use the 8-bit-aware property C<\p{alpha}>). | |
651 | ||
652 | All the properties that begin with C<\p> (and its inverse C<\P>) are actually | |
653 | character classes that are Unicode-aware. There are dozens of them, see | |
654 | L<perluniprops>. | |
655 | ||
0145df7d | 656 | Starting in v5.22, you can use Unicode code points as the end points of |
74fe8880 KW |
657 | regular expression pattern character ranges, and the range will include |
658 | all Unicode code points that lie between those end points, inclusive. | |
0145df7d | 659 | |
77c8f263 | 660 | qr/ [ \N{U+03} - \N{U+20} ] /xx |
0145df7d KW |
661 | |
662 | includes the code points | |
663 | C<\N{U+03}>, C<\N{U+04}>, ..., C<\N{U+20}>. | |
ba62762e | 664 | |
f3f4813b | 665 | This also works for ranges in C<tr///> starting in Perl v5.24. |
74fe8880 | 666 | |
ba62762e JH |
667 | =item * |
668 | ||
669 | String-To-Number Conversions | |
670 | ||
376d9008 JB |
671 | Unicode does define several other decimal--and numeric--characters |
672 | besides the familiar 0 to 9, such as the Arabic and Indic digits. | |
ba62762e | 673 | Perl does not support string-to-number conversion for digits other |
4d2d7a4c | 674 | than ASCII C<0> to C<9> (and ASCII C<a> to C<f> for hexadecimal). |
c8695642 | 675 | To get safe conversions from any Unicode string, use |
67592e11 | 676 | L<Unicode::UCD/num()>. |
ba62762e JH |
677 | |
678 | =back | |
679 | ||
680 | =head2 Questions With Answers | |
681 | ||
682 | =over 4 | |
683 | ||
818c4caa | 684 | =item * |
5cb3728c RB |
685 | |
686 | Will My Old Scripts Break? | |
ba62762e JH |
687 | |
688 | Very probably not. Unless you are generating Unicode characters | |
1bfb14c4 JH |
689 | somehow, old behaviour should be preserved. About the only behaviour |
690 | that has changed and which could start generating Unicode is the old | |
691 | behaviour of C<chr()> where supplying an argument more than 255 | |
692 | produced a character modulo 255. C<chr(300)>, for example, was equal | |
693 | to C<chr(45)> or "-" (in ASCII), now it is LATIN CAPITAL LETTER I WITH | |
694 | BREVE. | |
ba62762e | 695 | |
818c4caa | 696 | =item * |
5cb3728c RB |
697 | |
698 | How Do I Make My Scripts Work With Unicode? | |
ba62762e JH |
699 | |
700 | Very little work should be needed since nothing changes until you | |
1bfb14c4 JH |
701 | generate Unicode data. The most important thing is getting input as |
702 | Unicode; for that, see the earlier I/O discussion. | |
c8695642 KW |
703 | To get full seamless Unicode support, add |
704 | C<use feature 'unicode_strings'> (or C<use 5.012> or higher) to your | |
705 | script. | |
ba62762e | 706 | |
818c4caa | 707 | =item * |
5cb3728c RB |
708 | |
709 | How Do I Know Whether My String Is In Unicode? | |
ba62762e | 710 | |
c8695642 KW |
711 | You shouldn't have to care. But you may if your Perl is before 5.14.0 |
712 | or you haven't specified C<use feature 'unicode_strings'> or C<use | |
52d1f2c9 | 713 | 5.012> (or higher) because otherwise the rules for the code points |
c8695642 | 714 | in the range 128 to 255 are different depending on |
2bbc8d55 | 715 | whether the string they are contained within is in Unicode or not. |
e1b711da | 716 | (See L<perlunicode/When Unicode Does Not Happen>.) |
ba62762e | 717 | |
2bbc8d55 | 718 | To determine if a string is in Unicode, use: |
ba62762e | 719 | |
8800c35a | 720 | print utf8::is_utf8($string) ? 1 : 0, "\n"; |
ba62762e JH |
721 | |
722 | But note that this doesn't mean that any of the characters in the | |
723 | string are necessary UTF-8 encoded, or that any of the characters have | |
724 | code points greater than 0xFF (255) or even 0x80 (128), or that the | |
725 | string has any characters at all. All the C<is_utf8()> does is to | |
726 | return the value of the internal "utf8ness" flag attached to the | |
376d9008 | 727 | C<$string>. If the flag is off, the bytes in the scalar are interpreted |
3c1c8017 | 728 | as a single byte encoding. If the flag is on, the bytes in the scalar |
0eb9ada1 KW |
729 | are interpreted as the (variable-length, potentially multi-byte) UTF-8 encoded |
730 | code points of the characters. Bytes added to a UTF-8 encoded string are | |
1e54db1a | 731 | automatically upgraded to UTF-8. If mixed non-UTF-8 and UTF-8 scalars |
c8695642 | 732 | are merged (double-quoted interpolation, explicit concatenation, or |
3c1c8017 AT |
733 | printf/sprintf parameter substitution), the result will be UTF-8 encoded |
734 | as if copies of the byte strings were upgraded to UTF-8: for example, | |
735 | ||
736 | $a = "ab\x80c"; | |
737 | $b = "\x{100}"; | |
738 | print "$a = $b\n"; | |
739 | ||
a02b5feb JH |
740 | the output string will be UTF-8-encoded C<ab\x80c = \x{100}\n>, but |
741 | C<$a> will stay byte-encoded. | |
ba62762e JH |
742 | |
743 | Sometimes you might really need to know the byte length of a string | |
96b10823 | 744 | instead of the character length. For that use the C<bytes> pragma |
c8695642 | 745 | and the C<length()> function: |
ba62762e JH |
746 | |
747 | my $unicode = chr(0x100); | |
748 | print length($unicode), "\n"; # will print 1 | |
00d823b9 | 749 | use bytes; |
96b10823 | 750 | print length($unicode), "\n"; # will print 2 |
1bfb14c4 | 751 | # (the 0xC4 0x80 of the UTF-8) |
0eb9ada1 | 752 | no bytes; |
ba62762e | 753 | |
818c4caa | 754 | =item * |
5cb3728c | 755 | |
c8695642 KW |
756 | How Do I Find Out What Encoding a File Has? |
757 | ||
968ee499 | 758 | You might try L<Encode::Guess>, but it has a number of limitations. |
c8695642 KW |
759 | |
760 | =item * | |
761 | ||
5cb3728c | 762 | How Do I Detect Data That's Not Valid In a Particular Encoding? |
ba62762e | 763 | |
8baee566 JF |
764 | Use the C<Encode> package to try converting it. |
765 | For example, | |
ba62762e | 766 | |
8e179dd8 | 767 | use Encode 'decode'; |
2bbc8d55 | 768 | |
8e179dd8 P |
769 | if (eval { decode('UTF-8', $string, Encode::FB_CROAK); 1 }) { |
770 | # $string is valid UTF-8 | |
ba62762e | 771 | } else { |
8e179dd8 | 772 | # $string is not valid UTF-8 |
ba62762e JH |
773 | } |
774 | ||
f337b084 | 775 | Or use C<unpack> to try decoding it: |
ba62762e JH |
776 | |
777 | use warnings; | |
f337b084 | 778 | @chars = unpack("C0U*", $string_of_bytes_that_I_think_is_utf8); |
ba62762e | 779 | |
ae5648b3 RGS |
780 | If invalid, a C<Malformed UTF-8 character> warning is produced. The "C0" means |
781 | "process the string character per character". Without that, the | |
782 | C<unpack("U*", ...)> would work in C<U0> mode (the default if the format | |
783 | string starts with C<U>) and it would return the bytes making up the UTF-8 | |
f337b084 | 784 | encoding of the target string, something that will always work. |
ba62762e | 785 | |
818c4caa | 786 | =item * |
5cb3728c RB |
787 | |
788 | How Do I Convert Binary Data Into a Particular Encoding, Or Vice Versa? | |
ba62762e | 789 | |
8baee566 JF |
790 | This probably isn't as useful as you might think. |
791 | Normally, you shouldn't need to. | |
ba62762e | 792 | |
1bfb14c4 | 793 | In one sense, what you are asking doesn't make much sense: encodings |
376d9008 | 794 | are for characters, and binary data are not "characters", so converting |
a5f0baef JH |
795 | "data" into some encoding isn't meaningful unless you know in what |
796 | character set and encoding the binary data is in, in which case it's | |
376d9008 | 797 | not just binary data, now is it? |
8baee566 | 798 | |
1bfb14c4 JH |
799 | If you have a raw sequence of bytes that you know should be |
800 | interpreted via a particular encoding, you can use C<Encode>: | |
ba62762e JH |
801 | |
802 | use Encode 'from_to'; | |
f34228d6 | 803 | from_to($data, "iso-8859-1", "UTF-8"); # from latin-1 to UTF-8 |
ba62762e | 804 | |
1bfb14c4 JH |
805 | The call to C<from_to()> changes the bytes in C<$data>, but nothing |
806 | material about the nature of the string has changed as far as Perl is | |
807 | concerned. Both before and after the call, the string C<$data> | |
808 | contains just a bunch of 8-bit bytes. As far as Perl is concerned, | |
809 | the encoding of the string remains as "system-native 8-bit bytes". | |
8baee566 JF |
810 | |
811 | You might relate this to a fictional 'Translate' module: | |
812 | ||
813 | use Translate; | |
814 | my $phrase = "Yes"; | |
815 | Translate::from_to($phrase, 'english', 'deutsch'); | |
816 | ## phrase now contains "Ja" | |
ba62762e | 817 | |
8baee566 | 818 | The contents of the string changes, but not the nature of the string. |
1bfb14c4 JH |
819 | Perl doesn't know any more after the call than before that the |
820 | contents of the string indicates the affirmative. | |
ba62762e | 821 | |
376d9008 | 822 | Back to converting data. If you have (or want) data in your system's |
a5f0baef JH |
823 | native 8-bit encoding (e.g. Latin-1, EBCDIC, etc.), you can use |
824 | pack/unpack to convert to/from Unicode. | |
ba62762e | 825 | |
f337b084 TH |
826 | $native_string = pack("W*", unpack("U*", $Unicode_string)); |
827 | $Unicode_string = pack("U*", unpack("W*", $native_string)); | |
ba62762e JH |
828 | |
829 | If you have a sequence of bytes you B<know> is valid UTF-8, | |
830 | but Perl doesn't know it yet, you can make Perl a believer, too: | |
831 | ||
016b3422 P |
832 | $Unicode = $bytes; |
833 | utf8::decode($Unicode); | |
ba62762e | 834 | |
f337b084 TH |
835 | or: |
836 | ||
837 | $Unicode = pack("U0a*", $bytes); | |
ae5648b3 | 838 | |
2bbc8d55 SP |
839 | You can find the bytes that make up a UTF-8 sequence with |
840 | ||
9e5bbba0 | 841 | @bytes = unpack("C*", $Unicode_string) |
2bbc8d55 SP |
842 | |
843 | and you can create well-formed Unicode with | |
844 | ||
9e5bbba0 | 845 | $Unicode_string = pack("U*", 0xff, ...) |
ba62762e | 846 | |
818c4caa | 847 | =item * |
5cb3728c RB |
848 | |
849 | How Do I Display Unicode? How Do I Input Unicode? | |
ba62762e | 850 | |
2bbc8d55 SP |
851 | See L<http://www.alanwood.net/unicode/> and |
852 | L<http://www.cl.cam.ac.uk/~mgk25/unicode.html> | |
ba62762e | 853 | |
818c4caa | 854 | =item * |
5cb3728c RB |
855 | |
856 | How Does Unicode Work With Traditional Locales? | |
ba62762e | 857 | |
725a67e5 KW |
858 | If your locale is a UTF-8 locale, starting in Perl v5.26, Perl works |
859 | well for all categories; before this, starting with Perl v5.20, it works | |
860 | for all categories but C<LC_COLLATE>, which deals with | |
861 | sorting and the C<cmp> operator. But note that the standard | |
862 | C<L<Unicode::Collate>> and C<L<Unicode::Collate::Locale>> modules offer | |
863 | much more powerful solutions to collation issues, and work on earlier | |
864 | releases. | |
31f05a37 KW |
865 | |
866 | For other locales, starting in Perl 5.16, you can specify | |
66cbab2c KW |
867 | |
868 | use locale ':not_characters'; | |
869 | ||
31f05a37 | 870 | to get Perl to work well with them. The catch is that you |
66cbab2c KW |
871 | have to translate from the locale character set to/from Unicode |
872 | yourself. See L</Unicode IE<sol>O> above for how to | |
873 | ||
874 | use open ':locale'; | |
875 | ||
876 | to accomplish this, but full details are in L<perllocale/Unicode and | |
30189633 | 877 | UTF-8>, including gotchas that happen if you don't specify |
66cbab2c | 878 | C<:not_characters>. |
ba62762e JH |
879 | |
880 | =back | |
881 | ||
882 | =head2 Hexadecimal Notation | |
883 | ||
376d9008 JB |
884 | The Unicode standard prefers using hexadecimal notation because |
885 | that more clearly shows the division of Unicode into blocks of 256 characters. | |
ba62762e JH |
886 | Hexadecimal is also simply shorter than decimal. You can use decimal |
887 | notation, too, but learning to use hexadecimal just makes life easier | |
1bfb14c4 | 888 | with the Unicode standard. The C<U+HHHH> notation uses hexadecimal, |
076d825e | 889 | for example. |
ba62762e JH |
890 | |
891 | The C<0x> prefix means a hexadecimal number, the digits are 0-9 I<and> | |
892 | a-f (or A-F, case doesn't matter). Each hexadecimal digit represents | |
893 | four bits, or half a byte. C<print 0x..., "\n"> will show a | |
894 | hexadecimal number in decimal, and C<printf "%x\n", $decimal> will | |
895 | show a decimal number in hexadecimal. If you have just the | |
376d9008 | 896 | "hex digits" of a hexadecimal number, you can use the C<hex()> function. |
ba62762e JH |
897 | |
898 | print 0x0009, "\n"; # 9 | |
899 | print 0x000a, "\n"; # 10 | |
900 | print 0x000f, "\n"; # 15 | |
901 | print 0x0010, "\n"; # 16 | |
902 | print 0x0011, "\n"; # 17 | |
903 | print 0x0100, "\n"; # 256 | |
904 | ||
905 | print 0x0041, "\n"; # 65 | |
906 | ||
907 | printf "%x\n", 65; # 41 | |
908 | printf "%#x\n", 65; # 0x41 | |
909 | ||
910 | print hex("41"), "\n"; # 65 | |
911 | ||
912 | =head2 Further Resources | |
913 | ||
914 | =over 4 | |
915 | ||
916 | =item * | |
917 | ||
918 | Unicode Consortium | |
919 | ||
30659cfd | 920 | L<https://www.unicode.org/> |
ba62762e JH |
921 | |
922 | =item * | |
923 | ||
924 | Unicode FAQ | |
925 | ||
b11331f8 | 926 | L<https://www.unicode.org/faq/> |
ba62762e JH |
927 | |
928 | =item * | |
929 | ||
930 | Unicode Glossary | |
931 | ||
30659cfd | 932 | L<https://www.unicode.org/glossary/> |
ba62762e JH |
933 | |
934 | =item * | |
935 | ||
c8695642 KW |
936 | Unicode Recommended Reading List |
937 | ||
938 | The Unicode Consortium has a list of articles and books, some of which | |
939 | give a much more in depth treatment of Unicode: | |
940 | L<http://unicode.org/resources/readinglist.html> | |
941 | ||
942 | =item * | |
943 | ||
ba62762e JH |
944 | Unicode Useful Resources |
945 | ||
30659cfd | 946 | L<https://www.unicode.org/unicode/onlinedat/resources.html> |
ba62762e JH |
947 | |
948 | =item * | |
949 | ||
950 | Unicode and Multilingual Support in HTML, Fonts, Web Browsers and Other Applications | |
951 | ||
2bbc8d55 | 952 | L<http://www.alanwood.net/unicode/> |
ba62762e JH |
953 | |
954 | =item * | |
955 | ||
956 | UTF-8 and Unicode FAQ for Unix/Linux | |
957 | ||
2bbc8d55 | 958 | L<http://www.cl.cam.ac.uk/~mgk25/unicode.html> |
ba62762e JH |
959 | |
960 | =item * | |
961 | ||
962 | Legacy Character Sets | |
963 | ||
2bbc8d55 SP |
964 | L<http://www.czyborra.com/> |
965 | L<http://www.eki.ee/letter/> | |
ba62762e JH |
966 | |
967 | =item * | |
968 | ||
ba62762e JH |
969 | You can explore various information from the Unicode data files using |
970 | the C<Unicode::UCD> module. | |
971 | ||
972 | =back | |
973 | ||
f6edf83b JH |
974 | =head1 UNICODE IN OLDER PERLS |
975 | ||
976 | If you cannot upgrade your Perl to 5.8.0 or later, you can still | |
977 | do some Unicode processing by using the modules C<Unicode::String>, | |
978 | C<Unicode::Map8>, and C<Unicode::Map>, available from CPAN. | |
979 | If you have the GNU recode installed, you can also use the | |
376d9008 | 980 | Perl front-end C<Convert::Recode> for character conversions. |
f6edf83b | 981 | |
aaef10c5 | 982 | The following are fast conversions from ISO 8859-1 (Latin-1) bytes |
63de3cb2 | 983 | to UTF-8 bytes and back, the code works even with older Perl 5 versions. |
aaef10c5 JH |
984 | |
985 | # ISO 8859-1 to UTF-8 | |
986 | s/([\x80-\xFF])/chr(0xC0|ord($1)>>6).chr(0x80|ord($1)&0x3F)/eg; | |
987 | ||
988 | # UTF-8 to ISO 8859-1 | |
989 | s/([\xC2\xC3])([\x80-\xBF])/chr(ord($1)<<6&0xC0|ord($2)&0x3F)/eg; | |
990 | ||
ba62762e JH |
991 | =head1 SEE ALSO |
992 | ||
2575c402 | 993 | L<perlunitut>, L<perlunicode>, L<Encode>, L<open>, L<utf8>, L<bytes>, |
4c496f0c JH |
994 | L<perlretut>, L<perlrun>, L<Unicode::Collate>, L<Unicode::Normalize>, |
995 | L<Unicode::UCD> | |
ba62762e | 996 | |
376d9008 | 997 | =head1 ACKNOWLEDGMENTS |
ba62762e JH |
998 | |
999 | Thanks to the kind readers of the perl5-porters@perl.org, | |
1000 | perl-unicode@perl.org, linux-utf8@nl.linux.org, and unicore@unicode.org | |
1001 | mailing lists for their valuable feedback. | |
1002 | ||
1003 | =head1 AUTHOR, COPYRIGHT, AND LICENSE | |
1004 | ||
91a927c1 KW |
1005 | Copyright 2001-2011 Jarkko Hietaniemi E<lt>jhi@iki.fiE<gt>. |
1006 | Now maintained by Perl 5 Porters. | |
ba62762e JH |
1007 | |
1008 | This document may be distributed under the same terms as Perl itself. |