IT201800002537A1 - Procedimento per la compressione di dati, sistema, apparecchiatura, veicolo e prodotto informatico corrispondenti - Google Patents

Description

DESCRIZIONE dell’invenzione industriale dal titolo:

“Procedimento per la compressione di dati, sistema, apparecchiatura, veicolo e prodotto informatico corrispondenti”

TESTO DI DESCRIZIONE

Campo tecnico

La descrizione si riferisce alla compressione di dati. Una o più forme di realizzazione si possono applicare alla compressione di dati di testo in caratteri non latini.

Il cinese, giapponese, coreano, tailandese, vietnamita, russo (cirillico) sono esemplificativi di lingue cui si possono applicare le forme di realizzazione.

Sfondo tecnologico

Un’ampia gamma di prodotti (ad es. elettronica di consumo e prodotti mediali) previsti per grossi mercati quali certi mercati dell’estremo oriente come la Cina, la Corea o il Giappone ci si attende presentino caratteristiche atte a gestire in modo appropriato le lingue locali, che utilizzano caratteri non latini.

Esistono vari tipi di procedimenti di codifica che possono facilitare il modo di affrontare tale problema. Ad esempio, l’UNICODE è sempre più diffuso e dovrebbe diventare in alcuni anni lo standard per la codifica dei caratteri.

Esistono vari specifici schemi di codifica basati sul concetto di Identificatore Numerico UNICODE o UNICODE Code Point, quali UTF-16LE, UTF-16BE, UTF-32 e UTF-8. In un prossimo futuro, l’UTF-8 sarà presumibilmente quello più ampiamente utilizzato ed è già adottato in molti sistemi diversi. L’UTF-8 (designazione abbreviata per Universal Coded Character Set Transformation Format - 8-bit) è uno schema di codifica a larghezza variabile che consente la codifica di tutti i code point nell’UNICODE utilizzando da uno a quattro byte. Una caratteristica dell’UTF-8 è l’assenza di una specifica dimensione per un carattere, in quanto la lunghezza dipende dall’Unicode Code Point associato al carattere.

Scopo e sintesi

Nonostante l’attività discussa in precedenza, sono auspicabili soluzioni migliorate al fine di espandere ulteriormente l’utilizzo di schemi di codifica che facilitano la gestione di tali caratteri.

Uno scopo di una o più forme di realizzazione è di contribuire a fornire una tale soluzione migliorata.

Secondo una o più forme di realizzazione, un tale scopo si può conseguire per mezzo di un procedimento avente le caratteristiche esposte nelle rivendicazioni che seguono.

Una o più forme di realizzazione si possono riferire ad un corrispondente sistema, corrispondente apparecchiatura (ad es. apparecchiatura di autoradio) e un corrispondente veicolo (ad es., motore) dotato di tale apparecchiatura.

Una o più forme di realizzazione possono comprendere un prodotto informatico caricabile nella memoria di almeno un circuito di elaborazione (ad es., un processore a bordo di un veicolo) e comprendente porzioni di codice software per eseguire le fasi del procedimento quando il prodotto è eseguito su almeno un circuito di elaborazione. Come qui utilizato, il riferimento ad un tale prodotto informatico è compreso come essere equivalente al riferimento ad un mezzo leggibile su computer contenente istruzioni per controllare il sistema di elaborazione al fine di coordinare l’implementazione del procedimento secondo una o più forme di realizzazione. Il riferimento ad “almeno un computer” è previsto per evidenziare l’eventualità che una o più forme di realizzazione possano essere implementate in forma modulare e/o distribuita.

Le rivendicazioni sono parte integrante dell’insegnamento tecnico qui fornito rispetto alle forme di realizzazione.

Una o più forme di realizzazione facilitano la riduzione della dipendenza dell’uscita sull’ingresso di un processo di codifica di caratteri, fornendo un comportamento più prevedibile ad es. in termini di rapporto di compressione (il rapporto di compressione può essere in funzione delle stringhe di ingresso e può dipendere ad es. sul carattere dell’Unicode Code Point e ordine del carattere).

Si è verificato che una o più forme di realizzazione forniscono buoni risultati di compressione ad es. nella codifica di elenchi di riproduzione o playlist in sistemi di autoradio e simili.

Una o più forme di realizzazione facilitano la designazione di prodotti con un alto livello di prestazione (ad es. in termini di caratteristiche) rendendo inutile una SDRAM esterna.

Questi vantaggi si possono apprezzare ad es. in sistemi di autoradio quali la famiglia di dispositivi Accordo2<TM>, così come disponibili presso società del gruppo ST, fornendo anche nel contempo vantaggi in termini di ridotta BoM (Distinta Materiali o Bill of Materials).

Breve descrizione delle varie viste dei disegni

Una o più forme di realizzazione verranno ora descritte, solo a titolo di esempio, facendo riferimento alle figure annesse, in cui:

- la Figura 1 è un diagramma funzionale esemplificativo di un possibile contesto di utilizzo di forme di realizzazione,

- le Figure 2 e 3 sono un diagramma a blocchi esemplificativo di una possibile architettura di elaborazione nelle forme di realizzazione,

- le Figure 4 e 5 sono diagrammi di flusso esemplificativi di possibili atti di elaborazione nelle forme di realizzazione.

Descrizione dettagliata

Nella seguente descrizione, sono illustrati uno o più dettagli specifici, mirati a fornire una comprensione approfondita degli esempi di forme di realizzazione di questa descrizione. Le forme di realizzazione si possono ottenere senza uno o più dei dettagli specifici, o con altri procedimenti, componenti, materiali, ecc. In altri casi, note strutture, materiali, o funzionamenti non sono illustrati o descritti nel dettaglio tale che certi aspetti delle forme di realizzazione non verranno resi poco chiari.

Il riferimento a “una forma di realizzazione” nel quadro della presente descrizione è destinato ad indicare che una particolare configurazione, struttura o caratteristica descritta in relazione alla forma di realizzazione è compresa in almeno una forma di realizzazione. Di conseguenza, una frase quale “in una forma di realizzazione” che può essere presente in uno o più punti della presente descrizione non si riferisce necessariamente ad un’unica e alla stessa forma di realizzazione. Inoltre, conformazioni, strutture o caratteristiche particolari possono essere combinate in un modo adatto qualsiasi, in una o più forme di realizzazione.

