view release on metacpan or  search on metacpan

IT/perlunicode.pod  view on Meta::CPAN

=head1 NOME

perlunicode - Supporto Unicode in Perl

=head1 DESCRIZIONE

=head2 Avvertenze Importanti

Un supporto completo Unicode richiede una gran quantitE<agrave> di
lavoro.  Sebbene Perl non implementi lo standard Unicode e i rapporti
tecnici allegati da parte a parte, Perl fornisce comunque una gran
quantitE<agrave> di funzionalitE<agrave> Unicode.

=over 4

=item Strati di Input e Output

Perl sa che un filehandle usa la codifica Unicode interna (UTF-8, o
UTF-EBCDIC su piattaforme EBCDIC) se il filehandle viene aperto con lo
strato C<:utf8>. Altre codifiche possono essere convertite alla
codifica interna Perl in lettura (o viceversa in scrittura) usando lo
strato C<:encoding(...)>. Leggete L<open>.

Per indicare che il sorgente stesso dello script E<egrave> in una
particolare codifica, usate L<encoding>.

=item Espressioni Regolari

Il compilatore delle espressioni regolari produce istruzioni
polimorfiche. Ovvero, l'espressione si adatta ai dati e commuta
automaticamente allo schema di caratteri Unicode quando viene usata su
dati Unicode -- o viceversa usa lo schema tradizionale a byte quando
viene usata su dati a byte.

=item C<use utf8> E<egrave> ancora necessario per usare UTF-8/UTF-EBCDIC negli script

Per compatibilitE<agrave>, la direttiva C<use utf8> deve essere
inclusa esplicitamente per attivare il riconoscimento di stringhe in
UTF-8 nei sorgenti degli script (nelle costanti stringa e espressioni
regolari, o nei nomi degli identificatori) sulle macchine ASCII,
ovvero il riconoscimento di UTF-EBCDIC sulle macchine EBCDIC. B<<
Questi sono i soli casi in cui E<egrave> necessario un esplicito C<use
utf8> >>. Cfr. L<utf8>.

Potete anche usare la direttiva C<encoding> per cambiare la codifica
di default per i dati nei vostri script; cfr. L<encoding>.

=item gli script marcati con BOM o codificati in UTF-16 sono riconosciuti automaticamente

Se uno script Perl comincia con il BOM Unicode (codificato in
UTF-16LE, UTF16-BE, o UTF-8), oppure sembra essere codificato in
UTF-16 (con i byte in qualunque ordine) senza BOM, perl
interpreterE<agrave> correttamente lo script in Unicode. (UTF-8 senza
BOM non è efficacemente distinguibile da ISO 8859-1 o altre codifiche
a 8 bit).

=item C<use encoding> E<egrave> necessario per interpretare correttamente le stringhe di byte non Latin-1

Per default, c'E<egrave> una asimmetria fondamentale nel modello
Unicode di Perl: la conversione implicita da stringhe di byte a
stringhe di caratteri Unicode assume che la codifica di partenza sia
I<ISO 8859-1 (Latin-1)>, ma le stringhe di caratteri Unicode vengono
convertite in stringhe di byte usando UTF-8. Questo succede
perchE<eacute> i primi 256 code point di Unicode concordano (quasi per
caso) con Latin-1.

Se volete che le stringhe di byte siano interpretate come UTF-8, usate
la direttiva C<encoding>:

    use encoding 'utf8';

Cfr. L</"Semantica a byte e a caratteri"> per ulteriori dettagli.

=back

=head2 Semantica a byte e a caratteri

A partire dalla versione 5.6, la rappresentazione interna delle
stringhe in Perl E<egrave> basata su caratteri "larghi" (nel senso che
possono occupare piE<ugrave> di un byte).

Nel futuro, si potrE<agrave> supporre che le operazioni a livello di
Perl lavorino su caratteri anzichE<eacute> byte.

Comunque, come misura di compatiblitE<agrave> temporanea, Perl cerca
di fornire un percorso sicuro di migrazione per i vostri programmi da
semantica a byte a semantica a caratteri. Nel caso di operazioni per
le quali Perl puE<ograve> decidere senza ambiguitE<agrave> che i dati
in ingresso sono caratteri, viene usata la semantica a caratteri. Nel
caso di operazioni per le quali questa decisione non puE<ograve>
essere effettuata senza ulteriori informazioni da parte dell'utente,
Perl decide per la compatibilitE<agrave> e sceglie la semantica a
byte.

