perlunicode - Online na nuvem

PROGRAMA:

NOME

perlunicode - suporte Unicode em Perl

DESCRIÇÃO

Se ainda não o fez, antes de ler este documento, você deve se familiarizar com ambos
perlunitut e perluniintro.

Unicode visa UNI-fique o en-CÓDIGO-ings de todos os conjuntos de caracteres do mundo em um único
Padrão. Para alguns dos vários padrões de codificação que existiam quando o Unicode era
criado pela primeira vez, a conversão de cada um para Unicode significava essencialmente adicionar uma constante a cada
ponto de código no padrão original, e converter de volta significava apenas subtrair esse mesmo
constante. Para ASCII e ISO-8859-1, a constante é 0. Para ISO-8859-5, (cirílico) o
constante é 864; para hebraico (ISO-8859-8), é 1488; Tailandês (ISO-8859-11), 3424; e entao
adiante. Isso tornou mais fácil fazer as conversões e facilitou a adoção do Unicode.

E funcionou; hoje em dia, esses padrões legados raramente são usados. Quase todo mundo usa
Unicode.

Unicode é um padrão abrangente. Ele especifica muitas coisas fora do escopo do Perl,
por exemplo, como exibir sequências de caracteres. Para uma discussão completa de todos os aspectos do
Unicode, vejahttp://www.unicode.org>.

importante Advertências
Embora parte desta seção possa não ser compreensível para você na primeira leitura, nós
acho que é importante o suficiente para destacar algumas das pegadinhas antes de aprofundar, então
aqui vai:

O suporte a Unicode é um requisito extenso. Embora o Perl não implemente o Unicode
padrão ou os relatórios técnicos que o acompanham de capa a capa, Perl dá suporte a muitos
Recursos Unicode.

Além disso, o uso de Unicode pode apresentar problemas de segurança que não são óbvios. Leia Unicode
Considerações de Segurançahttp://www.unicode.org/reports/tr36>.

Mais seguro se você "usar o recurso 'unicode_strings'"
A fim de preservar a compatibilidade com versões anteriores, Perl não liga totalmente interno
Suporte a Unicode, a menos que o pragma "use feature 'unicode_strings'" seja especificado. (Esse
é selecionado automaticamente se você "usar 5.012" ou superior.) Caso contrário, pode
desencadear surpresas inesperadas. Veja "O" Bug Unicode "" abaixo.

Este pragma não afeta a E / S. Nem muda a representação interna de
strings, apenas sua interpretação. Ainda existem vários lugares onde o Unicode
não é totalmente compatível, como em nomes de arquivos.

Camadas de entrada e saída
Use a camada ": encoding (...)" para ler e gravar em filehandles usando o
codificação especificada. (Veja aberto.)

Você deve converter seus scripts Perl não ASCII e não UTF-8 para UTF-8.
Veja codificação.

"use utf8" ainda é necessário para habilitar UTF-8 em scripts
Se o seu script Perl for codificado em UTF-8, o pragma "use utf8" deve ser
incluído explicitamente para permitir o reconhecimento disso (em string ou expressão regular
literais ou em nomes de identificadores). Este is da só tempo quando an explícito "usar utf8 "
is necessário. (Veja utf8).

Scripts marcados com "BOM" e scripts UTF-16 detectados automaticamente
No entanto, se um script Perl começar com o Unicode "BOM" (UTF-16LE, UTF16-BE ou
UTF-8), ou se o script se parece com UTF-16 não marcado com "BOM" de qualquer endianness, Perl
será lido corretamente no script como a codificação Unicode apropriada. ("BOM" - sem
UTF-8 não pode ser efetivamente reconhecido ou diferenciado de ISO 8859-1 ou outro
codificações de oito bits.)

Byte e Personagem Semântica
Antes do Unicode, a maioria das codificações usava 8 bits (um único byte) para codificar cada caractere. Assim
um caractere era um byte e um byte era um caractere e poderia haver apenas 256 ou menos
personagens possíveis. "Semântica de bytes" no título desta seção refere-se a este
comportamento. Não houve necessidade de distinguir entre "Byte" e "Character".

Em seguida, vem o Unicode, que tem espaço para mais de um milhão de caracteres (e o Perl permite
ainda mais). Isso significa que um caractere pode exigir mais de um único byte para representar
ele, e assim os dois termos não são mais equivalentes. O que importa são os personagens como
entidades inteiras, e não normalmente os bytes que as compõem. Esse é o termo
O título desta seção refere-se a "Semântica de caracteres".

Perl teve que mudar internamente para desacoplar "bytes" de "caracteres". É importante que
você também muda suas idéias, se ainda não o fez, de modo que "byte" e "caractere" não
já significam a mesma coisa em sua mente.

O bloco de construção básico das strings Perl sempre foi um "caractere". As mudanças
basicamente se resume a que a implementação não pensa mais que um personagem está sempre
apenas um único byte.

Existem várias coisas a serem observadas:

· Funções de manipulação de string, na maior parte, continuam a operar em termos de
personagens. "length ()", por exemplo, retorna o número de caracteres em uma string,
como antes. Mas esse número não é mais necessariamente o mesmo que o número de
bytes na string (pode haver mais bytes do que caracteres). O outro tal
as funções incluem "chop ()", "chomp ()", "substr ()", "pos ()", "index ()", "rindex ()",
"sort ()", "sprintf ()" e "write ()".

As exceções são:

· O bit-orientado "vec"

· O formato "empacotar" / "descompactar" "C" orientado a bytes

No entanto, o especificador "W" opera em caracteres inteiros, assim como o "U"
especificador.

· Alguns operadores que interagem com o sistema operacional da plataforma

Os operadores que lidam com nomes de arquivos são exemplos.

· Quando as funções são chamadas de dentro do escopo do pragma "use bytes"

Provavelmente, você deve usar isso apenas para depuração de qualquer maneira.

· Strings - incluindo chaves hash - e padrões de expressão regular podem conter caracteres
que têm valores ordinais maiores que 255.

Se você usar um editor Unicode para editar seu programa, podem ocorrer caracteres Unicode
diretamente nas strings literais na codificação UTF-8 ou UTF-16. (O antigo
requer um "BOM" ou "use utf8", o último requer um "BOM".)

"Criando Unicode" no perluniintro oferece outras maneiras de colocar caracteres não ASCII em
suas cordas.

· As funções "chr ()" e "ord ()" funcionam em caracteres inteiros.

· As expressões regulares correspondem a caracteres inteiros. Por exemplo, "." corresponde a um todo
caractere em vez de apenas um único byte.

· O operador "tr ///" traduz caracteres inteiros. (Observe que o "tr /// CU"
funcionalidade foi removida. Para obter uma funcionalidade semelhante a essa, consulte "pack ('U0',
...) "e" pack ('C0', ...) ").

· "Scalar reverse ()" reverte por caractere ao invés de byte.

· Os operadores de string de bits, "& | ^ ~" e (começando na v5.22) "&. |. ^. ~." pode operar
em caracteres que não cabem em um byte. No entanto, o comportamento atual tende a
mudança. Você não deve usar esses operadores em strings codificadas em UTF-8. Se
você não tem certeza sobre a codificação de uma string, faça o downgrade antes de usar qualquer um destes
operadores; você pode usar "utf8 :: utf8_downgrade ()".

O ponto principal é que Perl sempre praticou a "Semântica de Personagem", mas com o
advento do Unicode, que agora é diferente da "Semântica de bytes".

ASCII Regras contra Unicode Regras
Antes do Unicode, quando um caractere era um byte era um caractere, Perl sabia apenas sobre o 128
caracteres definidos por ASCII, pontos de código de 0 a 127 (exceto em "usar localidade").
Isso deixou os pontos de código 128 a 255 como não atribuídos e disponíveis para qualquer uso de um
programa pode querer. A única semântica que eles têm são seus números ordinais, e que eles
não são membros de nenhuma das classes de caracteres não negativos. Nenhum é considerado compatível
"\ w" por exemplo, mas todos correspondem a "\ W".

O Unicode, é claro, atribui a cada um desses pontos de código um significado particular (junto com
acima de 255). Para preservar a compatibilidade com versões anteriores, Perl usa apenas os significados Unicode
quando houver alguma indicação de que Unicode é o pretendido; caso contrário, o não-ASCII
os pontos de código permanecem tratados como se não estivessem atribuídos.

Aqui estão as maneiras que Perl sabe que uma string deve ser tratada como Unicode:

· No âmbito de "usar utf8"

Se todo o programa for Unicode (significado pelo uso de 8 bits UNicode Transformação
Format), então todas as strings dentro dele devem ser Unicode.

· Dentro do escopo de "usar o recurso 'unicode_strings'"

Este pragma foi criado para que você possa dizer explicitamente ao Perl que as operações foram executadas
dentro de seu escopo são para usar regras Unicode. Mais operações são afetadas com os mais novos
perls. Veja "O" Bug Unicode "".

· No âmbito de "usar 5.012" ou superior

Isso ativa implicitamente "usar o recurso 'unicode_strings'".

· Dentro do escopo "use locale 'not_characters'", ou "use locale" e o atual
locale é um locale UTF-8.

O primeiro é definido para implicar o manuseio Unicode; e o último indica um Unicode
locale, portanto, uma interpretação Unicode de todas as strings dentro dele.

· Quando a string contém um ponto de código somente Unicode

Perl nunca aceitou pontos de código acima de 255 sem eles serem Unicode, então seu uso
implica Unicode para toda a string.

· Quando a string contém um ponto de código chamado Unicode "\ N {...}"

A construção "\ N {...}" refere-se explicitamente a um ponto de código Unicode, mesmo que seja um
isso também está em ASCII. Portanto, a string que o contém deve ser Unicode.

· Quando a string veio de uma fonte externa marcada como Unicode

A opção de linha de comando "-C" pode especificar que certas entradas para o programa são
Unicode, e os valores disso podem ser lidos por seu código Perl, consulte "$ {^ UNICODE}" em
perlvar.

· Quando a string foi atualizada para UTF-8

A função "utf8 :: utf8_upgrade ()" pode ser explicitamente usada para permanentemente (a menos que um
subsequente "utf8 :: utf8_downgrade ()" é chamado) faz com que uma string seja tratada como
Unicode.

· Existem métodos adicionais para padrões de expressão regular

