Come fare il rimando incrociato di molte codifiche di caratteri con ASCII o UTFx?

1

Sto lavorando con una struttura binaria, il cui scopo è quello di indicizzare il significato di bit specifici per qualsiasi codifica di caratteri in modo che possiamo attivare eventi mentre facciamo controlli specifici sul profilo.

Ogni schema di codifica dei caratteri ha un record di sistema associato. Il valore iniziale di questo record sarà un valore binario diunsigned long long in C ++% e indica la lunghezza, in bit, dei caratteri codificati.

Seguendo la lunghezza ci sono tre valori, ognuno dei quali è un campo bit di quella lunghezza.

  • offset_mask - definisce l'occorrenza di caratteri non stampabili all'interno del min, max di print_mask
  • range_mask - definisce l'occorrenza del 50% più popolare dei caratteri stampabili
  • print_mask - definisce il valore di occorrenza dei caratteri stampabili

La struttura dei profili è cambiata dall'op di questa domanda. Molto probabilmente cercherò di ridimensionare o comprimere questi valori a lungo termine invece di iniziare con intervalli dopo aver letto di più.

Devo scrivere alcune delle funzionalità di base per questi motivi principali.

  • Deve adattarsi a una particolare architettura di eventi che stiamo utilizzando,
  • Migliore comprensione della codifica dei caratteri. Ne ho bisogno.
  • L'integrazione nel design non lineare esclude molte librerie senza hook speciali.

Non sono sicuro se esiste un meccanismo standard di codifica incrociata per comunicare già tali dati. Sto appena iniziando a esaminare come chardet potrebbe fare il profiling come suggerito da @amon. Il BOM Unicode sarebbe abbastanza semplice (per il mio progetto attuale) se tutte le codifiche fossero Unicode.

Naturalmente, idealmente, vorremmo supportare tutte le codifiche, ma non sto chiedendo l'implementazione - solo il caso generale.

Come possono questi profili essere popolati in modo efficiente, per produrre un set di maschere di bit che possiamo usare per far corrispondere le stringhe con caratteri comuni in più lingue?

Se hai suggerimenti di modifica, ti prego di essere libero, sono leggero quando si tratta di localizzazione, ed è per questo che sto cercando di raggiungere i più esperti. Qualsiasi avvertimento che potresti essere in grado di aiutarti sarà apprezzato.

    
posta Garet Claborn 02.10.2013 - 04:27
fonte

1 risposta

4

Le tue ipotesi sono per lo più sbagliate, perché non prendi in considerazione le codifiche come UTF-16be.

If you take a look at ASCII (or by virtue at UTF-8); the first 32 characters are control characters. This is pretty common for lots of reasons.

No. Succede che ASCII, Unicode codepoints e UTF-8 hanno tutti i caratteri di controllo nelle prime posizioni di 32 byte / punto di codice, ma questo per garantire la retrocompatibilità con ASCII! Ci sono molte altre codifiche che fanno anche questo, di solito codifiche a singolo byte.

Codici codificati UTF-16 (e predecessori) e UTF-32 con un minimo di 2 risp. 4 byte. In UTF-16be, una nuova riga è 00 0A , la lettera a è 00 7A - in UTF-16le, questa è 7A 00 .

Control characters for all covered character sets are in the first N bits, hopefully 4.

Haha, cosa? I caratteri di controllo non occupano determinati bit, di solito sono byte completi. Se stai intrattenendo l'idea che i personaggi di controllo siano sempre in un raggio chiuso all'inizio del tavolo di codifica, dovrò deluderti.

Ad esempio, il carattere di eliminazione U+007F codifica in ASCII e UTF-8 7F . Unicode ha caratteri di controllo negli intervalli U+0000 - U+001F e U+007F - U+009F . L'ultimo intervallo codifica su più byte in UTF-8 e non può essere rappresentato in ASCII.

The most frequently used characters and phrases in a localization are in a particular range smaller than 8 or 8-N bits, but may be contained neighboring bytes (depending on packing order).

Non capisco bene questa affermazione (grammatica ...). Se intendi che esiste un solo piccolo sottoinsieme di sequenze di byte che viene utilizzato principalmente in una determinata lingua, allora sei parzialmente corretto - la maggior parte dei writer si atterrà a uno specifico script. Tuttavia, considera quanto segue:

  • Alcuni di questi intervalli sono vasti. Prendi per esempio i caratteri cinesi. Unicode contiene migliaia di caratteri CJK.
  • Molti grafemi hanno rappresentazioni multiple. A seconda della normalizzazione Unicode, uno scrittore dell'Est europeo potrebbe produrre testo con caratteri da pochi intervalli di punti di riferimento, oppure può utilizzare la combinazione di segni diacritici.
  • Molti documenti non inglesi (specialmente sul Web) includeranno probabilmente anche caratteri latini.
  • Ci sono dozzine di codifiche a singolo byte che differiscono solo al di sopra dell'intervallo ASCII. Queste codifiche sono ancora ampiamente utilizzate e possono rendere impossibile rilevare la codifica effettiva. Confronta le codifiche Latin-1 con Latin-16.

{ control: 31, range: [65,122], print: [32,255] }

Questo è sbagliato per vari motivi, alcuni già menzionati. Dovresti capire che le codifiche che cercano di essere compatibili ASCII probabilmente non saranno compatibili tra loro sopra includendo 0x80 (vedi sopra). UTF-8 utilizza i byte in questo intervallo per codificare la lunghezza della sequenza di byte di questo punto di codice (in realtà solo alcuni bit, ma in questo modo i byte risultanti sono qui).

Il rilevamento della codifica può utilizzare le seguenti tecniche per trovare una possibile codifica:

  • Standard. Ad esempio, qualsiasi documento XML è UTF-8 fino a prova contraria.
  • Convenzioni. Windows-1252 è deprimentemente comune.
  • I contrassegni di ordine dei byte (BOM) possono identificare le codifiche UTF-16.
  • Esclusione. Molte codifiche hanno sequenze di byte illegali che non possono verificarsi (questo è particolarmente utile per escludere UTF-8). Anche nelle codifiche a byte singolo, alcuni byte non sono assegnati.
  • Caratteristiche uniche. Se ogni 2 byte è NUL, c'è una buona probabilità che stiamo vedendo UTF-16le (ma potremmo ancora sbagliare).
  • Statistiche che utilizzano informazioni esterne. Quali sono le probabilità che i dati provenienti dalla Francia utilizzino una codifica cinese?

Leggi l'articolo di Wikipedia su rilevamento charset per iniziare. Raccomando di utilizzare una soluzione esistente per il tuo progetto, ad es. chardet di Mozilla.

    
risposta data 02.10.2013 - 12:09
fonte