Questo comportamento mantiene la compatiblitE<agrave> con versioni
precedenti del Perl, che usavano la semantica a byte solo nel caso in
cui nessuno degli input del programma erano indicati come sorgenti di
caratteri Unicode. Questi dati possono provenire da filehandle, da
chiamate a programmi esterni, da informazioni fornite dal sistema (ad
esempio C<%ENV>), o da costanti nel sorgente.

La direttiva C<bytes> forzerE<agrave> sempre, indipendentemente dalla
piattaforma, la semantica a byte in un particolare scope
lessicale. Cfr. L<bytes>.

La direttiva C<utf8> E<egrave> principalmente un sistema di
compatibilitE<agrave> che attiva il riconoscimenti di costanti
UTF-(8|EBCDIC) da parte del parser. Notate che questa direttiva
E<egrave> necessaria solo finchE<eacute> Perl assume una semantica a
byte; quando la semantica a caratteri diventerE<agrave> quella
predefinita, questa direttiva potrE<agrave> non avere piE<ugrave>
effetto. Cfr. L<utf8>.

Tranne dove viene detto esplicitamente, gli operatori Perl usano la

IT/perlunicode.pod  view on Meta::CPAN

astratti. Per usare questi numeri, sono necessarie varie codifiche.

=over 4

=item *

UTF-8

UTF-8 E<egrave> una codifica a lunghezza variabile (da 1 a 6 byte, per
tutti i caratteri attualmente allocati ne sono sufficienti 4),
indipendente dall'ordinamento dei byte. La codifica UTF-8 E<egrave>
trasparente se ci si limita ad ASCII (e qui si intende davvero ASCII,
7 bit, non una qualche altra codifica a 8 bit).

La tabella seguente E<egrave> presa da Unicode 3.2:

     Code Point         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       ******* mal formato *******
   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

Notate il C<A0..BF> per C<U+0800..U+0FFF>, il C<80..9F> per
C<U+D000...U+D7FF>, il C<90..BF> per C<U+10000..U+3FFFF>, e il
C<80...8F> per C<U+100000..U+10FFFF>.  Questi "buchi" sono causati dal
fatto che UTF-8 corretto evita le codifiche non minime: tecnicamente
E<egrave> possibile codificare in UTF-8 un singolo code point in
piE<ugrave> di un modo, ma ciE<ograve> E<egrave> espressamente
proibito, e bisogna sempre usare la codifica piE<ugrave> breve
possibile. Per cui questo E<egrave> quello che fa Perl.

Un altro modo di vedere la codifica E<egrave> a livello di bit:

         Code Point              1o byte   2o byte   3o byte   4o byte

                    0aaaaaaa     0aaaaaaa
            00000bbbbbaaaaaa     110bbbbb  10aaaaaa
            ccccbbbbbbaaaaaa     1110cccc  10bbbbbb  10aaaaaa
  00000dddccccccbbbbbbaaaaaa     11110ddd  10cccccc  10bbbbbb  10aaaaaa

Come potete vedere, i byte seguenti cominciano tutti con C<10>, e i
bit iniziali del primo byte indicano quanti byte fanno parte della
codifica del carattere.

=item *

UTF-EBCDIC

Come UTF-8 ma "EBCDIC-safe", allo stesso modo che UTF-8 E<egrave>
ASCII-safe.

=item *

UTF-16, UTF-16BE, UTF-16LE, surrogati, e i BOM (Byte Order Mark)

Quello che segue E<egrave> soprattutto per riferimento e conoscenza generale
di Unicode; Perl non usa questi costrutti internamente.

UTF-16 E<egrave> una codifica a 2 o 4 byte. I code point
C<U+0000..U+FFFF> sono codificati in una singola unitE<agrave> da 16
bit, e i code point C<U+10000..U+10FFFF> sono codificati in due
unitE<agrave> da 16 bit.  Quest'ultimo caso usa i I<surrogati>, con la
prima unitE<agrave> chiamata I<surrogato alto> ("high surrogate" NdT)
e la seconda chiamata I<surrogato basso> ("low surrogate" NdT).

I surrogati sono code point lasciati da parte per codificare
l'intervallo di code point C<U+10000..U+10FFFF> in coppie di
unitE<agrave> da 16 bit. I I<surrogati alti> sono nell'intervallo
C<U+D800..U+DBFF>, e i I<surrogati bassi> sono nell'intervallo
C<U+DC00..U+DFFF>.  La codifica con i surrogati E<egrave>

	$alto  = ($uni - 0x10000) / 0x400 + 0xD800;
	$basso = ($uni - 0x10000) % 0x400 + 0xDC00;

e la decodifica E<egrave>

	$uni = 0x10000 + ($alto - 0xD800) * 0x400 + ($basso - 0xDC00);