I riferimenti qui utilizzati sono forniti meramente per comodità e quindi non definiscono la portata di protezione o l'ambito delle forme di realizzazione.

In Figura 1 il riferimento V indica un veicolo quale un’autovettura us cui è installato un sistema di car audio CR.

La famiglia di dispositivi Accordo2<TM>, come disponbile presso le società del gruppo ST, è esemplificativa di un tale sistema, che fornisce un’ampia gamma di funzionalità in aggiunta oltre all’utilizzo convenzionale come ricevitore radio installato a bordo di un veicolo.

Ad esempio, Accordo2<TM >è una famiglia di dispositivi che forniscono una soluzione di processore efficiente in termini di costo per sistemi di autoradio nel settore automobilistico moderno, con un potente sottosistema incorporato di Elaborazione di Suoni Digitali, così come un processore ARM Cortex-R4 efficiente ai MIPS ed un controllore ARM Cortex-M3 dedicato all’Elaborazione di Interfaccia di Veicolo/CAN in tempo reale.

I dispositivi della famiglia Accordo2<TM >sono provvisti di un insieme di interface comuni (UART/I2S/I2C/USB/MMC) il che facilita l’implementazione di un sistema ricco di caratteristiche così come una soluzione efficace in termini di costi, insieme ad un pacchetto software, che facilita l’implementazione veloce del sistema.

I dispositivi della famiglia Accordo2<TM >possono gestire una catena audio da ingress analogici o digitali ad uscite analogiche o digitali, comprendenti la decodifica di media audio digitali, la conversione della frequenza di campionamento fra varie sorgenti, l’instradamento intelligente ed effetti audio/post elaborazione di DSP. Una configurazione di memoria flessibile facilita l’implementazione da sistemi a bassissimo costo basati su OS in tempo reale, sino ad applicazioni esigenti basate su OS Linux.

Il contesto esemplificato nella Figura 1 è altrimenti meramente esemplificativo di una gamma in linea di principio illimitata di sistemi (ad es. apparecchiature di elettronica al consumo, dispositivi/supporti mediali) che, se previsti per mercati dove sono in uso caratteri/lingue non latini, si auspica possano supportare l’utilizzo di questi caratteri/lingue.

Indipendentemente dalla sua natura e destinazione un sistema CR come qui esemplificato può comprendere un blocco circuitale “sorgente” S per generare dati di testo espressi come caratteri (ipotizzati essere caratteri non latini) ed un blocco circuitale di elaborazione 10. Il blocco circuitale di elaborazione è configurato (come discusso nel seguito) per codificare tali dati in modo che questi possano essere memorizzati (con un’impronta di memoria ridotta) in una - ad es. RAM - memoria OT; il blocco circuitle 10 è configurato per leggere i dati codificati dalla memoria OT e decodificarli con i dati decodificati forniti ad un blocco circuitale di “consumo” U.

Meramente a titolo di esempio (facendo riferimento al contesto di utilizzo di autoradio discusso in precedenza -senza intento limitativo delle forme di realizzazione) i dati dal blocco circuitale S possono comprendere una playlist di brani da riprodurre in un sistema di autoradio, con una tale playlist (titoli, artisti interpreti, e così via) prevista per essere visualizzata su uno schermo nel blocco U (ad es. un’interfaccia uomo-macchina - HMI).

Come descritto, prodotti quali prodotti di elettronica di consumo e i prodotti mediali previsti per essere utilizzati in certi (grossi) mercati ci si aspetta presentino caratteristiche in grado di gestire in modo appropriato le lingue locali, che utilizzano caratteri non latini.

Ad esempio, facendo ancora una volta riferimento -senza intento limitativo delle forme di realizzazione - al settore delle autoradio - si nota che i clienti sono attratti dalla famiglia Accordo2<TM >poiché essa facilita lo sviluppo di sistemi di autoradio con un’ampia varietà di caratteristiche senza coinvolgere l’utilizzo di una memoria RAM esterna. I prodotti nella famiglia Accordo 2<TM >(quale lo STA1090) utilizzati in un sistema di informazione ed intrattenimento o infotainment del settore automobilistico (IVI) possono beneficiare estesamente della capacità di gestire questi caratteri/lingue, eventualmente con costo ridotto e/o prestazioni ulteriormente migliorate quali ulteriori caratteristiche disponibili.

In questo scenario, i clienti possono desiderare di avere supportati diversi tipi di media come la chiavetta USB o SDCARD (Scheda Digitale Sicura), con l’eventualità di memorizzare e gestire un maggiore numero di elementi (ad es. brani in una playlist). Ad esempio, i produttori di autoradio possono mirare ad offrire un’interfaccia uomomacchina complessa - HMI per mostrare al cliente finale informazioni approfondite relative a ciascun brano quali: nome artista, titolo canzone, genere e così via.

Secondo principi stabiliti, quando un dispositivo (ad es. USB, SD) è inserito nel sistema, il codice software in esecuzione nel circuito sorgente S inizia ad analizzarlo. Questo processo è chiamato parsing. Durante il parsing del dispositivo, le suddette informazioni sono memorizzate in una memoria RAM. Una RAM avente dimensioni (molto) limitate si può utilizzare per quello scopo al fine di facilitare una riproduzione e navigazione veloci.

Ad esempio, gli attuali prodotti basati su Accordo2<TM >consentono la gestione di un numero di file superiori a 5000 in un’unità di pilotaggio. Quando si utilizza ad es. l’UTF-8, si può memorizzare un carattere inglese utilizzando solo 1 byte. Lingue come il cinese comprendono caratteri che possono aver bisogno di memorizzare sino a 4 byte.

Apparecchiature quali un ricevitore radio (ad es. per sistemi di autoradio) possono creare una base dati locale per memorizzare informazioni su brani quale un percorso di file per accedere in breve tempo ad uno specifico file quando l’utente desidera avviare la riproduzione. In certi casi, è auspicabile essere in grado di fornire informazioni di metadata quail il titolo, artista e così via. Come conseguenza, i requisiti di memoria per memorizzare ad es.

