1 / 16

Il trattamento informatico di dati multilinguistici

Il trattamento informatico di dati multilinguistici. Federico Greselin Dipartimento di Studi sull’Asia Orientale Venezia. PARTE I: ASPETTI GENERALI DEL PROBLEMA.

moesha
Download Presentation

Il trattamento informatico di dati multilinguistici

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Il trattamento informaticodi dati multilinguistici Federico Greselin Dipartimento di Studi sull’Asia Orientale Venezia

  2. PARTE I: ASPETTI GENERALI DEL PROBLEMA • Nei sistemi operativi non c'è corrispondenza univoca tra collocazione nel codice e caratteri di testo, ovvero lo stesso codice può portare a glifi diversi, diverse lettere, addirittura diversi significati In sostanza, le diverse lingue del mondo, almeno fino ad un determinato stadio dell'evoluzione dell'informatica, si sono dovute servire degli stessi codici per diversi alfabeti o sistemi di rappresentazione grafica delle lingue stesse In rete si trovano vari documenti che spiegano l'evoluzione del processo di sviluppo conosciuto da questo particolare aspetto dell'informatica. Fabio Vitali dell'Università di Bologna fornisce, in http://vitali.web.cs.unibo.it/twiki/pub/Main/EnBeg/04-caratteribn.pdf un documento molto sintetico e tecnico sull'utilizzazione delle varie codifiche, sul processo di ampiamento degli spazi-codice dedicati al testo e sulle differenze tra i vari sistemi in uso…

  3. …tuttavia le informazioni di questo studioso vanno prese con le molle. Sussiste una certa confusione, di fatto, su quello che è il reale oggetto del contendere, come si suol dire, ovvero su cosa sia realmente una stringa di testo e di cosa occorra tener conto nella gestione informatica di documenti in lingue diverse. • Per esempio, Vitali afferma che: • "Il carattere è l’entità atomica di un testo scritto in una lingua umana. • In alfabeti diversi i caratteri hanno particolarità diverse: • Negli alfabeti di derivazione greca (greco, latino e cirillico), esiste la distinzione tra maiuscole e minuscole, ignota altrove • Negli alfabeti di derivazione latina si sono inventati segni particolari sulle lettere per soddisfare le esigenze delle varie lingue che lo usano (accenti, segni diacritici, ecc.). • In ebraico, le vocali sono modificatori grafici della forma delle consonanti • In arabo, la giustapposizione di lettere diverse nella parola provoca una differenziazione della forma delle lettere stesse. • In cinese, è possibile creare nuovi caratteri come composizione di altri caratteri esistenti" • Gestione informatica di stringhe di testo e di documenti multilingue Una stringa di testo è un oggetto come gli altri, che ha sì determinbate caratteristiche, ma che sostanzialmente consiste in una serie di 1 e 0 in una delle aree di memoria di un computer.

  4. Una stringa di testo è un oggetto come gli altri, che ha sì determinbate caratteristiche, ma che sostanzialmente consiste in una serie di 1 e 0 in una delle aree di memoria di un computer. A livello informatico, una lingua è una proprietà specifica riservata ad una stringa di testo, anche se non in maniera esclusiva. Ad esempio, la lingua serve anche per definire la localizzazione di un sistema operativo, di un applicativo ecc. In questo senso, la lingua serve a riassumere una serie di formati attribuibili ad oggetti e comportamenti anche molto diversi tra loro, quali il formato della data, l'uso di sistemi di misurazione, l'uso di un dato correttore ortografico ecc. La lingua, intesa come localizzazione, è importante anche per l'interfaccia (uso del colore, sviluppo dei testi da destra a sinistra ecc. ecc.) Inizialmente la gestione della proprietà "lingua" di una stringa di testo era affidata ai singoli applicativi, mentre il sistema operativo si incaricava di assegnare inizialmente una codifica a tutte le stringhe di testo attive. Ecco dunque che le varie "codifiche" disponibili per una pagina sul Web si riferiscono al modo in cui un applicativo (il browser, nel caso specifico), attribuisce determinati glifi e/o caratteri a unità di codice significative.

  5. Quindi il browser può trattare stringhe di testo in lingue diverse, ovvero può disporre di più codifiche per regolare la visualizzazione (ovvero il comportamento) di una stessa stringa di testo. Ad un altro livello, può sussistere un certo livello di incompatibilità tra applicativi e localizzazione di un sistema operativo. Ad esempio, un applicativo nato per una versione localizzata di Windows 3.1 può non essere gestibile in un'altra versione dato che il sistema può gestire unicamente una sola localizzazione — il che significica che per gli oggetti di sistema contenenti stringhe di testo è ammessa una sola codifica…

  6. Ecco dunque che la stessa finestra di dialogo nello stesso applicativo viene visualizzata in diversi modi, dei quali solo uno - quello corrispondente alla localizzazione nativa - sarà corretto localizzazione Italia: le stringhe di testo vengono rese con uno dei set ANSI disponibili per le codifiche Latin localizzazione Repubblica Popolare Cinese: le stringhe di testo vengono rese secondo la codifica dbcs Guobiao

  7. I sistemi operativi si sono in pratica evoluti da un sistema ad una sola lingua (l'inglese), priva di segni diacritici, che poteva contare su un insieme limitato di caratteri (sistema ASCII, a 7 bit), ad un sistema che consentisse una localizzazione a livello di stringhe di testo, oltre che delle proprietà generiche (data, ora ecc.), a seconda delle esigenze dell'utente. Il sistema ANSI, a 8 bit, permette un certo grado di localizzazione utilizzando la pate superiore della tabella di 255+1 spazi destinati alle stringhe di testo. La metà inferiore è uguale alla tabella ASCII. Le lingue cosiddette alfabetiche utilizzavano il sistema ANSI, così i sistemi operativi permettavano la differenziazione tra i vari sistemi di gestione dei diacritici per le lingue europee basate sui caratteri latini (italiano, francese, tedesco, svedese, ungherese ecc.) e addirittura di gestione degli stessi glifi tra queste lingue e le altre (russo, greco, serbo ecc.). Una visita alla pagina internazionale di Yahoo può rendere l'idea dell'ampiezza del problema: http://world.yahoo.com/

  8. Le lingue non alfabetiche, quelle che cioè basano i loro sistemi di scrittura su un numero di caratteri e/o un trattamento dei glifi molto più esteso che non le lingue europee, potevano comunque utilizzare la tabella ANSI, gestendo i caratteri come composti di due byte, da cui l'acronimo DBCS (= Double Byte Character System). In sostanza, i sistemi operativi rimanevano sistemi che gestivano le stringhe di testo destinando un byte per carattere, solo che alcuni sistemi abbinavano certi caratteri/byte per costruirne di diversi, la cui visualizzazione presupponeva anche l'impiego di font particolari. Da qui le varie varianti di DOS per le varie lingue arabo, cinese RPC, cinese Taiwan, giapponese, hindi, thai ecc., in cui in pratica non erano ammessi caratteri accentati, ma solo le lettere latine dello standard ASCII, e, dal 1990, le varie versioni di Windows. Da qui le varie varianti di DOS per le varie lingue arabo, cinese RPC, cinese Taiwan, giapponese, hindi, thai ecc., in cui in pratica non erano ammessi caratteri accentati, ma solo le lettere latine dello standard ASCII, e, dal 1990, le varie versioni di Windows, del Mac OS ecc.

  9. Contrariamente a quanto prospettato, la possibilità di gestire una sola lingua per volta non è sufficiente L'uso delle codifiche ANSI, pur ampliando notevolmente le lingue in grado di gestire dati digitali, limitava ad una singola lingua le possibilità di gestione dell'OS. Tuttavia è chiaro come sia necessario gestire talvolta più lingue contemporaneamente: questo è evidente nel mondo dell'editoria. È impensabile infatti che un applicativo di Desktop Publishing riesca a gestire una sola lingua o un set limitato di lingue occidentali: eppure, chi lavorava con applicativi prestigiosi un tempo come Framemaker, Quarkpress o Ventura Publisher, in vari ambienti operativi, si trovava di fatto a gestire solo le lingue occidentali, giocando sulla possibilità di cambiare font e di attribuire determinate proprietà linguistiche a singole sottostringhe e/o paragrafi. Alcuni espedienti consentivano di bypassare questa difficoltà che tuttavia persisteva a livello di sistema operativo.

  10. Il Mac OS addirittura elevava uno di questi espedienti a livello di strumento di sistema, addirittura permettendo, negli applicativi predisposti, la coesistenza tra stringhe caratterizzate da proprietà di tipo "lingua" diverse. WorldScript determinò in sostanza il successo del Macintosh in alcuni ambienti professionali (editoria, stampa periodica, mondo accademico ecc.) appunto grazie alla capacità di gestire insieme lingue alfabetiche e non, facendole coesistere addirittura nella stessa pagina. In pratica all'interno di una stessa stringa di testo era possibile dotare sottostringhe di diversi attributi linguistici, in pratica ogni sottostringa veniva "taggata" in maniera specifica. Questa soluzione non riuscì però ad imporsi anche in ambienti operativi diversi da quelli che caratterizzavano i prodotti Apple. In ambiente Windows si poteva optare per sistemi operativi localizzati sulla lingua prevalente, per poi affidarsi ad applicativi di terze parti (Universe per varie lingue, Twinbridge pwer il cinese e il giapponese ecc.) per la gestione dei codici di identificazione delle stringhe di testo. Chi vi parla ha addirittura pubblicato un libretto (La versione cinese di Windows 3.0 ™. Ottimizzazione dell'ambiente a fini sinologici: installazione e guida all'uso delle più note applicazioni, Venezia, Cafoscarina, 1992) per spiegare come la versione taiwanese di Windows 3.0 potesse essere attrezzata ed utilizzata estesamente per la gestione di testi che contenessero insieme stringhe scritte in cinese non semplificato (codifica Big5) e stringhe scritte in lingue occidentali

  11. Se anche questi sistemi "sporchi" di gestire più lingue avevano una loro funzionalità, anche piuttosto elevata, e quindi permettevano la preparazione di documenti di qualità professionale per la stampa, rimaneva insoluto il problema più grave… • Com'è possibile gestire dati testuali "puri", ovvero non formattati e non formattabili riferiti a lingue diverse? Da quanto fin qui detto appare chiaro che, lavorando di "tag" e di formattazione è certo possibile dotare le stringhe di testo che formano un documento di diverse proprietà linguistiche e addirittura farle coesistere in uno stesso sistema operativo. Nella gestione di basi di dati non è invece possibile farlo in un sistema basato sulle codifiche ANSI: così, un database di dati contenenti testo non potrà comprendere nella stessa stringa di testo (ovvero in un campo) sottostringhe a diversa codifica. I sistemi di catalogazione delle grandi biblioteche sinologiche e nipponistiche si basano ancora prevalentemente sull'implementazione di codifiche localizzate DBCS: pur trattando prevalentemente testi appunto cinesi e giapponesi, questa scelta, frutto di varie considerazioni tecniche, comporta alcune oggettive difficoltà e l'insorgere di problemi non facilmente risolvibili

  12. La soluzione di questo problema cruciale passa sostanzialmente attraverso due passi, tra loro collegati: a. È necessario che tutte le stringhe di testo vengano codificate in modo univoco e che questo modo sia implementato a livello di sistema b. Occorre che la nuova codifica consenta uno spazio di codice autonomo per ogni glifo appartenente a una qualsiasi lingua del globo, o quasi ASCII - 7 bit: in teoria 128 spazi/codice per gestire il testo ANSI - 8 bit: in teoria 256 spazi/codice per gestire il testo DBCS - 8 + 8 bit: in pratica circa 16.000 caratteri derivati dalle combinazioni possibili Codifiche a 16 bit ed oltre: da oltre 60.000 spazi/codice a milioni di caratteri possibili

  13. Citiamo ancora dal documento di Fabio Vitali: Unicode e ISO/IEC 10646 (1) Il compito di creare uno standard unico è stato affrontato indipendentemente da due commissioni di standard, Unicode e ISO/IEC 10646. Le due commissioni, una industriale, l'altra espressione governativa, hanno lavorato indipendentemente per le prime versioni, salvo poi convergere Attualmente la versione 3.0 di Unicode e la versione ISO/IEC 10646-1:2000 associano gli stessi codici agli stessi caratteri. Questo però non è garantito nel futuro. Il primo sistema operativo ad implementare Unicode fu Windows NT, nel 1994, anche se i primi applicativi non specializzati a gestire in qualche modo stringhe di testo a 16 bit furono alcuni esponenti della versione 97 di Microsoft Office, segnatamente Word e, in qualche modo, Access. Dalla metà degli anni Novanta, comunque, tutte le grandi software house hanno operato nella direzione di dedicare 16 bit ad ogni singolo carattere; questo è avvenuto sia a livello di OS (Windows NT, 2000 e XP sono del tutto predisposti ad Unicode, 98 e Me lo erano solo in parte. Le ultime versioni di Linux e Unix, Mac SystemX sono pure compatibili completamente), sia di applicativi.

  14. Tra gli applicativi di rilievo che possono gestire Unicode, oltre ai vari linguaggi di programmazione e authoring tools (C++, VisualNet, VBA ecc.), possiamo notare che tutti i grandi sistemi DBMS da tempo ammettono la nuova codifica (Novell, Oracle, SQL). Unicode permette di fatto, anche solo nella sua implementazione a 16 bit, la gestione insimultanea di molte lingue diverse. Sussiste un rapporto univoco molto stretto tra area di codice, glifo, proprietà e caratteristiche di comportamento riferite ad un singolo carattere. Ad esempio, per i caratteri compresi nell'area CJK, non è previsto l'impiego di font a spaziatura variabile, mentre per quelli nell'area Arabic, è previsto l'impiego di font che cambiano sostanzialmente la morfologia dei glifi e la presenza di caratteri (diacritici) a spazio zero. Inoltre, nei dati disponibili nei vari chart è possibile trovare riferimenti a codifiche DBCS preesistenti, per consentire una facile indicizzazione a scopi di compatibilità Una visita al sito del Consorzio Unicode può far capire meglio la vastità dei problemi che sono già stati risolti e l'importanza dell'adozione a livello informatico di una codifica unica http://www.unicode.org

  15. PARTE I: ASPETTI SPECIFICI E PRATICI • A lingue diverse, in particolar modo se le lingue hanno sistemi di scrittura sostanzialmente differenti, corrispondono anche rese diverse nella pagina stampata, com'è naturale, ma anche nella pagina Web Esempi: Sito di commercio elettronico http://www.dangdang.com/ http://www.amazon.com Quotidiani on-line http://www.people.com.cn/GB/index.html http://www.repubblica.it

  16. La gestione di dati multilinguistici implica sia un diverso modo di rapportarsi ai diversi applicativi, sia l'apertura di nuovi campi d'intervento, per gli informatici e gli operatori culturali in genere • Basi di dati: • Gestione di bibliografie per gli studi orientali (vedi: http://venus.unive.it/dsao//webpages/docs/corsi/informatica/dbcina03.zip e http://venus.unive.it/dsao//webpages/docs/corsi/informatica/dbcina-manuale2004.pdf. • Uno schedario elettronico del cinema cinese • Il dizionario analitico dei sinonimi cinesi (prof. Harbsmeyer) Applicativi orizzontali: i vantaggi di ambienti completamente multilingue.

More Related