POD2-IT

 view release on metacpan or  search on metacpan

IT/perlunicode.pod  view on Meta::CPAN

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

IT/perlunicode.pod  view on Meta::CPAN

=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).

IT/perlunicode.pod  view on Meta::CPAN

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

IT/perluniintro.pod  view on Meta::CPAN

inglese, NdT) o I<serializzati> in qualche modo. Unicode definisce
svariate I<forme di codifica dei caratteri>, di cui I<UTF-8> E<egrave>
forse la piE<ugrave> nota.  UTF-8 E<egrave> una codifica a lunghezza
variabile che rappresenta i caratteri Unicode come sequenze da 1 a 6
byte (se ci si limita ai caratteri attualmente definiti ne bastano
4). Altre codifiche sono UTF-16 e UTF-32, e le loro varianti
big-endian e little-endian (UTF-8 E<egrave> invariante). Lo standard
ISO/IEC 10646 definisce le forme UCS-2 e UCS-4.

Per ulteriori informazioni sulle codifiche -- ad esempio, per sapere
cosa sono i I<surrogati> e i I<byte order marks> (BOM) -- leggete
L<perlunicode>.

=head2 Il supporto Unicode in Perl

A partire da Perl 5.6.0, Perl ha avuto la capacitE<agrave> di gestire
nativamente Unicode. Ad ogni modo, Perl 5.8.0 E<egrave> la minima
versione raccomandata per lavorare seriamente con Unicode. La versione
di manutenzione 5.6.1 ha corretto molti dei problemi della prima
implementazione di Unicode, ma ad esempio le espressioni regolari
ancora non funzionano con Unicode nella 5.6.1.