5000 e più percorsi possono diventare gravosi.

La codifica migliorata (compressione) di tali stringhe di dati di testo può essere di conseguenza desiderabile con lo scopo di facilitare applicazioni a basso costo ad es. nel mercato del “Infotainment” audio, riducendo al contempo il costo totale (ad es. in termini di Distinta Materiali BOM).

La compressione del testo è stata un’ampia area di ricerca e sono disponibili varie procedure per comprimere testo o dati. Ad esempio, le librerie del consorzio UNICODE e dei Componenti Internazionali per Unicode (ICU) forniscono fra l’altro soluzioni note come:

- Standard Compression Scheme for UNICODE (SCSU)

- Binary Ordered Compresion for Unicode (BOCU)

Dei due, la BOCU (ad es. la versione nota come BOCU-1) è oggigiorno più comunemente utilizzata poiché essa può essere direttamente utilizzata per occuparsi di casi di utilizzo come la posta elettronica. Inoltre, essa può fornire buoni livelli di prestazione senza dover ricorrere a progettazioni complesse del codificatore.

Una descrizione introduttiva della BOCU si può trovare in corrispondenza di:

http://www.icuproject.org/docs/papers/binary_ordered_compression_for_unic ode.html

L’ordine lessicale ad es. della BOCU-1 è lo stesso del l’ordine del code point del testo originale, come l’UTF-8, al contrario della SCSU, che consente la compressione di grandi elenchi ordinati di stringhe.

Una o più forme di realizzazione si basano fra l’altro sul riconoscimento che questa caratteristica rende la BOCU-1 adatta per l’utilizzo nelle basi di dati per ridurre l’impronta di memoria; inoltre, la BOCU-1 è deterministica: vale a dire, uno stesso testo (completo) di ingresso risulterà in uno stesso testo di uscita, indipendentemente dalla progettazione del codificatore, il che non è il caso per la SCSU.

A titolo di riferimento, si possono valutare le prestazioni di un codificatore BOCU-1 in termini di tasso di compressione (ad es. rispetto all’UTF-8) utilizzando alcuni testi standard in lingue diverse che utilizzano caratteri non latini (ad es. cinese, giapponese, coreano, tailandese, vietnamita).

La tabella nel seguito mostra i risultati ottenibili per un testo di ingresso contenente 1024 caratteri.

Da questa analisi si può notare che il vietnamita si può considerare come un caso “patologico”.

Di fatto un codificatore BOCU è una macchina a stati e l’uscita è in funzione dell’ingresso e dello stato del codificatore. Questo stato è calcolato in funzione del carattere precedente. La lunghezza del carattere codificato è in funzione dello stato. L’alfabeto vietnamita produce cambiamenti continui in questo stato con una perdita di prestazioni, per cui si possono generare stringhe di uscita che sono più lunghe delle stringhe di ingresso.

Inoltre, la prestazione di codifica può dipendere dal carattere di ingresso per cui il tasso di compressione possa essere difficile da predire: ad esempio, ingressi in cinese e giapponese di una stessa dimensione possono risultare in tassi di compressione (notevolmente) diversi.

Un tasso di compressione medio mantenuto di circa il 30% può essere un obiettivo desiderabile per certi mercati asiatici (ad es. Cina, Giappone e Corea).

Mentre la suddetta tabella mostra che un tale traguardo (ad es. una riduzione dell’impronta di memoria del 30%) può essere ottenibile con la BOCU, si nota che la prestazione in condizioni di funzionamento reale (ad es. una playlist) può differire in modo apprezzabile dai risultati raffigurati nella tabella riprodotta sopra.

Ad esempio, le prove eseguite su una playlist cinese esemplificativa con dimensione di ingresso di 1027-byte hanno condotto ad un’uscita compressa tramite BOCU di 948-byte che corrisponde ad un tasso di compressione di appena il 7.69%.

Queste scarse prestazioni di compressione sono presumibilmente correlate a frequenti cambiamenti di alfabeti/caratteri che si possono verificare nelle playlist.

Una o più forme di realizzazione si possono occupare di questo problema integrando un nucleo di BOCU (ad es. BOCU-1) con tre atti di elaborazione aggiuntivi (cui nel seguito si fa riferimento in breve come “ottimizzazioni”), che si è scoperto contribuireo a migliorare le prestazioni ad es. in abbinamento ad un testo quale una playlist.

Nel seguito, verranno descritte tre tali ottimizzazioni esemplificative attorno ad un nucleo di codifica/decodifica BOCU (ad es. BOCU-1) che sono adatte per essere implementate ad es. nel blocco circuitale 10 con un obiettivo comune di ridurre i cambiamenti dello stato del codificatore.

Si comprenderà altrimenti che possibili forme di realizzazione non sono limitate all’applicazione congiunta di tutte queste tre ottimizzazioni in combinazione. A seconda ad es. di requisiti d’utente e/o scelte di implementazione, una o più forme di realizzazione possono comportare l’utilizzo di solo una o due di queste ottimizzazioni conservando al contempo un livello di prestazione accettabile.

Una prima ottimizzazione come esemplificata nelle Figure 2 e 3 mira ad aumentare il tasso di compressione evitando nel contempo il comportamento indesiderabile come sperimentato ad es. nella codifica BOCU standard vietnamita (si veda ad es. il valore di compressione “negativo” nella tabella riprodotta in precedenza).

In una o più forme di realizzazione, la corrispondente elaborazione può comportare un confronto di una stringa di ingresso (ad es. UTF-8) e della stringa codificata (BOCU) associata. Se la lunghezza della stringa di ingresso è inferiore alla lunghezza della corrispondente stringa codificata, la stringa codificata è “saltata” e viene memorizzata la stringa originale.

Il corrispodente controllo può comportare uno strato di memoria per facilitare la decodifica e rilevamento corretti di quale delle due stringhe le cui lunghezze sono confrontate è codificata in UTF-8 e quale è codificata tramite BOCU.

Come esemplificato nella Figura 2, tale elaborazione può comportare i seguenti atti:

- una stringa di caratteri standard (ad es. UTF-8) è prelevata da una tabella di ingresso IT (o direttamente da un file system);