Um padrão compilado com os modificadores "/ u" ou "/ a" é tratado como Unicode
(embora haja algumas restrições com "/ a"). Sob os modificadores "/ d" e "/ l",
existem várias outras indicações para Unicode; consulte "Modificadores de conjunto de caracteres" em
perlre.

Observe que todos os itens acima são sobrescritos dentro do escopo de "bytes de uso"; mas voce devia
estar usando esse pragma apenas para depuração.

Observe também que algumas interações com o sistema operacional da plataforma nunca usam Unicode
regras.

Quando as regras Unicode estão em vigor:

· Os operadores de conversão de caso usam as tabelas de conversão de caso Unicode.

Observe que "uc ()", ou "\ U" em strings interpoladas, se traduz em maiúsculas, enquanto
"ucfirst", ou "\ u" em strings interpoladas, se traduz em titlecase em idiomas que
faça a distinção (que é equivalente a maiúsculas em idiomas sem o
distinção).

Existe um módulo CPAN, "Unicode :: Casing", que permite que você defina o seu próprio
mapeamentos a serem usados ​​em "lc ()", "lcfirst ()", "uc ()", "ucfirst ()" e "fc" (ou seus
versões sequenciais de strings com aspas duplas, como "\ U"). (Antes do Perl 5.16, este
funcionalidade foi fornecida parcialmente no núcleo Perl, mas sofreu de uma série de
desvantagens intransponíveis, então o módulo CPAN foi escrito em seu lugar.)

· As classes de caracteres em expressões regulares correspondem com base nas propriedades dos caracteres
especificado no banco de dados de propriedades Unicode.

"\ w" pode ser usado para corresponder a um ideograma japonês, por exemplo; e "[[: dígito:]]" a
Número bengali.

· Propriedades Unicode nomeadas, scripts e intervalos de blocos podem ser usados ​​(como colchetes
classes de caracteres) usando a construção "\ p {}" "coincide com a propriedade" e "\ P {}"
negação, "não corresponde à propriedade".

Consulte "Propriedades de caracteres Unicode" para obter mais detalhes.

Você pode definir suas próprias propriedades de caractere e usá-las na expressão regular
com a construção "\ p {}" ou "\ P {}". Veja "Propriedades de Caracteres Definidas pelo Usuário" para mais
Detalhes.

Alargado Grafema Clusters (Lógico personagens)
Considere um personagem, diga "H". Pode aparecer com várias marcas ao redor, como um
acento agudo, ou circunflexo, ou vários ganchos, círculos, setas, etc., acima, abaixo, para
um lado ou outro, etc.. Existem muitas possibilidades entre as línguas do mundo.
O número de combinações é astronômico, e se houvesse um caractere para cada
combinação, logo esgotaria os mais de um milhão de caracteres possíveis do Unicode. Então
O Unicode adotou uma abordagem diferente: há um caractere para a base "H" e um caractere
para cada uma das marcas possíveis, e estes podem ser combinados de várias maneiras para obter uma lógica final
personagem. Portanto, um personagem lógico - o que parece ser um único personagem - pode ser um
seqüência de mais de um caractere individual. O padrão Unicode chama isso de
"clusters de grafemas estendidos" (que é uma versão melhorada do já não muito usado
"cluster grafema"); Perl fornece a construção de expressão regular "\ X" para corresponder a tais
sequências em sua totalidade.

Mas a intenção do Unicode é unificar os padrões e práticas de conjunto de caracteres existentes, e
vários padrões pré-existentes têm caracteres únicos que significam a mesma coisa que alguns dos
essas combinações, como ISO-8859-1, que tem alguns deles. Por exemplo, "LATIN
LETRA MAIÚSCULA E COM AGUDA "já estava nesse padrão quando surgiu o Unicode.
O Unicode, portanto, o adicionou ao seu repertório como aquele único personagem. Mas esse personagem
é considerado pelo Unicode como equivalente à sequência que consiste no caractere
“LATIN CAPITAL LETTER E” seguido do caractere “COMBINING AGUTE ACCENT”.

"LETRA E MAIÚSCULA LATINA COM AGUDO" é denominado um caractere "pré-composto", e seu
equivalência com o "E" e a sequência de "ACENTO DE COMBINAÇÃO" é chamada de canônica
equivalência. Todos os caracteres pré-compostos são considerados como tendo uma decomposição (no
sequência equivalente), e o tipo de decomposição também é chamado de canônico. Uma corda pode
ser composto, tanto quanto possível, por caracteres pré-compostos, ou pode ser composto por
caracteres totalmente decompostos. O Unicode os chama, respectivamente, de "Formulário de Normalização
Composed "(NFC) e" Normalization Form Decomposed ". O módulo" Unicode :: Normalize "
contém funções que convertem entre os dois. Uma string também pode ter ambos compostos
caracteres e caracteres decompostos; este módulo pode ser usado para torná-lo um ou o
outro.

Podem ser apresentados strings em qualquer uma dessas formas equivalentes. Há atualmente
nada no Perl 5 que ignore as diferenças. Portanto, você terá que lidar especialmente com isso.
O conselho usual é converter suas entradas em "NFD" antes de continuar o processamento.

Para obter informações mais detalhadas, consultehttp://unicode.org/reports/tr15/>.

Unicode Personagem Propriedades
(A única vez que Perl considera uma sequência de pontos de código individuais como um único
caractere lógico está na construção "\ X", já mencionada acima. Portanto
"caractere" nesta discussão significa um único ponto de código Unicode.)

Quase todas as propriedades de caracteres Unicode são acessíveis por meio de expressões regulares por
usando a construção "\ p {}" "corresponde à propriedade" e "\ P {}" "não corresponde à propriedade" para
sua negação.

Por exemplo, "\ p {Maiúsculas}" corresponde a qualquer caractere único com o Unicode "Maiúsculas"
propriedade, enquanto "\ p {L}" corresponde a qualquer caractere com uma "CategoriaGeral" de "L" (letra)
propriedade (consulte "CategoriaGeral" abaixo). Os colchetes não são necessários para uma única letra
nomes de propriedades, então "\ p {L}" é equivalente a "\ pL".

Mais formalmente, "\ p {Maiúsculas}" corresponde a qualquer caractere único cujo Unicode "Maiúsculas"
o valor da propriedade é "Verdadeiro" e "\ P {Maiúsculas}" corresponde a qualquer caractere cujo "Maiúsculas"
o valor da propriedade é "False", e eles podem ter sido escritos como "\ p {Uppercase = True}" e
"\ p {Maiúsculas = Falso}", respectivamente.

Essa formalidade é necessária quando as propriedades não são binárias; isto é, se eles podem assumir mais
valores do que apenas "True" e "False". Por exemplo, a propriedade "Bidi_Class" (ver
"Tipos de caracteres bidirecionais" abaixo), pode assumir vários valores diferentes, como
"Esquerda", "Direita", "Espaço em branco" e outros. Para combiná-los, é necessário especificar os
nome da propriedade ("Bidi_Class") E o valor sendo correspondido ("Left", "Right", etc.).
Isso é feito, como nos exemplos acima, tendo os dois componentes separados por um
sinal (ou indistintamente, dois pontos), como "\ p {Bidi_Class: Left}".

Todas as propriedades de caracteres definidas por Unicode podem ser escritas nessas formas compostas de
"\ p {propriedade = valor} " ou "\ p {valor da propriedade}", mas Perl fornece algumas propriedades adicionais
que são escritos apenas no formato único, bem como atalhos de formato único para todos os binários
propriedades e algumas outras descritas abaixo, em que você pode omitir o nome da propriedade e
o igual ou separador de dois pontos.

A maioria das propriedades de caracteres Unicode têm pelo menos dois sinônimos (ou aliases, se você preferir): a
um curto que é mais fácil de digitar e um mais longo que é mais descritivo e, portanto,
mais fácil de entender. Assim, as propriedades "L" e "Letra" acima são equivalentes e podem
ser usado indistintamente. Da mesma forma, "Maiúsculas" é sinônimo de "Maiúsculas", e poderíamos
escreveu "\ p {Maiúsculas}" equivalentemente a "\ p {Maiúsculas}". Além disso, normalmente há
vários sinônimos para os valores que a propriedade pode ser. Para propriedades binárias, "True" tem 3
sinônimos: "T", "Sim" e "Y"; e "False" tem correspondentemente "F", "Não" e "N". Mas seja
cuidadoso. A forma abreviada de um valor para uma propriedade pode não significar a mesma coisa que o mesmo
forma abreviada de outro. Assim, para a propriedade "General_Category", "L" significa "Letra",
mas para a propriedade "Bidi_Class", "L" significa "Esquerda". Uma lista completa de propriedades e
sinônimos estão em perluniprops.

Diferenças em maiúsculas / minúsculas em nomes de propriedades e valores são irrelevantes; portanto, "\ p {Superior}"
significa a mesma coisa que "\ p {superior}" ou mesmo "\ p {UpPeR}". Da mesma forma, você pode adicionar ou
subtraia sublinhados em qualquer lugar no meio de uma palavra, de modo que eles também sejam equivalentes
para "\ p {U_p_p_e_r}". E o espaço em branco é irrelevante adjacente a caracteres não-word, como
como colchetes e iguais ou separadores de dois pontos, então "\ p {Superior}" e "\ p {Maiúsculas
: Y} "são equivalentes a estes também. Na verdade, espaços em branco e até mesmo hífens podem geralmente
ser adicionado ou excluído em qualquer lugar. Portanto, mesmo "\ p {por caso = Sim}" é equivalente. Tudo isso
é chamado de "correspondência flexível" pelo Unicode. Os poucos lugares onde uma correspondência mais rígida é usada é
no meio dos números e nas propriedades de extensão Perl que começam ou terminam com um
sublinhado. A correspondência mais estrita preocupa-se com o espaço em branco (exceto adjacente a não palavra
caracteres), hifens e sublinhados não internos.

Você também pode usar negação em "\ p {}" e "\ P {}" introduzindo um circunflexo ("^") entre
a primeira chave e o nome da propriedade: "\ p {^ Tamil}" é igual a "\ P {Tamil}".