Se provate a generare surrogati (ad esempio usando C<chr()>),
otterrete un avvertimento se gli avvertimenti sono abilitati,
poichE<eacute> tali code point non sono validi per caratteri Unicode.

Avendo unitE<agrave> lunghe 16 bit, UTF-16 dipende dall'ordinamento
dei byte. UTF-16 di per sE<eacute> puE<ograve> essere usato in
memoria, ma se deve essere trasmesso o salvato su file bisogna
scegliere tra UTF-16BE (big-endian) e UTF-16LE (little-endian).

Questo introduce un altro problema: cosa succede se sapete solo che i
dati sono in UTF-16, ma non sapete in che ordine? I Byte Order Mark, o
BOM, sono una soluzione. Un carattere speciale E<egrave> stato scelto in
Unicode per essere usato come Byte Order Mark: il carattere con code
point C<U+FEFF> E<egrave> il BOM.

Il trucco E<egrave> che se leggete un BOM, saprete l'ordinamento dei
byte, visto che se E<egrave> stato scritto su una piattaforma
big-endian, leggerete i due byte C<0xFE 0xFF>, ma se E<egrave> stato
scritto su una piattaforma little-endian leggerete i due byte C<0xFF
0xFE>. (E se la piattaforma di partenza scriveva in UTF-8, leggerete i
tre byte C<0xEF 0xBB 0xBF>).

Questo trucco funziona perchE<eacute> il code point C<U+FFFE>
E<egrave> garantito non essere un carattere valido, per cui la
sequenza di byte C<0xFF 0xFE> E<egrave> senza ambiguitE<agrave> "BOM
rappresentato in forma little-endian" e non puE<ograve> essere
"C<U+FFFE> rappresentato in forma big-endian".

=item *

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

La famiglia UTF-32 E<egrave> molto simile a quella UTF-16, tranne per
il fatto che le unitE<agrave> sono di 32 bit, e di conseguenza non
serve il metodo dei surrogati. Le segnature BOM saranno C<0x00 0x00
0xFE 0xFF> per BE e C<0xFF 0xFE 0x00 0x00> per LE.

=item *

UCS-2, UCS-4

Codifiche definite dallo standard ISO 10646. UCS-2 E<egrave> una
codifica a 16 bit. A differenza di UTF-16, UCS-2 non puE<ograve>
essere esteso oltre C<U+FFFF>, poichE<eacute> non usa i
surrogati. UCS-4 E<egrave> una codifica a 32 bit, funzionalmente
identica a UTF-32.

=item *

UTF-7

Una codifica a 7 bit (l'ottavo bit E<egrave> sempre a 0), utile quando
il sistema di trasferimento o immagazzinamento non gestisce bene dati
a 8 bit. E<Egrave> definito dalla RFC 2152.

=back

=head2 Implicazioni di sicurezza di Unicode

=over 4

=item *

UTF-8 malformato

Sfortunatamente, la specifica di UTF-8 lascia un po' di spazio
all'interpretazione su quanti byte di output codificato si debbano
generare per un dato carattere Unicode di input. Strettamente
parlando, dovrebbe essere generata la sequenza piE<ugrave> breve
possibile, poichE<eacute> altrimenti c'E<egrave> la
possibilitE<agrave> di overflow del buffer di input dal lato di
lettura di una connessione UTF-8. Perl genera sempre la sequenza
piE<ugrave> breve, e con gli avvertimenti attivati Perl vi
avvertirE<agrave> nel caso di UTF-8 a lunghezza non minima assieme ad
altre malformazioni, come l'uso di surrogati, che non sono davvero
code point Unicode.

=item *

Le espressioni regolari si comportano in maniera leggermente
differente se applicate a stringhe di byte o a stringhe di caratteri
(Unicode). Ad esempio, la classe "caratteri di parola" C<\w>
funzionerE<agrave> in modo diverso nei due casi.

Nel primo caso, l'insieme di caratteri di C<\w> E<egrave> piuttosto
ristretto: l'insieme di default di caratteri alfabetici, cifre, e il
"C<_>" -- oppure, se state usando un "locale" (cfr. L<perllocale>),
C<\w> potrebbe contenere alcune altre lettere a seconda della vostra
lingua e nazione.

Nel secondo caso, l'insieme di caratteri di C<\w> E<egrave> molto,
molto piE<ugrave> esteso. La cosa piE<ugrave> importante E<egrave>
che, anche limitatamente ai primi 256 caratteri, probabilmente
includerE<agrave> caratteri diversi: a differenza della maggior parte
dei "locale", che sono specifici di una lingua e una nazione, Unicode