- la lunghezza in corrispondenza di quella stringa, cioè SL1, è controllata/calcolata, il che, nel caso di una stringa UTF-8, si può verificare tramite una funzione C standard compresa in una libreria “string.h”;

- la stringa di ingresso è codificata tramite BOCU in corrispondenza di un codificatore BEN, ad es. utilizzando una procedura BOCU-1 convenzionale con la lunghezza della stringa codificata tramite BOCU che diventa disponibile come SL2;

- le lunghezze SL1 (ad es. UTF-8) e SL2 (ad es. BOCU-1) sono confrontate in corrispondenza di un comparatore CMP;

- se la lunghezza della stringa codificata tramite BOCU SL2 è più lunga di o uguale alla lunghezza della stringa UTF-8 SL1 (il che è indicativo di nessun vantaggio conseguito con la codifica tramite BOCU) un bit o indice associato in una struttura di codifica ES è impostato su un primo valore (ad es. su “0”); in alternativa se la lunghezza della stringa codificata tramite BOCU SL2 è più breve della lunghezza della stringa UTF-8 SL1 (il che è indicativo di un vantaggio conseguito con la codifica tramite BOCU) il bit o indice associato nella struttura di codifica ES è impostato su un secondo valore (ad es. su “1”);

- la stringa più breve (UTF-8 or BOCU-1) è memorizzata in una memoria o tabella di uscita OT.

A titolo di implementazione pratica, la struttura (memoria) ES si può considerare come una sequenza di bit, uno per ciascuna stringa di ingresso.

Il valore del bit si può cambiare basandosi sul risultato del confronto in corrispondenza del CMP, con il risultato per la i-esima stringa che si può salvare nell’iesimo bit nella memoria ES, tale che l’i-esimo indice può avere un valore di “0” o “1”.

In una o più forme di realizzazione, il bit memorizzato in corrispondenza del ES si può utilizzare come un indicatore di una possibile decodifica BOCU (vale a dire da BOCU-1 a UTF-8) da eseguire. In effetti, in una o più forme di realizzazione tale decodifica verrà eseguita (solo) se una stringa codificata tramite BOCU è stata memorizzata in corrispondenza dell’OT da cui una stringa UTF-8 verrà recuperata da un’azione di decodifica.

Questo tipo di operazione è esemplificata nella Figura 2 sotto forma di un ideale componente MUX, che, in funzione del valore “0” o “1” memorizzato in corrispondenza dell’ES, rende possibile selezionare una possibile azione di decodifica da BOCU-1 a ritroso in UTF-8.

Questo tipo di operazione è inoltre esemplificata nella Figura 3 sotto forma di due componenti MUX, MUX1 e MUX2 fatti funzionare sotto il controllo della struttura ES e che definiscono due possibili percorsi per le stringhe memorizzate in corrispondenza dell’OT:

- un primo percorso (attivato quando l’indice nell’ES è impostato sul primo valore, ad es. su “0”), tale che le stringhe UTF-8 originali memorizzate in corrispondenza dell’OT siano fatte passare direttamente all’uscita in quanto tale;

- un secondo percorso (attivato quando l’indice nell’ES è impostato sul secondo valore, ad es. su “1”) tale che le stringhe codificate tramite BOCU memorizzate in corrispondenza dell’OT siano fatte passare attraverso un decodificatore di BOCU, BDEC (ad es. BOCU-1) per essere di nuovo decodificate all’UTF-8 e fatte passare all’uscita.

Nell’utilizzare un campo ad un bit (ad es. nell’ES) come stato di memoria per l’ottimizzazione facilita il fatto di avere un impatto ridotto sull’impronta di memoria.

L’applicazione di questa prima ottimizzazione alla playlist cinese esemplificativa di dimensione di ingresso di 1027-byte discussa in precedenza ha condotto ad un’uscita di 928-byte data dalla somma della dimensione della tabella di uscita OT (923 byte) con la dimensione (5 byte) della struttura di codifica ES (una tabella contenente i campi di memoria associati alle stringhe di ingresso).

Ciò corrisponde ad un tasso di compressione del 9.64%, con un guadagno in termini di tasso di compressione attorno al 2%. Questo risultato è altrimenti di interesse poiché dimostra che, anche se non ad una tale quantità significativa come nel caso del vietnamita, qualsiasi alfabeto può aver condotto a stringhe di uscita BOCU più lunghe delle stringhe di ingresso.

Una o più forme di realizzazione possono comprendere una seconda ottimizzazione (come notato, questo termine è qui utilizzato meramente per brevità) che insegue il traguardo di ridurre i cambiamenti di stato nel codificatore BOCU (ad es. BOCU-1).

In tal senso una o più forme di realizzazione possono comportare la gestione di specifici caratteri come eccezioni.

Come descritto, l’elaborazione della BOCU quale la BOCU-1 è una compressione MIME per Unicode. MIME (un acronimo per Multipurpose Internet Mail Extensions) è uno standard Internet che facilita il supporto di posta elettronica ad es. di caratteri diversi dall’ASCII o audio, video, immagini, programmi applicativi e così via.

L’ASCII (American Standard Code for Information Interchange) è uno standard di codifica di caratteri ben noto adatto per rappresentare il testo in computer, apparecchiature di telecomunicazioni, e così via.

MIME fornisce caratteri di controllo che sono “di per sé codificati”, con caratteri in un Insieme di Controllo (ad es. C0) già trattati come eccezioni che non producono un cambiamento nello stato del codificatore.

Gli insiemi di codici di controllo o di caratteri di controllo quali C0 o C1 sono utilizzati come codici di controllo per il testo tramite sistemi di computer per fornire informazioni ausiliarie riguardanti il testo, quali la posizioni di un cursore, un’istruzione per avviare una nuova linea, o un messaggio che il testo è stato ricevuto.