Quase todas as propriedades são imunes à correspondência que não diferencia maiúsculas de minúsculas. Ou seja, adicionar um "/ i"
O modificador de expressão regular não altera o que corresponde. Existem dois conjuntos que são
afetados. O primeiro conjunto é "Uppercase_Letter", "Lowercase_Letter" e
"Titlecase_Letter", todos os quais correspondem a "Cased_Letter" na correspondência "/ i". E o segundo
conjunto é "Maiúscula", "Minúscula" e "Titlecase", todos correspondendo a "Cased" em "/ i"
Coincidindo. Este conjunto também inclui seus subconjuntos "PosixUpper" e "PosixLower", ambos os quais
em "/ i" corresponde a "PosixAlpha". (A diferença entre esses conjuntos é que algumas coisas,
como algarismos romanos, vêm em maiúsculas e minúsculas, portanto são "Casados", mas não são
consideradas letras, portanto, não são "Cased_Letter".)

Consulte "Além dos pontos de código Unicode" para considerações especiais ao corresponder Unicode
propriedades em relação a pontos de código não Unicode.

Geral_Categoria

Cada caractere Unicode é atribuído a uma categoria geral, que é a "mais usual
categorização de um personagem "(dehttp://www.unicode.org/reports/tr44>).

A forma composta de escrevê-los é como "\ p {General_Category = Number}" (abreviação:
"\ p {gc: n}"). Mas Perl fornece atalhos em que tudo passa pelo igual ou
o separador de dois pontos é omitido. Então você pode simplesmente escrever "\ pN".

Aqui estão as formas curta e longa dos valores que a propriedade "Categoria Geral" pode ter:

Curto longo

Letra L
LC, L & Cased_Letter (isto é: [\ p {Ll} \ p {Lu} \ p {Lt}])
Lu Maiúsculas_Letra
Ll Minúscula_Letra
Tenente Titlecase_Letter
Lm modificador_letra
Lo Other_Letter

Marca M
Mn Sem espaçamento_Marca
Mc Espaçamento_Marca
Eu encerrando_Mark

Número N
Nd Decimal_Number (também dígito)
Nl Letra_Número
Sem Other_Number

Pontuação P (também Punct)
Pc Connector_Pontuação
Pd Dash_Pontuação
Ps Open_Pontuação
Pe Fechar_Pontuação
Pi Inicial_Pontuação
(pode se comportar como Ps ou Pe dependendo do uso)
Pf Final_Pontuação
(pode se comportar como Ps ou Pe dependendo do uso)
Po Outro_Pontuação

Símbolo S
Sm Math_Symbol
Sc Moeda_Símbolo
Modificador Sk_Symbol
Então Other_Symbol

Separador Z
Espaço_Separador Zs
Zl Line_Separator
Zp Parágrafo_Separador

C Outro
Controle Cc (também Cntrl)
Formato Cf
Cs substituto
Coprivado_Uso
Cn não atribuído

As propriedades de uma única letra correspondem a todos os caracteres em qualquer uma das subpropriedades de duas letras
começando com a mesma letra. "LC" e "L &" são especiais: ambos são apelidos para o conjunto
consistindo em tudo correspondido por "Ll", "Lu" e "Lt".

Bidirecional Personagem Tipos

Porque os scripts diferem em sua direcionalidade (hebraico e árabe são escritos diretamente para
esquerda, por exemplo) Unicode fornece uma propriedade "Bidi_Class". Alguns dos valores são
propriedade pode ter são:

Significado de valor

L da esquerda para a direita
Incorporação LRE da esquerda para a direita
Substituição da esquerda para a direita LRO
R direita para esquerda
Carta Árabe AL
Incorporação RLE da direita para a esquerda
Substituição da direita para a esquerda de RLO
Formato PDF Pop Direcional
Número europeu EN
ES Separador Europeu
Exterminador Europeu ET
Um número árabe
Separador Comum CS
Marca sem espaçamento NSM
Neutro de limite BN
Separador de Parágrafo B
Separador de Segmento S
Espaço em branco do WS
ON Outros Neutros

Esta propriedade é sempre escrita na forma composta. Por exemplo, "\ p {Bidi_Class: R}"
corresponde a caracteres que normalmente são escritos da direita para a esquerda. Ao contrário de "General_Category"
, esta propriedade pode ter mais valores adicionados em uma versão futura do Unicode. Aqueles
listados acima compreendem o conjunto completo para muitas versões Unicode, mas outros foram adicionados
em Unicode 6.3; você sempre pode encontrar o que os atuais estão em perluniprops. E
<http://www.unicode.org/reports/tr9/> descreve como usá-los.

Scripts

Os idiomas do mundo são escritos em muitos scripts diferentes. Esta frase (a menos que você seja
ler na tradução) é escrito em latim, enquanto o russo é escrito em cirílico, e
O grego é escrito, bem, grego; Japonês principalmente em Hiragana ou Katakana. Existem muitos
mais.

As propriedades Unicode "Script" e "Script_Extensions" fornecem a qual script um determinado caractere
está em. Qualquer propriedade pode ser especificada com a forma composta como "\ p {Script = Hebraico}"
(abreviatura: "\ p {sc = hebr}"), ou "\ p {Script_Extensions = Javanês}" (abreviatura: "\ p {scx = java}"). No
Além disso, Perl fornece atalhos para todos os nomes de propriedades "Script". Você pode omitir
tudo até igual (ou dois pontos), e simplesmente escreva "\ p {latim}" ou
"\ P {Cirílico}". (Isso não é verdade para "Script_Extensions", que deve ser
escrito na forma composta.)

A diferença entre essas duas propriedades envolve caracteres que são usados ​​em vários
scripts. Por exemplo, os dígitos de '0' a '9' são usados ​​em muitas partes do mundo.
Eles são colocados em um script denominado "Comum". Outros personagens são usados ​​em apenas alguns
scripts. Por exemplo, o "KATAKANA-HIRAGANA DOUBLE HYPHEN" é usado em ambos os idiomas
scripts, Katakana e Hiragana, mas em nenhum outro lugar. A propriedade "Script" coloca todos
caracteres que são usados ​​em vários scripts no script "Comum", enquanto o
A propriedade "Script_Extensions" coloca aqueles que são usados ​​em apenas alguns scripts em cada um dos
esses scripts; enquanto ainda usa "Comum" para aqueles usados ​​em muitos scripts. Assim, ambos estes
partida:

"0" = ~ / \ p {sc = Comum} / # correspondências
"0" = ~ / \ p {scx = Comum} / # correspondências

e apenas o primeiro destes corresponde:

"\ N {KATAKANA-HIRAGANA DOUBLE HYPHEN}" = ~ / \ p {sc = Comum} # correspondências
"\ N {KATAKANA-HIRAGANA DOUBLE HYPHEN}" = ~ / \ p {scx = Comum} # Sem correspondência

E apenas os dois últimos deles correspondem:

"\ N {KATAKANA-HIRAGANA DOUBLE HYPHEN}" = ~ / \ p {sc = Hiragana} # Sem correspondência
"\ N {KATAKANA-HIRAGANA DOUBLE HYPHEN}" = ~ / \ p {sc = Katakana} # Sem correspondência
"\ N {KATAKANA-HIRAGANA DOUBLE HYPHEN}" = ~ / \ p {scx = Hiragana} # correspondências
"\ N {KATAKANA-HIRAGANA DOUBLE HYPHEN}" = ~ / \ p {scx = Katakana} # partidas

"Script_Extensions" é, portanto, um "Script" melhorado, no qual há menos caracteres em
o script "Comum" e, correspondentemente, mais em outros scripts. É novo em Unicode
versão 6.0, e seus dados provavelmente mudarão significativamente em versões posteriores, à medida que as coisas
ser resolvido. O novo código provavelmente deve estar usando "Script_Extensions" e não simples
"Roteiro".

(Na verdade, além de "Comum", o script "Herdado", contém caracteres que são usados ​​em
vários scripts. Estes são caracteres modificadores que herdam o valor do script do
personagem controlador. Alguns deles são usados ​​em muitos scripts e, portanto, vão para "Herdado"
em "Script" e "Script_Extensions". Outros são usados ​​em apenas alguns scripts, então são
em "Herdado" em "Script", mas não em "Script_Extensions".)

É importante ressaltar que existem vários conjuntos diferentes de dígitos em Unicode que são
equivalentes a 0-9 e são comparáveis ​​por "\ d" em uma expressão regular. Se eles são usados ​​em
um único idioma, eles estão no "Script" e "Script_Extension" desse idioma. Se
eles são usados ​​em mais de um script, eles estarão em "sc = Common", mas apenas se estiverem
usados ​​em muitos scripts devem estar em "scx = Common".

Uma lista completa de scripts e seus atalhos está em perluniprops.

Use of da "É" Prefixo

Para compatibilidade com versões anteriores (com Perl 5.6), todas as propriedades graváveis ​​sem usar o
a forma composta mencionada até agora pode ter "É" ou "É_" prefixado ao nome, então
"\ P {Is_Lu}", por exemplo, é igual a "\ P {Lu}", e "\ p {IsScript: Arabic}" é igual a
"\ p {árabe}".

Blocos

Além de Scripts, Unicode também define blocos de personagens. A diferença entre
scripts e blocos é que o conceito de scripts está mais próximo das linguagens naturais, enquanto
o conceito de blocos é mais um agrupamento artificial baseado em grupos de Unicode
caracteres com valores ordinais consecutivos. Por exemplo, o bloco "Latim básico" é tudo
os caracteres cujos ordinais estão entre 0 e 127, inclusive; em outras palavras, o ASCII
personagens. A escrita "latina" contém algumas letras deste, bem como de vários outros
blocos, como "Latin-1 Supplement", "Latin Extended-A", etc., mas não contém todos
os personagens desses blocos. Não contém, por exemplo, os dígitos 0-9,
porque esses dígitos são compartilhados por muitos scripts e, portanto, estão no script "Comum".

Para obter mais informações sobre scripts versus blocos, consulte UAX # 24 "Propriedade de script Unicode":
<http://www.unicode.org/reports/tr24>

As propriedades "Script" ou "Script_Extensions" são provavelmente as que você deseja usar
ao processar linguagem natural; a propriedade "Bloquear" pode ocasionalmente ser útil em
trabalhando com as porcas e parafusos do Unicode.

Os nomes dos blocos são combinados na forma composta, como "\ p {Bloco: setas}" ou
"\ p {Blk = hebraico}". Ao contrário da maioria das outras propriedades, apenas alguns nomes de bloco têm um Unicode-
nome abreviado definido. Mas Perl fornece um atalho (leve, não mais recomendado):
Você pode dizer, por exemplo "\ p {In_Arrows}" ou "\ p {In_Hebrew}".

