Newsgroup: it.comp.appl.access
Titolo: Compressione Unicode

Nei campi testo delle tabelle la Compressione Unicode serve a qualcosa?
L'help fa un grande giro di parole ma se ho capito bene, per i normali 
caratteri alfanumerici è esattamente la stessa cosa mettere Si o No. 
Sbaglio?
-- 
Ciao, Sandrobi


Sě serve perchč comprime i record...ma non tutti. Leggi qui:
http://office.microsoft.com/it-it/access/HP052604161040.aspx
Ciao, Carlo 

 
http://office.microsoft.com/it-it/access/HP052604161040.aspx
Dimmi allora cosa vuol dire questa frase:
"Poiché il primo byte di un carattere latino (ovvero un carattere di una 
lingua europea occidentale come l'inglese, l'italiano o il tedesco) è 0, la 
rappresentazione dei caratteri Unicode non ha effetto sulla quantità di 
spazio richiesta per la memorizzazione dei dati compressi che consistano 
esclusivamente di caratteri latini."
Per i caratteri latini riduce lo spazio o no?
Sandrobi 

 ha scritto nel messaggio 
news:493ae40a$0$40305$4faf...@reader5.news.tin.it...

(IMHO) è semplice ...ma per capirlo bisogna approfondire l'unicode. La 
rappresentazione unicode anzichè usare un byte (otto bit) ne usa due e 
questo gli permette
di supportare 65.536 caratteri anzichè 256.
Già solo questo aspetto ti fa ben capire che per scrivere "sandrobi" in 
unicode occorrerebbero il doppio di byte.
E tanti ne occorerebbero senza la compressione unicode, la quale, nel caso 
dei caratteri latini che hanno sempre lo zero davanti, "comprime" appunto i 
due byte in uno, non considerando lo zero.
Insomma con la compressione unicode impostata a sì, benefici di 65.536 
caratteri pur "consumando" un solo byte (otto bit) per carattere.
Chi usa la compressione unicode con altri alfabeti (per esempio il cirillico 
o l'ebraico o l'arabo) non si avvantaggia molto di questa caratteristica 
perchè, per esempio, il primo byte inizia con 110.
Pur tuttavia l'unicode ti permette di localizzare il tuo db in quasi tutte 
le lingue potendo rappresentare (con due byte) praticamente tutti i 
caratteri.
Dimmi che mi sono capito....
Ciao, Carlo 

 ha scritto nel 
messaggio news:ghg288$btg$1...@tdi.cu.mi.it...

Ti ringrazio per la spiegazione che sicuramente mi arricchisce di qualche 
elemento in più ... "purtuttavia" non è per essere pignoli ma leggere che 
"...la rappresentazione dei caratteri Unicode non ha effetto sulla quantità 
di  spazio richiesta per la memorizzazione dei dati compressi che consistano 
esclusivamente di caratteri latini." che diavolo vuol dire? O è una cattiva 
traduzione o una cattiva spiegazione! specie se l'autore voleva dire: "se 
usi caratteri latini metti sempre SI che risparmi la meta di spazio di 
memorizzazione". e poi doveva anche spiegare quale è l'utilità di prevedere 
di impostare a NO la compressione: c'è forse un aspetto negativo non detto, 
tipo un rallentamento dei processi? altrimenti perché prevedere un'opzione 
per chiedermi se la benzina voglio pagarla per intero o a metà prezzo?
Scusa lo sfogo, ma leggere e rileggere una pagina di help senza poter alla 
fine capire cosa è meglio fare, non è il massimo!
Ciao, Sandrobi 

 ha scritto nel messaggio 
news:493ee09e$0$41664$4faf...@reader4.news.tin.it...

A volte le parole scritte sono difficili da comprendere...ma (imho) non in 
questo caso.
Le parole chiave da sottolineare sono due: "rappresentazione" e 
"memorizzazione dei dati COMPRESSI".
La memorizzazione dei dati COMPRESSI (compressione = vero) non ha effetto 
sulla quantità di spazio richiesto se i dati sono esclusivamente in 
caratteri latini e sono "rappresentati" in unicode. Tutto ciò è possibile, 
uno, perchè si usa l'unicode per la rappresentazione dei caratteri e due, 
perchè si usa la compressione.
Lo spazio richiesto non varia perchè la compressione (impostata a sì) viene 
attivata al momento della memorizzazione e "scompattata" al momento della 
visualizzazione. I dati memorizzati sono già compressi...quello è lo spazio 
occupato.
Un db dalla versione 2000 in poi occupa lo stesso spazio di un db 97, se 
scritto in caratteri latini, e non il doppio come ci si aspetterebbe a causa 
dell'unicode (due byte per carattere), ma grazie alla compressione.
Per capirlo ci si potrebbe porre una domanda come questa:
se il db è scritto in cirillico ci si avvantaggia ad usare la compressione 
unicode?
La risposta è evidentemente NO.
Perchè non conviene?
Perchè la compressione agisce solo sul primo byte = a zero e i caratteri 
cirillici hano il primo byte impostato a 110.
A meno di sospettare serie patologie mentali, un motivo per aggiungere la 
possbibilità di impostare la compressione unicode, i tecnici microsoft 
avranno avuto un motivo abbastanza valido. O no?
La nota esplicativa è necessaria perchè con Access e unicode non si 
ottengono benefici ad usare la compressione se i caratteri non sono latini. 
Siccome Access è un db non solo multilingue ma che può accettare qualsiasi 
tipo di carattere e in qualsiasi lingua.
Ben lo sanno quei partecipanti al NG che localizzano i loro db in lingua 
THAY o in cinese...ricordi i post di qualche anno fa?
Anzi, a questo proposito, posso aggiungere che ci sono grossi problemi con 
il pur magnifico unicode, per esempio con il cinese che possiede più di 
50.000 "segni".
Già si pensa ad una nuova rappresentazione dei caratteri.
Ciao, Carlo