L’insieme C0 definisce i codici nell’intervallo 00HEX– 1FHEX (si veda ad es. http://www.unicode.org/charts/PDF/U0000.pdf).

All’insieme C0 verrà qui di seguito fatto rifermento come esemplificativo di un insieme di caratteri di controllo (codici di controllo) adatti per l’utilizzo nelle forme di realizzazione, essendo altrimenti compreso che altri insiemi di caratteri di controllo (ad es. C1) si possono utilizzare in una o più forme di realizzazione.

Si nota che certe applicazioni quali le playlist comportano la gestione di un percorso di file che non contempla l’utilizzo di tali caratteri C0, tale che non esiste la necessità di tale caratteristica MIME, poiché la maggior parte di questi caratteri non sono contemplati per essere inseriti in file o nomi di cartella.

Tuttavia, questa caratteristica si può utilizzare in una o più forme di realizzazione per migliorare la prestazione convertendo un insieme di caratteri ASCII frequentemente utilizzati in un insieme di caratteri di controllo “sicuro” (ad es. C0), che riduca l’occorrenza di cambiamenti di stato del codificatore, creando di conseguenza un insieme di caratteri speciali che sono gestiti ad es. come il carattere SPAZIO nella BOCU-1.

Ad esempio, l’insieme C0 è sufficientemente ampio per comprendere caratteri ASCII come frequentemente utilizzati ad es. nelle playlist, quali ad es.:

- numeri: ‘0’, ‘1’, ‘2’, ‘3’, ‘4’, ’5’, ‘6’, ‘7’, ‘8’, ‘9’

- simboli: ‘/’, ‘-’, ‘.’, ‘_’, ‘(’, ’)’

Questa soluzione è di beneficio poiché un insieme di caratteri di controllo quale C0 è escluso dal calcolo della BOCU standard e può non sorgere alcun rischio di generare codifiche ambigue.

L’utilizzo di questa seconda ottimizzazione è abbastanza facile: i caratteri previsti per essere utilizzati frequentemente si possono convertire ad es. in un carattere C0, ad es. utilizzando una tabella per associare il valore desiderato. Si può adottare lo stesso approccio nella fase di decodifica.

L’applicazione di questa seconda ottimizzazione alla playlist cinese esemplificativa di dimensione di ingresso di 1027-byte discussa in precedenza (selezionando per l’inclusione nell’insieme C0 i simboli aventi la ricorrenza maggiore nella playlist) ha condotto ad un’uscita di 904-byte. Ciò corrisponde ad un tasso di compressione del 11.98%, con una tale pre-elaborazione che fornisce un guadagno in termini di tasso di compressione attorno al 4%.

Una o più forme di realizzazione possono comprendere una terza ottimizzazione (nuovamente, questo termine è qui utilizzato meramente per brevità) che comnporta la codifica di estensioni di file.

Si è verificato che ciò ha condotto ad un buon miglioramento in termini di lunghezza di stringa e conseguentemente in termini di impronta di memoria.

In una o più forme di realizzazione, un’estensione di file si può sostituire con un numero (decimale) a singola cifra (a cui si può applicare la seconda ottimizzazione discussa in precedenza) o direttamente con un simbolo scelto tra simboli mappati su un insieme di caratteri di controllo (ad es. C0) come discusso in precedenza.

Nell’utilizzare questa ottimizzazione sulla seconda, le stringhe codificate possono impiegare (solo) 1 byte per codificare l’estensione di file poiché, come discusso in precedenza, i numeri e simboli mappati sull’insieme C0 non sono codificati.

Il seguente è un elenco esemplificativo di come si possono associare cifre (decimali) ad estensioni di file:

- “.mp3” = ‘1’

- .”wav” = ‘2’

- “.flac” = ‘3’

e così via.

Questa terza ottimizzazione si può teoricamente utilizzare in modo autonomo. Tuttavia, i vantaggi relativi al suo utilizzo sono meglio apprezzati quando utilizzati assieme a due altre ottimizzazioni (specialmente la seconda ottimizzazione, con cifre comprese nell’insieme C0).

Il diagramma di flusso della Figure 4 è esemplificativo del possibile utilizzo combinato delle tre ottimizzazioni discusse in precedenza nella codifica del testo quale una playlist che utilizza caratteri non latini quali un testo in cinese, giapponese, coreano, tailandese, vietnamita, russo (cirillico).

Dopo l’AVVIO, in un atto rappresentato dal blocco 100 la terza ottimizzazione, vale a dire è applicata la codifica di estensioni di file come numeri (decimali) a singola cifra.

Dopo ciò, la seconda ottimizzazione (mappatura di numeri ed altri simboli frequentemente utilizzati su un insieme di caratteri di controllo, ad es. l’insieme C0) è applicata in un atto rappresentato dal blocco 102.

Come notato, l’esecuzione della terza ottimizzazione prima della seconda ottimizzazione può essere per quanto possibile vantaggioso poiché i numeri che codificano le estensioni di file nella terza ottimizzazione si possono mappare sull’insieme C0 nella seconda ottimizzazione.

In un atto come rappresentato dal blocco 104, l’applicazione della prima ottimizzazione si può avviare calcolando (come discusso sopra) le lunghezze delle stringhe di ingresso (ad es. UTF-8) risultanti dalle terze e seconde ottimizzazioni .

Queste stringhe sono anche codificate tramite BOCU (ad es. con BOCU-1) in un atto come rappresentato dal blocco 106, con le lunghezze delle stringhe codificate tramite BOCU calcolate in un atto come rappresentato dal blocco 108.

Le lunghezze delle stringhe di ingresso (ad es. UTF-8) risultanti dalle terze e seconde ottimizzazioni sono confrontate con le lunghezze delle loro controparti codificate tramite BOCU in un atto come rappresentato dal blocco 110.

Se il controllo in corrispondenza di 110 rivela che la stringa UTF-8 è più breve o uguale in lunghezza rispetto alla versione codificata tramite BOCU (vale a dire, con la codifica BOCU che fallisce a fornire una riduzione di lunghezza desiderata, come eventualmente indicato dall’indice nell’ES nelle Figure 2 e 3 impostato sul primo valore - ad es. su “0”) la stringa UTF-8 è emessa, ad es., memorizzata nella memoria RAM quale l’OT, in un atto come rappresentato dal blocco 112.

Se, al contrario, il controllo in corrispondenza di 110 rivela che la stringa UTF-8 è più lunga della versione codificata tramite BOCU (vale a dire, con la codifica BOCU che fornisce una riduzione di lunghezza desiderata, come eventualmente indicato dall’indice nell’ES nelle Figure 2 e 3 impostato sul secondo valore - ad es. su “1”) la stringa codificata tramite BOCU è emessa, ad es., memorizzata nella memoria RAM quale l’OT, in un atto come rappresentato dal blocco 114.

Dopo o l’uno o l’altro degli atti 112 e 114 la procedura di codifica arriva ad una FINE.

Il diagramma di flusso della Figura 5 è esemplificativo dell’eventuale procedura di decodifica complementare alla procedura di codifica esemplificata dal diagramma di flusso della Figura 4.

Dopo l’AVVIO, in un atto come rappresentato dal blocco 200 è effettuato un controllo per quanto riguarda il valore dell’indice memorizzato nell’ES.

Se il controllo in corrispondenza di 200 rivela che l’indice nell’ES per una stringa è impostato sul primo valore - ad es. su “0” - in modo che la stringa UTF-8 e non la sua versione codificata tramite BOCU sia stata memorizzata (vale a dire, con la codifica BOCU che fallisce a fornire una riduzione di lunghezza desiderata) in un atto come rappresentato dal blocco 202 la stringa (UTF-8) letta dalla memoria è semplicemente fatta inoltrare, vale a dire l’atto 202 è un atto di “fare niente”.

Se al contrario, il controllo in corrispondenza di 200 rivela che l’indice nell’ES per la stringa in questione è impostato sul secondo valore - ad es. su “1” - in modo che la stringa codificata tramite BOCU sia stata memorizzata (con la codifica BOCU che fornisce una riduzione di lunghezza come desiderato) in un atto come rappresentato dal blocco 204 la decodifica BOCU è applicata (in una maniera di per sé nota) alla stringa codificata tramite BOCU letta dalla memoria.

In quell modo, l’elaborazione complementare alla prima ottimizzazione degli atti 104 a 114 della Figura 4 è applicata nella decodifica.

In un atto come rappresentato dal blocco 206, l’elaborazione complementare alla seconda ottimizzazione dell’atto 102 nella Figura 4 è applicata alla stringa (UTF-8) o dall’uno o dall’altro atto 202 (“fare niente”) e 204 (Decodifica BOCU), in modo che numeri quali ‘0’, ‘1’, ‘2’, ‘3’, ‘4’, ’5’, ‘6’, ‘7’, ‘8’, ‘9’ o simboli quali ‘/’, ‘-‘, ‘.’, ‘_’, ‘(‘, ‘)’ siano recuperati dall’insieme di caratteri di controllo, ad es. C0.

In un atto come rappresentato dal blocco 208, l’elaborazione complementare alla terza ottimizzazione dell’atto 100 nella Figura 4 è applicata per recuperare le estensioni di file dai numeri che erano associati ad esse, dopodichè la procedura di decodifica può arrivare ad una FINE.

Si apprezzerà che, nelle forme di realizzazione come qui esemplificato tutte le tre ottimizzazioni sono applicate nella codifica in un ordine (terza ottimizzazione - 100, seconda ottimizzazione - 102, prima ottimizzazione -104 a 114) che è riprodotta in un ordine inverso complementare simmetrico a specchio nella decodifica rispettivamente tramite gli atti 200 a 204, atto 206, e atto 208.

Come notato, in certe forme di realizzazione, si può applicare solo una parte delle ottimizzazioni qui esemplificate. Inoltre, l’ordine di applicazione di tali ottimizzazioni può essere almeno parzialmente modificato, ad es. avendo riguardo ai requisiti di applicazione/implementazione (ad es. pipeline di operazioni).

Si è verificato che una o più forme di realizzazione aumentano efficacemente il rapporto di compressione.

Ad esempio, quando si utilizzano tutte le tre ottimizzazioni, si è scoperto che il risultante rapporto di compressione per la playlist cinese a cui viene ripetutamente fatto riferimento in precedenza era attorno al 23%. Ulteriori prove eseguite con una playlist con lingue miste basata sul russo, giapponese e cinese hanno mostrato una prestazione ulteriormente migliorata con un rapporto di compressione quasi uguale al 34 %.

Questi risultati sono sintetizzati nella tabella riprodotta nel seguito.

Il calcolo del differenziale (delta) sul tasso di compressione sulla codifica BOCU standard per questi due esempi pratici produce valori di 3.13 e 1.36 rispettivamente per la playlist cinese e la playlist a lingue miste.

I suddetti risultati mostrano un miglioramento apprezzabile nel caso della playlist cinese rispetto al tasso di compressione della BOCU-1 standard. Si è scoperto che esiste un miglioramento anche nel caso di una playlist mista.

Un procedimento secondo una o più forme di realizzazione può comprendere:

- ricevere (ad es. IT) dati di testo digitale comprendenti stringhe di dati rappresentative di caratteri di testo,

- codificare (ad es. 100 a 114) dette stringhe di dati in detti dati di testo digitale applicando ad esse almeno una fra:

- i) una prima elaborazione (ad es. 104 a 114) comprendente la codifica BOCU (ad es. BEN, 106) di dette stringhe di dati, confrontare (ad es. CMP, 110) le lunghezze nelle stringhe di dati come ricevute e come stringhe codificate tramite BOCU risultanti da detta codifica BOCU, e mantenere (ad es. 114) le stringhe codificate tramite BOCU come stringhe codificate se le stringhe codificate tramite BOCU sono più brevi delle stringhe di dati come ricevute,