Para compatibilidade com versões anteriores, o prefixo "In" pode ser omitido se não houver conflito de nomenclatura
com um script ou qualquer outra propriedade, e você pode até usar um prefixo "É" em vez disso
casos. Mas não faça isso para o novo código, porque seu código pode quebrar em novos lançamentos, e
isso já aconteceu: houve um tempo, nos primeiros lançamentos do Unicode, quando
"\ p {hebraico}" teria correspondido ao quadra Hebraico; agora não.

Usar o prefixo "In" evita essa ambigüidade, até agora. Mas as novas versões do Unicode continuam
para adicionar novas propriedades cujos nomes começam com "In". Existe a possibilidade de que um de
algum dia eles entrarão em conflito com seu uso. Uma vez que esta é apenas uma extensão Perl,
O nome Unicode terá precedência e seu código será quebrado. Além disso, Unicode é
livre para adicionar um script cujo nome comece com "In"; isso causaria problemas.

Portanto, é mais claro e melhor usar a forma composta ao especificar blocos. E tenha certeza
isso é o que você realmente deseja fazer. Na maioria dos casos, os scripts são o que você deseja
ao invés.

Uma lista completa de blocos e seus atalhos está em perluniprops.

Outros Propriedades

Existem muito mais propriedades do que as básicas descritas aqui. Uma lista completa
está em perluniprops.

