Differenziazione tra ASCII e Unicode in File Spec

Question

Differenziazione tra ASCII e Unicode in File Spec

#1 da (4 voti)

2

Sto sviluppando rispetto a una specifica di file che elenca il tipo di dati per determinati campi come

CHAR(<length>)

La specifica è per un file flat a larghezza fissa. Nella maggior parte dei casi, i valori possibili per popolare i campi sono evidenti (o delineati in un elenco di scelte, o semplicemente alfabetici / numerici per impostazione). Uno dei campi memorizza un messaggio di errore, che viene popolato dall'altra parte in base al comportamento del proprio sistema; potrebbe essere specificato in un modo un po '"a mano libera".

Vorrei fare l'ipotesi che questi dati saranno archiviati come testo ASCII (allo scopo di impostare strutture di dati). C'è un modo per garantire che il file non contenga dati Unicode in questo campo, in base al campo che viene specificato come semplicemente CHAR (100)?

Nota: Vengo da uno sfondo di SQL Server, dove userei CHAR per ASCII e NCHAR per Unicode - Mi chiedo se c'è un modo simile per specificare la differenza quando si crea un documento di interfaccia.

unicode specifications data-types character-encoding ascii

posta mathewb 22.08.2018 - 19:11

fonte

1 risposta

Leggi altre domande sui tag unicode specifications data-types character-encoding ascii

Internazionalizzazione API .NET Core: utilizzo di Visual Studio e mantenimento della stessa piattaforma

score 4 · Answer 1

Quando si discute un formato di file, è importante essere chiari sulla codifica:

Stiamo descrivendo il formato del file in termini di byte (ottetti) o in termini di testo decodificato?
Per un formato binario, qual è l'ordine dei byte per i numeri a più byte o le codifiche Unicode con unità di codice multibyte?
Per un formato testuale, come viene comunicata la codifica del file?

Un "carattere" può significare qualsiasi cosa da un byte (ottetto), un carattere ASCII a 7 bit, un'unità di codice UTF16, un punto di codice Unicode o, talvolta, persino un grafo grafo.

Per un formato binario, l'interpretazione come ottetto / byte è probabilmente appropriata. Un ottetto può rappresentare caratteri non ASCII. Potrebbe non essere possibile decodificare gli ottetti in modo significativo a meno che la loro codifica non sia specificata da qualche parte.
Per un formato testuale, tutto dipende dalla codifica. Di solito si tratta di una codifica a singolo byte come CP-1252 o una codifica Unicode a lunghezza variabile come UTF-8. In entrambi i casi, questo può rappresentare caratteri non ASCII.

Quindi, in entrambi i casi, non è positivo presumere che non vedrete mai caratteri non ASCII in quel campo.