- ii) una seconda elaborazione (ad es. 102) comprendente localizzare in dette stringhe di dati rappresentative di caratteri di testo ASCII caratteri rappresentativi di numeri e simboli e mappare i caratteri localizzati su rispettivi caratteri in un insieme di caratteri di controllo BOCU (ad es. C0),

- iii) una terza elaborazione (ad es. 100) comprendente localizzare in dette stringhe di dati rappresentative di caratteri di testo, caratteri indicativi di estensioni di file e sostituire detti caratteri indicativi di estensioni di file con rispettivi numeri decimali.

Una o più forme di realizzazione possono comprendere applicare a dette stringhe di dati entrambe detta seconda elaborazione e detta terza elaborazione, con la terza elaborazione che precede la seconda elaborazione, in cui i numeri decimali che sostituiscono i caratteri indicativi di estensioni di file sono mappati in detto insieme di caratteri di controllo BOCU.

Una o più forme di realizzazione possono comprendere applicare a dette stringhe di dati detta prima elaborazione con la prima elaborazione che segue la terza e/o la seconda elaborazione.

Una o più forme di realizzazione possono comprendere memorizzare in una memoria (ad es. OT) le stringhe di dati a cui è stata applicata detta codifica.

Una o più forme di realizzazione possono comprendere applicare a dette stringhe di dati detta prima elaborazione e memorizzare (ad es. in corrispondenza di ES) assieme alle stringhe di dati a cui è stata applicata detta prima elaborazione un indice indicativo del fatto se le stringhe codificate tramite BOCU sono più brevi delle stringhe di dati come ricevute.