Unicode define todas as suas propriedades na forma composta, então todas as propriedades de forma única são
Extensões Perl. A maioria deles são apenas sinônimos para os Unicode, mas alguns são
extensões genuínas, incluindo várias que estão na forma composta. E alguns de
estes são, na verdade, recomendados pelo Unicode (emhttp://www.unicode.org/reports/tr18>).

Esta seção fornece alguns detalhes sobre todas as extensões que não são apenas sinônimos de compostos
formar propriedades Unicode (para essas propriedades, você terá que se referir ao Unicode
Padrãohttp://www.unicode.org/reports/tr44>.

"\mortalha}"
Isso corresponde a todos os pontos de código possíveis. É equivalente a "qr /./ s". Ao contrário de todos os
outra propriedade "\ p {}" não definida pelo usuário corresponde, nenhum aviso é gerado se este
Esta propriedade é comparada com um ponto de código não-Unicode (veja "Além do código Unicode
pontos "abaixo).

"\ p {Alnum}"
Corresponde a qualquer caractere "\ p {Alphabetic}" ou "\ p {Decimal_Number}".

"\ p {Qualquer}"
Isso corresponde a qualquer um dos 1_114_112 pontos de código Unicode. É sinônimo de
"\ p {Unicode}".

"\ p {ASCII}"
Corresponde a qualquer um dos 128 caracteres do conjunto de caracteres US-ASCII, que é um
subconjunto de Unicode.

"\ p {Atribuído}"
Isso corresponde a qualquer ponto de código atribuído; ou seja, qualquer ponto de código cuja categoria geral
não é "Não atribuído" (ou, equivalentemente, não é "Cn").

"\ p {em branco}"
É o mesmo que "\ h" e "\ p {HorizSpace}": um caractere que altera o espaçamento
horizontalmente.

"\ p {Decomposition_Type: Não canônico}" (Resumindo: "\ p {Dt = NonCanon}")
Corresponde a um caractere que possui uma decomposição não canônica.

A seção "Extended Grapheme Clusters (caracteres lógicos)" acima falou sobre
decomposições canônicas. No entanto, muitos outros personagens têm um tipo diferente de
decomposição, uma decomposição "compatível" ou "não canônica". As sequências que
formar essas decomposições não são consideradas canonicamente equivalentes às
personagem composto. Um exemplo é o "SUPERSCRIPT ONE". É um pouco como um
dígito regular 1, mas não exatamente; sua decomposição no dígito 1 é chamada de
decomposição "compatível", especificamente uma decomposição "super". Existem vários
tais decomposições de compatibilidade (verhttp://www.unicode.org/reports/tr44>),
incluindo um chamado "compat", o que significa algum tipo diverso de decomposição
isso não se encaixa nas outras categorias de decomposição que o Unicode escolheu.

Observe que a maioria dos caracteres Unicode não tem uma decomposição, então sua decomposição
o tipo é "Nenhum".

Para sua conveniência, Perl adicionou o tipo de decomposição "Non_Canonical" para significar
qualquer uma das várias decomposições de compatibilidade.

"\ p {Gráfico}"
Corresponde a qualquer caractere gráfico. Teoricamente, isso significa um personagem que em
uma impressora faria com que a tinta fosse usada.

"\ p {HorizSpace}"
É o mesmo que "\ h" e "\ p {em branco}": um caractere que altera o espaçamento
horizontalmente.

"\ p {In = *}"
Este é um sinônimo para "\ p {Present_In = *}"

"\ p {PerlSpace}"
É o mesmo que "\ s", restrito a ASCII, a saber "[\ f \ n \ r \ t]" e começando em
Perl v5.18, uma guia vertical.

Mnemônico: espaço do Perl (original)

"\ p {PerlWord}"
É o mesmo que "\ w", restrito a ASCII, a saber "[A-Za-z0-9_]"

Mnemônico: palavra de Perl (original).

"\ p {Posix ...}"
Existem vários destes, que são equivalentes, usando a notação "\ p {}", para
Classes Posix e são descritas em "Classes de caracteres POSIX" em perlrecharclass.

"\ p {Presente_In: *} " (Resumindo: "\ p {In = *}")
Esta propriedade é usada quando você precisa saber em qual versão Unicode um caractere está.

O "*" acima representa um número de versão Unicode de dois dígitos, como 1.1 ou 4.0; ou
o "*" também pode ser "Não atribuído". Esta propriedade irá corresponder aos pontos de código cujo
a disposição final foi resolvida a partir do lançamento do Unicode dado pela versão
número; "\ p {Present_In: Unassigned}" corresponderá aos pontos de código cujo significado tem
ainda a ser atribuído.

Por exemplo, "U + 0041" "LATIN CAPITAL LETTER A" estava presente no primeiro Unicode
versão disponível, que é 1.1, portanto, esta propriedade é verdadeira para todas as versões "*" válidas.
Por outro lado, "U + 1EFF" não foi atribuído até a versão 5.1, quando se tornou "LATIN
PEQUENA LETRA Y COM LOOP ", então os únicos" * "que corresponderiam a 5.1, 5.2 e
mais tarde.

O Unicode fornece a propriedade "Age" da qual é derivado. O problema com a idade
é que uma interpretação estrita dele (que Perl leva) faz com que corresponda ao preciso
liberar o significado de um ponto de código é introduzido em. Portanto, "U + 0041" corresponderia apenas a 1.1;
e "U + 1EFF" apenas 5.1. Normalmente, não é isso que você deseja.

Algumas implementações não Perl da propriedade Age podem mudar seu significado para ser o
igual à propriedade "Present_In" do Perl; apenas esteja ciente disso.

Outra confusão com essas propriedades é que a definição não é que o
ponto de código foi atribuído, mas que o significado do ponto de código foi
determinado. Isso ocorre porque 66 pontos de código sempre serão não atribuídos, e assim o
"Idade" para eles é a versão Unicode em que foi tomada a decisão de torná-los assim.
Por exemplo, "U + FDD0" deve ser permanentemente não atribuído a um personagem, e a decisão
para fazer isso foi feito na versão 3.1, então "\ p {Age = 3.1}" corresponde a este caractere, como também
faz "\ p {Present_In: 3.1}" e superior.

"\ p {Imprimir}"
Corresponde a qualquer caractere gráfico ou em branco, exceto os controles.

"\ p {SpacePerl}"
É o mesmo que "\ s", incluindo além do ASCII.

Mnemônico: Espaço, conforme modificado por Perl. (Não inclui a guia vertical até
v5.18, que tanto o padrão Posix quanto o Unicode consideram espaço em branco.)

"\ p {Título}" e "\ p {Titlecase}"
Na correspondência com distinção entre maiúsculas e minúsculas, ambos correspondem aos mesmos pontos de código que "\ p {Geral
Categoria = Titlecase_Letter} "(" \ p {gc = lt} "). A diferença é que sob" / i "sem caixa
correspondência, estes correspondem o mesmo que "\ p {Cased}", enquanto "\ p {gc = lt}" corresponde
"\ p {Cased_Letter").

"\ p {Unicode}"
Isso corresponde a qualquer um dos 1_114_112 pontos de código Unicode. "\ p {Qualquer}".

"\ p {VertSpace}"
É o mesmo que "\ v": um caractere que altera o espaçamento verticalmente.

"\ p {Palavra}"
É o mesmo que "\ w", incluindo mais de 100_000 caracteres além do ASCII.

"\ p {XPosix ...}"
Existem vários deles, que são as classes Posix padrão estendidas ao completo
Intervalo Unicode. Eles são descritos em "Classes de caracteres POSIX" em perlrecharclass.

Usuário definido Personagem Propriedades
Você pode definir suas próprias propriedades de caracteres binários definindo sub-rotinas cujos nomes
comece com "In" ou "Is". (O recurso experimental "(? [])" Em perlre fornece um
alternativa que permite definições mais complexas.) As sub-rotinas podem ser definidas em qualquer
pacote. As propriedades definidas pelo usuário podem ser usadas na expressão regular "\ p {}" e
"\ P {}" construções; se você estiver usando uma propriedade definida pelo usuário de um pacote diferente do
aquele em que você está, você deve especificar seu pacote na construção "\ p {}" ou "\ P {}".

# assumindo a propriedade Is_Foreign definida em Lang ::
pacote principal; # nome do pacote de propriedade obrigatório
if ($ txt = ~ / \ p {Lang :: IsForeign} + /) {...}

package Lang; # nome do pacote de propriedade não obrigatório
if ($ txt = ~ / \ p {IsForeign} + /) {...}

Observe que o efeito é em tempo de compilação e imutável, uma vez definido. No entanto, as sub-rotinas
recebem um único parâmetro, que é 0 se a correspondência com distinção entre maiúsculas e minúsculas estiver em vigor e não
zero se a correspondência sem caso estiver em vigor. A sub-rotina pode retornar valores diferentes
dependendo do valor do sinalizador, e um conjunto de valores estará imutavelmente em vigor para
todas as correspondências com distinção entre maiúsculas e minúsculas e o outro conjunto para todas as correspondências sem distinção entre maiúsculas e minúsculas.

Observe que se a expressão regular estiver contaminada, Perl morrerá em vez de chamar o
sub-rotina quando o nome da sub-rotina é determinado pelos dados corrompidos.

As sub-rotinas devem retornar uma string formatada especialmente, com um ou mais newline-
linhas separadas. Cada linha deve ser uma das seguintes:

· Um único número hexadecimal denotando um ponto de código a ser incluído.

· Dois números hexadecimais separados por espaços em branco horizontais (espaço ou tabular
caracteres) denotando uma gama de pontos de código a serem incluídos.

· Algo a ser incluído, prefixado por "+": uma propriedade de caractere embutida (prefixada por
"utf8 ::") ou um caractere totalmente qualificado (incluindo o nome do pacote) definido pelo usuário
propriedade, para representar todos os caracteres nessa propriedade; dois códigos hexadecimais
pontos para um intervalo; ou um único ponto de código hexadecimal.

· Algo a ser excluído, prefixado por "-": uma propriedade de caractere existente (prefixado por
"utf8 ::") ou um caractere totalmente qualificado (incluindo o nome do pacote) definido pelo usuário
propriedade, para representar todos os caracteres nessa propriedade; dois códigos hexadecimais
pontos para um intervalo; ou um único ponto de código hexadecimal.

· Algo a ser negado, prefixado "!": Uma propriedade de caractere existente (prefixado por
"utf8 ::") ou um caractere totalmente qualificado (incluindo o nome do pacote) definido pelo usuário
propriedade, para representar todos os caracteres nessa propriedade; dois códigos hexadecimais
pontos para um intervalo; ou um único ponto de código hexadecimal.

· Algo para cruzar, prefixado por "&": uma propriedade de caractere existente (prefixado
por "utf8 ::") ou um caractere totalmente qualificado (incluindo o nome do pacote) definido pelo usuário
propriedade, para todos os caracteres, exceto os caracteres da propriedade; dois
pontos de código hexadecimal para um intervalo; ou um único ponto de código hexadecimal.

Por exemplo, para definir uma propriedade que cobre os silabários japoneses (hiragana e
katakana), você pode definir

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

Imagine que o marcador final here-doc está no início da linha. Agora você pode usar
"\ p {InKana}" e "\ P {InKana}".

Você também pode ter usado os nomes de propriedade de bloco existentes:

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

Suponha que você queira corresponder apenas aos caracteres alocados, não aos intervalos de bloco brutos: em
outras palavras, você deseja remover os caracteres não atribuídos:

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

A negação é útil para definir (surpresa!) Classes negadas.

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

Isso corresponderá a todos os pontos de código não Unicode, uma vez que cada um deles não está em Kana. Vocês
pode usar interseção para excluí-los, se desejado, como mostra este exemplo modificado:

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

& utf8 :: Qualquer deve ser a última linha na definição.

A interseção é geralmente usada para obter os caracteres comuns combinados por dois (ou mais)
Aulas. É importante lembrar de não usar "&" para o primeiro conjunto; isso seria
cruzando com nada, resultando em um conjunto vazio.

Ao contrário das correspondências de propriedade "\ p {}" não definidas pelo usuário, nenhum aviso é gerado se estes
as propriedades são comparadas a um ponto de código não Unicode (consulte "Além dos pontos de código Unicode"
abaixo).

Usuário definido Casos Mapeamentos (Por grave hackers apenas)
Este integrado tem sido afastado as of Perl 5.16. O módulo CPAN "Unicode :: Casing" fornece
melhor funcionalidade sem as desvantagens que esse recurso tinha. Se você estiver usando um Perl
anterior ao 5.16, esse recurso foi documentado de forma mais completa na versão 5.14 deste pod:
<http://perldoc.perl.org/5.14.0/perlunicode.html# User-Defined-Case-Mappings-% 28for-serious-hackers-only% 29>

Personagem Codificações for Entrada e saída
Veja Encode.

Unicode Regular Expressão Suporte Nível
A lista a seguir de recursos compatíveis com Unicode para expressões regulares descreve todos
recursos atualmente suportados diretamente pelo núcleo Perl. As referências ao "Nível N" e ao
números de seção referem-se ao Padrão Técnico Unicode # 18, "Unicode Regular
Expressions ", versão 13, de agosto de 2008.

· Nível 1 - Suporte Unicode Básico

RL1.1 Hex Notation - concluído [1]
Propriedades RL1.2 - concluído [2] [3]
Propriedades de compatibilidade RL1.2a - concluído [4]
RL1.3 Subtração e Intersecção - experimental [5]
RL1.4 Limites de palavras simples - concluído [6]
RL1.5 Simples Loose Matches - concluído [7]
Limites de linha RL1.6 - FALTA [8] [9]
RL1.7 Pontos de código suplementares - feito [10]

[1] "\ N {U + ...}" e "\ x {...}"
[2] "\ p {...}" "\ P {...}"
[3] suporta não apenas lista mínima, mas todas as propriedades de caracteres Unicode (ver Unicode
Propriedades do personagem acima)
[4] "\ d" "\ D" "\ s" "\ S" "\ w" "\ W" "\ X" "[:suporte:]" "[: ^ prop:]"
[5] O recurso experimental a partir da v5.18 "(? [...])" faz isso.
Veja "(? [])" Em perlre. Se não quiser usar um recurso experimental, você pode
use um dos seguintes:

· Antecipação de expressão regular

Você pode simular a subtração de classe usando lookahead. Por exemplo, qual UTS # 18
pode escrever como

[{Bloco = grego} - [{UNASSIGNED}]]

em Perl pode ser escrito como:

(?! \ p {Não atribuído}) \ p {Bloco = grego}
(? = \ p {Atribuído}) \ p {Bloco = Grego}

Mas, neste exemplo específico, você provavelmente realmente deseja

\ p {grego}

que corresponderá a caracteres atribuídos conhecidos por fazerem parte da escrita grega.

· Módulo CPAN "Unicode :: Regex :: Set"

Ele implementa todo o agrupamento, interseção, união e remoção do UTS # 18
(subtração) sintaxe.

· "Propriedades de caracteres definidas pelo usuário"

"+" para união, "-" para remoção (diferença de conjunto), "&" para interseção

[6] "\ b" "\ B"
[7] Observe que Perl faz a dobra completa de maiúsculas e minúsculas na correspondência, não Simples:
Por exemplo, "U + 1F88" é equivalente a "U + 1F00 U + 03B9", em vez de apenas "U + 1F80".
Esta diferença é importante principalmente para certas letras maiúsculas gregas com certas
modificadores: a dobra em caixa completa decompõe a letra, enquanto a caixa simples
dobrar iria mapeá-lo para um único personagem.

[8] Perl trata "\ n" como o delimitador de linha inicial e final. Unicode especifica mais
caracteres que devem ser interpretados dessa forma.
Estes são:

VT U + 000B (\ v em C)
FF U + 000C (\ f)
CR U + 000D (\ r)
NEL U + 0085
LS U + 2028
PS U + 2029

"^" e "$" em padrões de expressão regular devem corresponder a todos estes, mas
não Esses caracteres também não afetam, mas devem afetar "<>" $. E a linha do script
números.

Além disso, as linhas não devem ser divididas dentro de "CRLF" (ou seja, não há nenhuma linha vazia entre
"\ r" e "\ n"). Para "CRLF", tente a camada ": crlf" (consulte PerlIO).

[9] Mas "Unicode :: LineBreak" está disponível.
Este módulo fornece quebra de linha em conformidade com quebra de linha Unicode UAX # 14 "
Algoritmo"http://www.unicode.org/reports/tr14>.

[10] UTF-8 / UTF-EBDDIC usado em Perl permite não apenas "U + 10000" a "U + 10FFFF", mas também
além de "U + 10FFFF"
· Nível 2 - Suporte estendido a Unicode

Equivalentes canônicos RL2.1 - MISSING [10] [11]
RL2.2 Conjuntos de grafemas padrão - AUSENTE [12]
RL2.3 Limites de palavras padrão - CONCLUÍDO [14]
RL2.4 Combinações soltas padrão - FALTAS [15]
Propriedades do nome RL2.5 - FEITO
Propriedades curinga RL2.6 - FALTA

[10] consulte UAX # 15 "Formulários de normalização Unicode"
[11] tem Unicode :: Normalize, mas não integrado a regexes
[12] temos \ X e \ b {gcb}, mas não temos um "Grupo de Grapheme
Modo"
[14] ver UAX # 29, Limites de palavras
[15] Isso é abordado no Capítulo 3.13 (em Unicode 6.0)

· Nível 3 - Suporte sob medida

RL3.1 Pontuação Personalizada - FALTA
RL3.2 Conjuntos de grafemas personalizados - FALTADO [17] [18]
RL3.3 Limites de palavras personalizados - FALTANDO
RL3.4 Fósforos Soltos Personalizados - FALTANDO
Intervalos personalizados RL3.5 - FALTA
Correspondência de contexto RL3.6 - FALTA [19]
RL3.7 Partidas Incrementais - FALTANDO
(Compartilhamento de conjunto Unicode RL3.8)
RL3.9 Conjuntos de correspondências possíveis - FALTA
RL3.10 Combinação dobrada - FALTA [20]
RL3.11 Subcombinadores - FALTANDO

[17] consulte UAX # 10 "Algoritmos de agrupamento Unicode"
[18] tem Unicode :: Collate, mas não integrado a regexes
[19] tem (? <= X) e (? = X), mas olha para a frente ou para trás
deve ver fora da substring alvo
[20] precisam de correspondência insensível para características linguísticas outros
do que caso; por exemplo, hiragana a katakana, amplo e
Han estreito e simplificado para Han tradicional (consulte UTR # 30
"Dobramento de personagens")

Unicode Codificações
Caracteres Unicode são atribuídos a código pontos, que são números abstratos. Para usar estes
números, várias codificações são necessárias.

· UTF-8

UTF-8 é uma codificação independente de ordem de bytes de comprimento variável (1 a 4 bytes). Na maioria
da documentação do Perl, incluindo em outras partes deste documento, o termo "UTF-8" significa
também "UTF-EBCDIC". Mas, nesta seção, "UTF-8" se refere apenas à codificação usada em
Plataformas ASCII. É um superconjunto de US-ASCII de 7 bits, portanto, qualquer coisa codificada em ASCII tem
a representação idêntica quando codificada em UTF-8.

A tabela a seguir é do Unicode 3.2.

Pontos de código 1o byte 2o byte 3o byte 4o byte

U + 0000..U + 007F 00..7F
U + 0080..U + 07FF * C2..DF 80..BF
U + 0800..U + 0FFF E0 * A0..BF 80..BF
U + 1000..U + CFFF E1..EC 80..BF 80..BF
U + D000..U + D7FF ED 80..9F 80..BF
U + D800..U + DFFF +++++ utf16 substitutos, utf8 ilegal +++++
U + E000..U + FFFF EE..EF 80..BF 80..BF
U + 10000..U + 3FFFF F0 * 90..BF 80..BF 80..BF
U + 40000..U + FFFFF F1..F3 80..BF 80..BF 80..BF
U + 100000..U + 10FFFF F4 80..8F 80..BF 80..BF

Observe as lacunas marcadas por "*" antes de várias das entradas de bytes acima. Estes são
causado por UTF-8 legal, evitando codificações não mais curtas: é tecnicamente possível
UTF-8 codifica um único ponto de código de maneiras diferentes, mas isso é explicitamente proibido,
e a codificação mais curta possível deve sempre ser usada (e é isso que o Perl faz).

Outra maneira de ver isso é por meio de bits:

Pontos de código 1o byte 2o byte 3o byte 4o byte

0aaaa 0aaaa
00000bbbbaaaaaaaaaa 110bbbbbb 10aaaaa
ccccbbbbbbbaaaaaa 1110cccc 10bbbbbb 10aaaaaa
00000dddccccccccbbbbbbaaaaaa 11110ddd 10cccccc 10bbbbbb 10aaaaaa

Como você pode ver, todos os bytes de continuação começam com "10" e os bits iniciais de
o byte inicial informa quantos bytes existem no caractere codificado.

A especificação UTF-8 original permitia até 6 bytes, para permitir a codificação de números
até "0x7FFF_FFFF". Perl continua permitindo isso, e estendeu para 13
bytes para codificar pontos de código até o que pode caber em uma palavra de 64 bits. No entanto, Perl irá
avisa se você enviar algum destes como não portátil; e sob entrada UTF-8 estrita
protocolos, eles são proibidos.

· UTF-EBCDIC

Como UTF-8, mas seguro para EBCDIC, da mesma forma que UTF-8 é seguro para ASCII. Isso significa que todos
os caracteres básicos (que incluem todos aqueles que têm equivalentes ASCII (como "A",
"0", "%", etc.) são iguais em EBCDIC e UTF-EBCDIC.)

UTF-EBCDIC é usado em plataformas EBCDIC. Os maiores pontos de código Unicode ocupam 5 bytes
para representar (em vez de 4 em UTF-8), e Perl o estende a um máximo de 7 bytes para
codificar pode aponta até o que pode caber em uma palavra de 32 bits (em vez de 13 bytes e um
Palavra de 64 bits em UTF-8).

· UTF-16, UTF-16BE, UTF-16LE, substitutos e "BOM" (marcas de ordem de bytes)

Os itens a seguir são principalmente para referência e conhecimento geral de Unicode, Perl
não usa essas construções internamente.

Como UTF-8, UTF-16 é uma codificação de largura variável, mas onde UTF-8 usa código de 8 bits
unidades, UTF-16 usa unidades de código de 16 bits. Todos os pontos de código ocupam 2 ou 4 bytes em
UTF-16: os pontos de código "U + 0000..U + FFFF" são armazenados em uma única unidade de 16 bits e o código
aponta "U + 10000..U + 10FFFF" em duas unidades de 16 bits. O último caso está usando substitutos,
a primeira unidade de 16 bits sendo o Alto substituto, e o segundo sendo o baixo
substituto.

Substitutos são pontos de código separados para codificar o intervalo "U + 10000..U + 10FFFF" de
Pontos de código Unicode em pares de unidades de 16 bits. o Alto substitutos são o alcance
"U + D800..U + DBFF" e o baixo substitutos são a faixa "U + DC00..U + DFFF". O substituto
codificação é

$ hi = ($ uni - 0x10000) / 0x400 + 0xD800;
$ lo = ($ uni - 0x10000)% 0x400 + 0xDC00;

e a decodificação é

$ uni = 0x10000 + ($ hi - 0xD800) * 0x400 + ($ lo - 0xDC00);

Por causa dos 16 bits, o UTF-16 é dependente da ordem de bytes. O próprio UTF-16 pode ser usado
para cálculos na memória, mas se o armazenamento ou transferência for necessário, UTF-16BE
(big-endian) ou codificações UTF-16LE (little-endian) devem ser escolhidas.

Isso introduz outro problema: e se você apenas souber que seus dados são UTF-16, mas
você não sabe qual endianness? Byte Order Marks, ou "BOM", são uma solução para
isto. Um caractere especial foi reservado no Unicode para funcionar como uma ordem de bytes
marcador: o personagem com o ponto de código "U + FEFF" é o "BOM".

O truque é que se você ler um "BOM", saberá a ordem dos bytes, pois se fosse
escrito em uma plataforma big-endian, você lerá os bytes "0xFE 0xFF", mas se fosse
escrito em uma plataforma little-endian, você lerá os bytes "0xFF 0xFE". (E se o
a plataforma de origem estava escrevendo na plataforma ASCII UTF-8, você vai ler os bytes
"0xEF 0xBB 0xBF".)

A maneira como esse truque funciona é que o personagem com o ponto de código "U + FFFE" não é
deveria estar em fluxos de entrada, então a sequência de bytes "0xFF 0xFE" é inequivocamente
"" BOM ", representado no formato little-endian" e não pode ser "U + FFFE", representado em
formato big-endian ".

Substitutos não têm significado em Unicode fora de seu uso em pares para representar outros
pontos de código. No entanto, Perl permite que eles sejam representados individualmente internamente, para
exemplo, dizendo "chr(0xD801) ", de modo que todos os pontos de código, não apenas aqueles válidos para
intercâmbio aberto, são representáveis. Unicode define semântica para eles, como
sua "CategoriaGeral" é "Cs". Mas porque seu uso é um tanto perigoso, Perl
irá avisar (usando a categoria de aviso "substituto", que é uma subcategoria de "utf8")
se for feita uma tentativa de fazer coisas como usar a minúscula de um ou combinar maiúsculas
de forma insensível, ou para enviá-los. (Mas não tente fazer isso no Perls antes de 5.14.)

· UTF-32, UTF-32BE, UTF-32LE

A família UTF-32 é muito parecida com a família UTF-16, exceto que as unidades são
32 bits e, portanto, o esquema substituto não é necessário. UTF-32 tem largura fixa
codificação. As assinaturas de "BOM" são "0x00 0x00 0xFE 0xFF" para BE e "0xFF 0xFE 0x00
0x00 "para LE.

· UCS-2, UCS-4

Codificações legadas de largura fixa definidas pelo padrão ISO 10646. UCS-2 é um 16 bits
codificação. Ao contrário do UTF-16, o UCS-2 não é extensível além de "U + FFFF", porque não
usar substitutos. UCS-4 é uma codificação de 32 bits, funcionalmente idêntica a UTF-32 (o
diferença sendo que o UCS-4 não proíbe substitutos nem pontos de código maiores que
"0x10_FFFF").

· UTF-7

Uma codificação segura de sete bits (não oito bits), que é útil se o transporte ou armazenamento
não é seguro para oito bits. Definido pela RFC 2152.

Sem caráter código pontos
66 pontos de código são separados em Unicode como "pontos de código não característicos". Todos estes têm o
"Unassigned" ("Cn") "General_Category", e nenhum personagem será atribuído a qualquer um dos
eles. Eles são os 32 pontos de código entre "U + FDD0" e "U + FDEF" inclusive, e os 34
pontos de código:

U + FFFE U + FFFF
U + 1FFFE U + 1FFFF
U + 2FFFE U + 2FFFF
...
U + EFFFE U + EFFFF
U + FFFFE U + FFFFF
U + 10FFFE U + 10FFFF

Até Unicode 7.0, os não caracteres eram "proibido para uso em intercâmbio aberto de
Dados de texto Unicode ", para que o código que processou esses fluxos pudesse usar esses pontos de código
como sentinelas que podem ser misturadas com dados de personagens, e sempre seriam
distinguível desses dados. (Ênfase acima e no próximo parágrafo são adicionados em
esse documento.)

O Unicode 7.0 mudou o texto para que sejam "não Recomenda para uso em aberto
intercâmbio de dados de texto Unicode ". O padrão 7.0 continua dizendo:

"Se um não caractere for recebido no intercâmbio aberto, um aplicativo não é necessário para
interpretar de qualquer maneira. É uma boa prática, no entanto, reconhecê-lo como um
não característico e tomar as medidas adequadas, como substituí-lo por "U + FFFD"
caractere de substituição, para indicar o problema no texto. Não é recomendado para
simplesmente exclua pontos de código não característicos desse texto, devido ao potencial
problemas de segurança causados ​​pela exclusão de caracteres não interpretados. (Ver cláusula de conformidade
C7 na Seção 3.2, Requisitos de Conformidade e Relatório Técnico Unicode nº 36,
"Considerações de segurança Unicode"
<http://www.unicode.org/reports/tr36/#Substituting_for_Ill_Formed_Subsequences>). "

Essa alteração foi feita porque foi constatado que várias ferramentas comerciais, como editores, ou
para coisas como controle de código-fonte, foi escrito de forma que não iria lidar com
arquivos de programa que usavam esses pontos de código, impedindo efetivamente seu uso quase
inteiramente! E essa nunca foi a intenção. Eles sempre foram feitos para serem usados ​​dentro
um aplicativo, ou conjunto cooperativo de aplicativos, à vontade.

Se você está escrevendo código, como um editor, que deve ser capaz de lidar com qualquer
Dados de texto Unicode, então você não deveria usar esses pontos de código e, em vez disso,
permiti-los na entrada. Se você precisa de sentinelas, eles devem ser algo que
não é Unicode legal. Para dados UTF-8, você pode usar os bytes 0xC1 e 0xC2 como sentinelas, como
eles nunca aparecem em UTF-8 bem formado. (Existem equivalentes para UTF-EBCDIC). Você pode
também armazena seus pontos de código Unicode em variáveis ​​inteiras e usa valores negativos como
sentinelas.

Se você não está escrevendo tal ferramenta, então aceitar ou não caracteres como entrada depende de
você (embora o Padrão recomende que não). Se você fizer uma verificação estrita do fluxo de entrada
com Perl, esses pontos de código continuam a ser proibidos. Isso é para manter para trás
compatibilidade (caso contrário, brechas de segurança em potencial podem se abrir, como um desavisado
aplicativo que foi escrito assumindo que os não caracteres seriam filtrados antes
conseguindo, poderia agora, sem aviso, começar a obtê-los). Para fazer uma verificação estrita,
você pode usar a camada ": encoding ('UTF-8')".

Perl continua a avisar (usando a categoria de aviso "nonchar", que é uma subcategoria de
"utf8") se for feita uma tentativa de saída de não caracteres.

Pós Unicode código pontos
O ponto de código Unicode máximo é "U + 10FFFF", e Unicode apenas define operações no código
aponta para cima através disso. Mas Perl funciona em pontos de código até o máximo permitido
número sem sinal disponível na plataforma. No entanto, Perl não os aceitará de entrada
streams, a menos que regras relaxadas estejam sendo usadas, e irá avisar (usando a categoria de aviso
"non_unicode", que é uma subcategoria de "utf8") se houver alguma saída.

Como as regras Unicode não são definidas nesses pontos de código, se uma operação definida por Unicode
é feito neles, Perl usa o que acreditamos serem regras sensatas, embora geralmente avise,
usando a categoria "non_unicode". Por exemplo, "uc (" \ x {11_0000} ")" irá gerar tal
aviso, retornando o parâmetro de entrada como seu resultado, uma vez que Perl define as letras maiúsculas de
cada ponto de código não Unicode é o próprio ponto de código. (Todas as maiúsculas e minúsculas mudando
operações, não apenas maiúsculas, funcionam desta forma.)

A situação com propriedades Unicode correspondentes em expressões regulares, o "\ p {}" e
"\ P {}" constrói, contra esses pontos de código não é tão claro, e como eles são
manipulado mudou à medida que ganhamos experiência.

Uma possibilidade é tratar qualquer correspondência com esses pontos de código como indefinida. Mas desde
Perl não tem o conceito de uma correspondência ser indefinida, ele converte isso em falha ou
"FALSO". Isso é quase, mas não exatamente, o que Perl fez a partir da v5.14 (quando o uso deste código
pontos tornaram-se geralmente confiáveis) por meio da v5.18. A diferença é que Perl tratou todos
"\ p {}" corresponde como falha, mas todas as correspondências "\ P {}" como bem-sucedidas.

Um problema com isso é que leva a resultados inesperados e confiantes em alguns
casos:

chr(0x110000) = ~ \ p {ASCII_Hex_Digit = True} # Falha em <= v5.18
chr(0x110000) = ~ \ p {ASCII_Hex_Digit = False} # Falha! em <= v5.18

Ou seja, ele tratou ambas as correspondências como indefinidas e converteu isso em falso (gerando um
aviso em cada). O primeiro caso é o resultado esperado, mas o segundo é provável
contra-intuitivo: "Como ambos podem ser falsos quando são complementos?" Outro problema
foi que a implementação otimizou muitas correspondências de propriedade Unicode até já
operações existentes mais simples e rápidas, que não geram o aviso. Nós escolhemos não abrir mão
aquelas otimizações, que ajudam a grande maioria das partidas, apenas para gerar um aviso
para o evento improvável de um ponto de código acima do Unicode estar sendo comparado.

Como resultado desses problemas, a partir da v5.20, o que Perl faz é tratar não-Unicode
pontos de código apenas como caracteres Unicode não atribuídos típicos e corresponde de acordo.
(Observação: Unicode tem pontos de código não atribuídos atípicos. Por exemplo, tem código não característico
pontos, e aqueles que, quando forem atribuídos, estão destinados a ser escritos Right-to-
esquerda, como o árabe e o hebraico. Perl assume que nenhum ponto de código não Unicode tem qualquer
propriedades atípicas.)

O Perl, na maioria dos casos, irá gerar um aviso ao combinar um ponto de código acima do Unicode
contra uma propriedade Unicode quando o resultado é "TRUE" para "\ p {}" e "FALSE" para "\ P {}".
Por exemplo:

chr(0x110000) = ~ \ p {ASCII_Hex_Digit = True} # Falha, sem aviso
chr(0x110000) = ~ \ p {ASCII_Hex_Digit = False} # Êxito, com aviso

Em ambos os exemplos, o caractere que está sendo correspondido não é Unicode, portanto, Unicode não
definir como ele deve corresponder. Claramente não é um dígito hexadecimal ASCII, então o primeiro exemplo
claramente deve falhar, e assim é, sem nenhum aviso. Mas é discutível que o segundo
O exemplo deve ter um resultado indefinido, portanto "FALSE". Portanto, um aviso é levantado para isso.

Assim, o aviso é gerado para muito menos casos do que em Perls anteriores, e apenas quando o que
o resultado pode ser discutível. Acontece que nenhuma das otimizações feitas por Perl
(ou é provável que ocorram) faz com que o aviso seja ignorado, de modo que resolve ambos
problemas da abordagem anterior do Perl. A propriedade mais comumente usada que é afetada por
esta mudança é "\ p {Unassigned}", que é uma forma abreviada de
"\ p {General_Category = Não atribuído}". A partir da v5.20, todos os pontos de código não Unicode são
considerado "Não atribuído". Em versões anteriores, as correspondências falharam porque o resultado foi
considerado indefinido.

O único lugar onde o aviso não é levantado, quando deveria ser, é se
otimizações fazem com que toda a correspondência de padrão nem mesmo seja tentada. Por exemplo, Perl
pode descobrir que para uma string corresponder a um certo padrão de expressão regular, a string
deve conter a substring "foobar". Antes de tentar a correspondência, Perl pode procurar
essa substring, e se não for encontrada, imediatamente falha a correspondência sem realmente tentar;
portanto, nenhum aviso é gerado, mesmo se a string contiver um ponto de código acima do Unicode.

Esse comportamento é mais "Faça o que quero dizer" do que em Perls anteriores para a maioria dos aplicativos. Mas
ele detecta menos problemas para código que precisa ser estritamente compatível com Unicode. Portanto
há um modo adicional de operação disponível para acomodar esse código. Este modo é
ativado se um padrão de expressão regular for compilado dentro do escopo léxico onde o
A classe de aviso "non_unicode" tornou-se fatal, digamos por:

use avisos FATAL => "non_unicode"

(veja os avisos). Neste modo de operação, Perl irá disparar o aviso para todas as partidas
contra um ponto de código não Unicode (não apenas os discutíveis) e ignora o
otimizações que podem fazer com que o aviso não seja exibido. (Atualmente ainda não
avise se a correspondência não for sequer tentada, como no exemplo "foobar" acima.)

Em resumo, o Perl agora normalmente trata os pontos de código não Unicode como Unicode não atribuído típico
pontos de código para correspondências de expressão regular, gerando um aviso apenas quando for discutível
qual deve ser o resultado. No entanto, se este aviso se tornou fatal, não é
pulado.

Há uma exceção para tudo isso. "\ p {All}" parece uma propriedade Unicode, mas é um
Extensão Perl que é definida para ser verdadeira para todos os pontos de código possíveis, Unicode ou não, então
nenhum aviso é gerado ao comparar isso com um ponto de código não Unicode. (Anterior
para v5.20, era um sinônimo exato para "\ p {Any}", correspondendo aos pontos de código de 0 a 0x10FFFF.)

Segurança Implicações of Unicode
Primeiro, leia Considerações de segurança Unicodehttp://www.unicode.org/reports/tr36>.

Além disso, observe o seguinte:

· UTF-8 malformado

Infelizmente, a especificação original do UTF-8 deixa algum espaço para interpretação
de quantos bytes de saída codificada se deve gerar a partir de uma entrada Unicode
personagem. Estritamente falando, a menor sequência possível de bytes UTF-8 deve ser
gerado, porque caso contrário, há potencial para um estouro do buffer de entrada no
extremidade de recepção de uma conexão UTF-8. Perl sempre gera o menor comprimento UTF-8,
e com os avisos ativados, o Perl avisará sobre UTF-8 de comprimento não menor junto com outros
malformações, como os substitutos, que não são pontos de código Unicode válidos para
intercâmbio.

· A correspondência de padrão de expressão regular pode surpreendê-lo se você não estiver acostumado a
Unicode. A partir do Perl 5.14, vários modificadores de padrão estão disponíveis para controlar
isso, chamado de modificadores de conjunto de caracteres. Os detalhes são fornecidos em "Conjunto de caracteres
modificadores "em perlre.

Como discutido em outro lugar, Perl tem um pé (dois cascos?) Plantado em cada um dos dois mundos: o
velho mundo de ASCII e localidades de byte único, e o novo mundo de Unicode, atualizando quando
necessário. Se o seu código legado não usa explicitamente Unicode, nenhuma mudança automática
para Unicode deve acontecer.

Unicode in Perl on EBCDIC
Unicode é compatível com plataformas EBCDIC. Veja perlebcdic.

A menos que questões de ASCII vs. EBCDIC estejam sendo especificamente discutidas, referências a UTF-8
codificação neste documento e em outros lugares deve ser lida como significando UTF-EBCDIC em EBCDIC
plataformas. Consulte "Unicode e UTF" em perlebcdic.

Como o UTF-EBCDIC é muito semelhante ao UTF-8, as diferenças estão, na maior parte, escondidas de você;
"use utf8" (e NÃO algo como "use utfebcdic") declara que o script está no
codificação "nativa" de 8 bits da plataforma de Unicode. (Da mesma forma para a camada ": utf8".)

Local
Consulte "Unicode e UTF-8" em perllocale

Quando Unicode Será que Não Acontecer
Ainda existem muitos lugares onde Unicode (em alguma codificação ou outra) poderia ser dado como
argumentos ou recebidos como resultados, ou ambos em Perl, mas não é, apesar de Perl ter
maneiras extensas de entrada e saída em Unicode, e alguns outros "pontos de entrada" como o
Array @ARGV (que às vezes pode ser interpretado como UTF-8).

A seguir estão essas interfaces. Além disso, consulte "O" Bug Unicode ". Por tudo isso
interfaces Perl atualmente (a partir da v5.16.0) simplesmente assume strings de byte como argumentos
e resultados, ou cadeias de caracteres UTF-8 se o pragma de "codificação" (obsoleto) tiver sido usado.

Uma razão pela qual Perl não tenta resolver o papel do Unicode nessas situações
é que as respostas são altamente dependentes do sistema operacional e dos sistemas de arquivos.
Por exemplo, se os nomes dos arquivos podem estar em Unicode e exatamente em que tipo de codificação, é
não é exatamente um conceito portátil. Da mesma forma para "qx" e "sistema": quão bem será o
"interface de linha de comando" (e qual delas?) manipula Unicode?

· "Chdir", "chmod", "chown", "chroot", "exec", "link", "lstat", "mkdir", "renomear",
"rmdir", "stat", "symlink", "truncate", "unlink", "utime", "-X"

·% ENV

· "Glob" (também conhecido como "<*>")

· "Abrir", "opendir", "sysopen"

· "Qx" (também conhecido como operador de crase), "sistema"

· "Readdir", "readlink"

A "Unicode Erro"
O termo "bug Unicode" foi aplicado a uma inconsistência com os pontos de código no
Bloco "Latin-1 Supplement", ou seja, entre 128 e 255. Sem uma localidade especificada,
ao contrário de todos os outros personagens ou pontos de código, esses personagens podem ter diferentes
semântica dependendo das regras em vigor. (Caracteres cujos pontos de código estão acima de 255
forçar regras Unicode; enquanto as regras para caracteres ASCII são as mesmas em ambos
e regras Unicode.)

Nas regras Unicode, esses caracteres latinos superiores 1 são interpretados como pontos de código Unicode,
o que significa que eles têm a mesma semântica que os controles Latin-1 (ISO-8859-1) e C1.

Conforme explicado em "Regras ASCII versus regras Unicode", nas regras ASCII, elas são consideradas
para serem personagens não atribuídos.

Isso pode levar a resultados inesperados. Por exemplo, a semântica de uma string pode de repente
mudar se um ponto de código acima de 255 for anexado a ele, o que altera as regras de ASCII para
Unicode. Como exemplo, considere o seguinte programa e sua saída:

$ perl -le '
sem recurso 'unicode_strings';
$ s1 = "\ xC2";
$ s2 = "\ x {2660}";
para ($ s1, $ s2, $ s1. $ s2) {
imprimir / \ w / || 0;
}
'
0
0
1

Se não há "\ w" em "s1" nem em "s2", por que sua concatenação tem um?

Esta anomalia deriva da tentativa do Perl de não perturbar programas mais antigos que não usavam
Unicode, junto com o desejo de Perl de adicionar suporte a Unicode perfeitamente. Mas o resultado
acabou por não ser perfeito. (A propósito, você pode escolher ser avisado quando coisas como
isso acontecer. Consulte "codificação :: avisos".)

"use feature 'unicode_strings'" foi adicionado, começando em Perl v5.12, para resolver este
problema. Afeta estas coisas:

· Alterar o caso de um escalar, ou seja, usando "uc ()", "ucfirst ()", "lc ()" e
"lcfirst ()" ou "\ L", "\ U", "\ u" e "\ l" em contextos de aspas duplas, como regular
substituições de expressão.

Em "unicode_strings" começando em Perl 5.12.0, as regras Unicode são geralmente usadas.
Veja "lc" em perlfunc para detalhes sobre como isso funciona em combinação com vários outros
pragmas.

· Usando caseless ("/ i") correspondência de expressão regular.

A partir do Perl 5.14.0, as expressões regulares compiladas dentro do escopo do
"unicode_strings" usam regras Unicode mesmo quando executadas ou compiladas em regras regulares maiores
expressões fora do escopo.

· Combinar qualquer uma das várias propriedades em expressões regulares.

Essas propriedades são "\ b" (sem colchetes), "\ B" (sem colchetes), "\ s", "\ S", "\ w",
"\ W", e todas as classes de caracteres Posix exceto "[[: ascii:]]".

A partir do Perl 5.14.0, as expressões regulares compiladas dentro do escopo do
"unicode_strings" usam regras Unicode mesmo quando executadas ou compiladas em regras regulares maiores
expressões fora do escopo.

· Em "quotemeta" ou seu equivalente inline "\ Q".

A partir do Perl 5.16.0, regras de cotação consistentes são usadas dentro do escopo de
"unicode_strings", conforme descrito em "quotemeta" em perlfunc. Antes disso, ou fora
seu escopo, nenhum ponto de código acima de 127 é citado em strings codificadas UTF-8, mas em byte
strings codificadas, os pontos de código entre 128-255 estão sempre entre aspas.

Você pode ver acima que o efeito de "unicode_strings" aumentou em vários
Lançamentos Perl. (E o suporte do Perl para Unicode continua a melhorar; é melhor usar o
versão mais recente disponível para obter os resultados mais completos e precisos possíveis.)
Observe que "unicode_strings" é escolhido automaticamente se você "usar 5.012" ou superior.

Para Perls anteriores aos descritos acima, ou quando uma string é passada para uma função
fora do escopo de "unicode_strings", consulte a próxima seção.

Forçando Unicode in Perl (Ou Inabalável Unicode in Perl)
Às vezes (consulte "Quando o Unicode não acontece" ou "O" Bug Unicode ""), há situações
onde você simplesmente precisa forçar uma string de bytes em UTF-8 ou vice-versa. O padrão
O módulo Encode pode ser usado para isso, ou as chamadas de baixo nível "utf8 :: upgrade ($ bytestring)"
e "utf8 :: downgrade ($ utf8string [, FAIL_OK])".

Observe que "utf8 :: downgrade ()" pode falhar se a string contiver caracteres que não cabem
em um byte.

Chamar qualquer uma das funções em uma string que já está no estado desejado é um modo autônomo.

"Regras ASCII versus regras Unicode" fornece todas as maneiras que uma string é feita para usar Unicode
regras.

utilização Unicode in XS
Veja "Suporte Unicode" em perlguts para uma introdução ao Unicode no nível XS, e
"Suporte Unicode" em perlapi para os detalhes da API.

hacker Perl para trabalho on mais cedo Unicode versões (Por muito grave hackers apenas)
Por padrão, o Perl vem com a versão Unicode suportada mais recente embutida, mas o objetivo é
para permitir que você mude para usar qualquer um dos anteriores. No Perls v5.20 e v5.22, no entanto, o
a primeira versão utilizável é Unicode 5.1. Perl v5.18 é capaz de lidar com todos os anteriores
versões.

Baixe os arquivos na versão desejada do Unicode do site do Unicode
<http://www.unicode.org>). Eles devem substituir os arquivos existentes em lib / unicore no
Árvore de origem do Perl. Siga as instruções em README.perl nesse diretório para mudar alguns
de seus nomes, e então construir perl (veja INSTALAR).

portando código da perl-5.6.X
Perls começando em 5.8 tem um modelo Unicode diferente de 5.6. Em 5.6 o programador era
necessário para usar o pragma "utf8" para declarar que um determinado escopo deve lidar com
Dados Unicode e tinha que ter certeza de que apenas os dados Unicode estavam alcançando esse escopo. Se vocês
tem código que está funcionando com 5.6, você precisará de alguns dos seguintes ajustes para
seu código. Os exemplos são escritos de forma que o código continue a funcionar em 5.6, então
você deve estar seguro para testá-los.

· Um identificador de arquivo que deve ler ou gravar UTF-8

if ($]> 5.008) {
binmode $ fh, ": codificação (utf8)";
}

· Um escalar que será passado para alguma extensão

Seja "Compress :: Zlib", "Apache :: Request" ou qualquer extensão que não tenha menção de
Unicode na página de manual, você precisa ter certeza de que o sinalizador UTF8 foi removido. Observação
que no momento da redação deste artigo (janeiro de 2012), os módulos mencionados não são
Compatível com UTF-8. Verifique a documentação para verificar se isso ainda é verdade.

if ($]> 5.008) {
requerem Encode;
$ val = Encode :: encode_utf8 ($ val); # fazer octetos
}

· Um escalar que recebemos de uma extensão

Se você acredita que o escalar retorna como UTF-8, você provavelmente desejará o sinalizador UTF8
restaurado:

if ($]> 5.008) {
requerem Encode;
$ val = Encode :: decode_utf8 ($ val);
}