In una o più forme di realizzazione, i dati di testo digitale possono comprendere:

- stringhe di dati UTF-8, e/o

- stringhe di dati rappresentative di caratteri di testo non latini, preferibilmente selezionati fra caratteri e relative combinazioni di cinese, giapponese, coreano, tailandese, vietnamita, russo (cirillico).

Un procedimento di decodifica secondo una o più forme di realizzazione può comprendere:

- ricevere (ad es. OT) dati di testo digitale codificati con il procedimento secondo una o più forme di realizzazione,

- decodificare (ad es. 200 a 208) detti dati di testo digitale codificati applicando ad essi l’elaborazione complementare all’almeno una fra detta prima, seconda e terza elaborazione come applicata nella codifica di dette stringhe di dati in detti dati di testo digitale.

Una o più forme di realizzazione possono comprendere rilevare (ad es. 200, ES) se detta prima elaborazione è stata applicata a detto testo digitale codificato mantenendo le stringhe codificate tramite BOCU come stringhe codificate, e

- se le stringhe codificate tramite BOCU sono state mantenute come stringhe codificate, applicare (ad es. 204) la decodifica BOCU alle stringhe codificate tramite BOCU, o altrimenti

- se le stringhe codificate tramite BOCU non sono state mantenute come stringhe codificate, inoltrare (ad es.

202) i dati di testo digitale ricevuti omettendo l’applicazione delladecodifica BOCU ad essi.

In una o più forme di realizzazione, un procedimento di decodifica può comprendere:

- leggere (ad es. 200) il valore di un indice (ad es. ES) indicativo del fatto se le stringhe codificate tramite BOCU sono più brevi delle stringhe di dati come ricevute; e - selezionare di applicare la decodifica BOCU alle stringhe codificate tramite BOCU o altrimenti inoltrare i dati di testo digitale ricevuti omettendo l’applicazione della decodifica BOCU ad essi in funzione del valore dell’indice letto.

Un sistema secondo una o più forme di realizzazione può comprendere:

- un circuito codificatore (ad es. 10) configurato per ricevere da una sorgente di dati di testo digitale dati di testo digitale comprendenti stringhe di dati rappresentative di caratteri di testo e applicare a dette stringhe di dati in detta codifica di dati di testo digitale con il procedimento di codifica secondo una o più forme di realizzazione,

- un circuito di memoria (ad es. OT) accoppiato al circuito codificatore per memorizzare dati di testo digitale così codificati,

- un circuito decodificatore accoppiato al circuito di memoria, il circuito decodificatore configurato per ricevere dati di testo digitale codificati dal circuito codificatore e memorizzati nel circuito di memoria, in cui il circuito decodificatore è configurato per decodificare con il procedimento di decodifica secondo una o più forme di realizzazione dati di testo digitale codificati dal circuito codificatore e memorizzati nel circuito di memoria.

Apparecchiatura secondo una o più forme di realizzazione può comprendere:

- una sorgente di dati di testo digitale,

- un sistema secondo una o più forme di realizzazione con il circuito codificatore nel sistema accoppiato alla sorgente di dati di testo digitale e configurato per ricevere da esso dati di testo digitale comprendenti stringhe di dati rappresentative di caratteri di testo, - un’unità di consumo di dati di testo digitale (ad es. U) accoppiata al circuito decodificatore nel sistema, il circuito decodificatore configurato per fornire all’unità di consumo di dati di testo digitale, dopo la decodifica, i dati di testo digitale codificati dal circuito codificatore e memorizzati nel circuito di memoria.

Apparecchiatura secondo una o più forme di realizzazione può comprendere a sistema di autoradio, la sorgente di dati di testo digitale comprendente opzionalmente una sorgente di dati di playlist.

Una o più forme di realizzazione possono comprendere un veicolo (ad es. un veicolo a motore V) dotato di un’apparecchiatura secondo una o più forme di realizzazione.

Una o più forme di realizzazione possono comprendere un prodotto informatico caricabile nella memoria di almeno un circuito di elaborazione (ad es., 10) e comprendente porzioni di codice software per eseguire le fasi del procedimento (codifica e/o decodifica) di una o più forme di realizzazione quando il prodotto è eseguito su almeno un circuito di elaborazione.

Senza pregiudizio per i principi sottostanti, i dettagli e le forme di realizzazione possono variare anche notevolmente, rispetto a quanto descritto in precedenza solo a titolo di esempio, senza discostarsi dall'ambito di protezione.

L’ambito di protezione è definito dalle rivendicazioni annesse.

Claims (14)

1. RIVENDICAZIONI 1. Procedimento, comprendente: - ricevere (IT) dati di testo digitale comprendenti stringhe di dati rappresentative di caratteri di testo, - codificare (100 a 114) dette stringhe di dati in detti dati di testo digitale applicando ad esse almeno una fra: - i) una prima elaborazione (104 a 114) comprendente la codifica BOCU (BEN, 106) di dette stringhe di dati, confrontare (CMP, 110) le lunghezze nelle stringhe di dati come ricevute (IT) e come stringhe codificate tramite BOCU risultanti da detta codifica BOCU, e mantenere (114) le stringhe codificate tramite BOCU come stringhe codificate se le stringhe codificate tramite BOCU sono più brevi delle stringhe di dati come ricevute, - ii) una seconda elaborazione (102) comprendente localizzare in dette stringhe di dati rappresentative di caratteri di testo ASCII caratteri rappresentativi di numeri e simboli e mappare i caratteri localizzati in rispettivi caratteri in un insieme di caratteri di controllo BOCU, - iii) una terza elaborazione (100) comprendente localizzare in dette stringhe di dati rappresentative di caratteri di testo, caratteri indicativi di estensioni di file e sostituire detti caratteri indicativi di estensioni di file con rispettivi numeri decimali.
2. 2. Procedimento secondo la rivendicazione 1, comprendente applicare a dette stringhe di dati entrambe detta seconda elaborazione (102) e detta terza elaborazione (103), con la terza elaborazione (100) che precede la seconda elaborazione (102), in cui i numeri decimali che sostituiscono i caratteri indicativi di estensioni di file sono mappati in detto insieme di caratteri di controllo BOCU.
3. 3. Procedimento secondo la rivendicazione 1, comprendente applicare a dette stringhe di dati detta prima elaborazione (104 a 114) con la prima elaborazione (104 a 114) che segue la terza (103) e/o la seconda elaborazione (102).
4. 4. Procedimento secondo qualsiasi delle rivendicazioni 1 a 3, comprendente memorizzare in una memoria (OT) le stringhe di dati a cui è stata applicata detta codifica (100 a 114).
5. 5. Procedimento secondo la rivendicazione 4, comprendente applicare a dette stringhe di dati detta prima elaborazione (104 a 114) e memorizzare (ES) assieme alle stringhe di dati a cui è stata applicata detta prima elaborazione (104 a 114) un indice indicativo del fatto se le stringhe codificate tramite BOCU son più brevi delle stringhe di dati come ricevute.
6. 6. Procedimento secondo qualsiasi delle rivendicazioni 1 a 5, in cui i dati di testo digitale comprendono: - stringhe di dati UTF-8, e/o - stringhe di dati rappresentative caratteri di testo non latini, preferibilmente selezionati fra caratteri e relative combinazioni di cinese, giapponese, coreano, tailandese, vietnamita, russo (cirillico).
7. 7. Procedimento, comprendente: - ricevere (OT) dati di testo digitale codificati con il procedimento secondo qualsiasi delle rivendicazioni 1 a 6, - decodificare (200 a 208) detti dati di testo digitale codificati applicando ad essi l’elaborazione complementare all’almeno una di detta prima (104 a 114), seconda (102) e terza elaborazione (100) come applicata nella codifica (100 a 114) di dette stringhe di dati in detti dati di testo digitale.
8. 8. Procedimento di decodifica secondo la rivendicazione 7, comprendente rilevare (200, ES) se detta prima elaborazione (104 a 114) è stata applicata a detto testo digitale codificato mantenendo (114) le stringhe codificate tramite BOCU come stringhe codificate, e - se le stringhe codificate tramite BOCU sono state mantenute come stringhe codificate, applicare (204) la decodifica BOCU alle stringhe codificate tramite BOCU, o altrimenti - se le stringhe codificate tramite BOCU non sono state mantenute come stringhe codificate, inoltrare (202) i dati di testo digitale (OT) ricevuti omettendo l’applicazione ad essi della decodifica BOCU.
9. 9. Procedimento di decodifica secondo la rivendicazione 8 applicato ai dati di testo digitale (OT) ricevuti codificati con il procedimento secondo la rivendicazione 5, il procedimento di decodifica comprendendo: - leggere (200) il valore di detto indice (ES) indicativo del fatto se le stringhe codificate tramite BOCU sono più brevi delle stringhe di dati come ricevute; e - selezionare di applicare (204) la decodifica BOCU alle stringhe codificate tramite BOCU o altrimenti di inoltrare (202) i dati di testo digitale (OT) ricevuti omettendo (202) l’applicazione ad essi della decodifica BOCU in funzione del valore dell’indice letto (ES).
10. 10. Sistema, comprendente: - un circuito codificatore (10) configurato per ricevere (IT) da una sorgente (S) di dati di testo digitale dati di testo digitale comprendenti stringhe di dati rappresentative di caratteri di testo e applicare a dette stringhe di dati in detti dati di testo digitale la codifica (100 a 114) con il procedimento secondo qualsiasi delle rivendicazioni 1 a 6, - un circuito di memoria (OT) accoppiato al circuito codificatore (10) per memorizzare i dati di testo digitale cosi codificati, - un circuito decodificatore (10) accoppiato al circuito di memoria (OT), il circuito decodificatore (10) configurato per ricevere i dati di testo digitale codificati dal circuito codificatore (10) e memorizzati nel circuito di memoria (OT), in cui il circuito decodificatore (10) è configurato per decodificare con il procedimento secondo qualsiasi delle rivendicazioni 7 a 9 i dati di testo digitale codificati dal circuito codificatore (10) e memorizzati nel circuito di memoria (OT).
11. 11. Apparecchiatura, comprendente: - una sorgente (S) di dati di testo digitale, - un sistema (10) secondo la rivendicazione 10 con il circuito codificatore (10) nel sistema accoppiato alla sorgente (S) di dati di testo digitale e configurato per ricevere da essa i dati di testo digitale comprendenti le stringhe di dati rappresentative di caratteri di testo, - un’unità (U) di consumo di dati di testo digitale accoppiata al circuito decodificatore (10) nel sistema, il circuito decodificatore configurato per fornire all’unità (U) di consumo di dati di testo digitale, dopo averli decodificati, i dati di testo digitale codificati dal circuito codificatore (10) e memorizzati nel circuito di memoria (OT).
12. 12. Apparecchiatura secondo la rivendicazione 11, in cui l’apparecchiatura comprende un sistema di autoradio, la sorgente (S) di dati di testo digitale comprendendo preferibilmente una sorgente di dati di playlist.
13. 13. Veicolo (V) dotato di un’apparecchiatura secondo la rivendicazione 11 o rivendicazione 12.
14. 14. Prodotto informatico caricabile nella memoria di almeno un circuito di elaborazione (10) e comprendente porzioni di codice software per eseguire le fasi del procedimento secondo qualsiasi delle rivendicazioni 1 a 9 quando il prodotto è eseguito su almeno un circuito di elaborazione.