· Mesma coisa, se você tem certeza que é UTF-8

if ($]> 5.008) {
requerem Encode;
Codificar :: _ utf8_on ($ val);
}

· Um wrapper para DBI "fetchrow_array" e "fetchrow_hashref"

Quando o banco de dados contém apenas UTF-8, uma função ou método de wrapper é uma maneira conveniente
para substituir todas as chamadas "fetchrow_array" e "fetchrow_hashref". Uma função wrapper
também tornará mais fácil se adaptar a melhorias futuras em seu driver de banco de dados. Observação
que, no momento da redação deste artigo (janeiro de 2012), o DBI não tinha uma forma padronizada de
lidar com dados UTF-8. Por favor, verifique a documentação DBI para verificar se ainda é
verdadeiro.

sub-busca {
# $ o que é um de fetchrow_ {array, hashref}
meu ($ self, $ sth, $ what) = @_;
if ($] <5.008) {
return $ sth -> $ what;
Else {}
requerem Encode;
if (quererray) {
meu @arr = $ sth -> $ what;
para (@arr) {
definido && / [^ \ 000- \ 177] / && Encode :: _ utf8_on ($ _);
}
retornar @arr;
Else {}
meu $ ret = $ sth -> $ what;
if (ref $ ret) {
para meu $ k (chaves% $ ret) {
definido
&& / [^ \ 000- \ 177] /
&& Encode :: _ utf8_on ($ _) para $ ret -> {$ k};
}
return $ ret;
Else {}
definido && / [^ \ 000- \ 177] / && Encode :: _ utf8_on ($ _) para $ ret;
return $ ret;
}
}
}
}

· Um grande escalar que você sabe que só pode conter ASCII

Escalares que contêm apenas ASCII e são marcados como UTF-8 às vezes são uma chatice para o seu
programa. Se você reconhecer tal situação, basta remover a sinalização UTF8:

utf8 :: downgrade ($ val) if $]> 5.008;

Use perlunicode online usando serviços onworks.net