Ragioni tecniche per preferire la logica di business di codifica per supportare Unicode (quando non richiesto)

In realtà puoi avere entrambi. Unicode supporta una codifica in cui tutti i caratteri sono rappresentati come una sequenza (di lunghezza variabile) di unità a 8 bit: UTF-8.

Supponendo che tu ti riferisca ad ASCII con i tuoi "chars 8 bit vecchio stile", allora puoi quasi banalmente supportare UTF-8, perché UTF-8 è un superset appropriato di ASCII: Tutti i caratteri nel 7 bit originale I set ASCII sono presenti in UTF-8 con lo stesso valore di codice. I caratteri nei vari set 'ASCII estesi' (così come il resto dei caratteri in Unicode) sono codificati come valori multi-byte. Questa codifica viene eseguita in modo tale che per ogni singolo byte è possibile stabilire se rappresenta 1) un carattere a byte singolo, 2) l'inizio di un carattere multi-byte o 3) un altro byte in un carattere a più byte.

L'unica area su cui prestare attenzione quando si passa da ASCII (o altre codifiche a lunghezza fissa) a UTF-8 (e Unicode in generale) è l'elaborazione di testo / stringa. Siccome UTF-8 (e Unicode in generale) non usano codifiche a lunghezza fissa, qualsiasi algoritmo che presuppone una codifica a lunghezza fissa può facilmente dare risultati errati.

Are there any technical reasons to reject keeping the business logic part of an application ignorant of Unicode like this?

1. Anche se sei ragionevolmente certo che il tuo sistema non ha bisogno di Unicode (ora), non vedo ciò che guadagni impedendoglielo. A meno che tu non stia usando un ambiente con il supporto orribile di Unicode, immagino che sarà più un lavoro da seguire.
   • E anche se veramente non ne hai mai bisogno, probabilmente la maggior parte delle altre persone vedrà questa risposta.
2. È probabile che si verifichi un problema di prestazioni durante la transizione tra le codifiche al limite UI / BL.
3. Potrebbero esserci problemi di serializzazione per la transizione tra le codifiche in base al trasporto di confine.

And even if the "natural language" of the system were "English-without-too-many-strings-or-dates" rather than Chemistry, would that make a difference?

Certo. In qualcosa di simile a una scienza fisica in cui i documenti e le discussioni avvengono tutti in inglese (vero?), Si può essere ragionevolmente certi che nessuno arriverà e richiederà la localizzazione nella vita del software. Nel software "Inglese con poche stringhe", il successo porterà probabilmente a società non inglesi che desiderano utilizzare l'applicazione, portando a richieste di localizzazione.

La risposta di Telastyn ha già dei buoni punti, a cui voglio aggiungere alcuni:

Parli di internazionalizzazione, almeno per l'interfaccia utente. Ciò significa nomi utente ecc .:
Avere un utente chiamato André Svónögrödäß (si, lui) e memorizzare il suo profilo sul server: BOINK! traduzioni e trascrizioni ovunque, o dirgli che il suo nome è "sbagliato", mentre l'altro 99,9% dei software nel mondo accetta il suo nome.

Inoltre: puoi garantire al 110% che nessun dato aziendale in tutto il mondo dipenderà mai da Unicode?
Scommetterei il costo di implementarlo ora con un leggero rischio di non davvero che ne ha bisogno rispetto al costo di implementazione quando gli utenti iniziano a lamentarsi.

Non sono sicuro che mi piaccia questa risposta, e anche se è la mia, non la preferirò. Ma non posso escludere nella mia mente che è una buona cosa da fare in alcune situazioni, quindi lo offrirò.

Se hai visto il film "Gravity", avrai visto il personaggio di Sandra Bullock mentre cerca di controllare una navicella i cui controlli sono etichettati in russo. Ma quei controlli potrebbero essere ugualmente etichettati con numeri. Ora sarebbe del tutto possibile scrivere il tipo di manuale utente utilizzato nel film in qualsiasi lingua, riferendosi solo ai numeri dei controlli. In effetti, queste etichette di controllo potrebbero essere tutte piccoli display che visualizzano un numero fino a quando non viene identificata una lingua, a quel punto potrebbero visualizzare etichette appropriate alla lingua.

Quindi ecco l'intero punto dell'esempio: non importa come cambi le etichette, il veicolo spaziale continuerà a volare lo stesso. (Inoltre, è utile che si tratti di un esempio non "incentrato sull'inglese" per fondere questo in).

La mia domanda (e questa risposta) deriva dal riconoscere che ci sono alcune applicazioni per situazioni come questa (come il controllo del processo di produzione e il monitoraggio) in cui l'applicazione essenziale (o l'astronave in questo esempio) non è conforme normale modello "database / business logic / UI" di fare le cose. Invece, forse un modello di "macchina di stato / impresa e-o logica di processo / interfaccia utente / database" ha più senso.

Cioè, miriamo tutti al "sacro graal" della separazione tra l'interfaccia utente e la logica aziendale ... ma poi ci ostacoliamo in tale sforzo memorizzando elementi nel database che non sono essenziali per la logica di business in il minimo Ma in quale altro posto dovremmo archiviarli se esiste un solo database ed è accessibile solo tramite la business logic?

Quindi forse c'è un caso da fare (in certe applicazioni che lo soddisfano) per mantenere la logica di business indipendente dal database che supporta l'interfaccia utente e l'interfaccia utente indipendente dal database (o macchina di stato) che supporta l'azienda logica.

Ciò consentirebbe alla logica aziendale di essere scritta in un linguaggio più naturale (che può essere FORTRAN, diagrammi ladder PLC, LISP, "Chimica", ecc. e che potrebbe essere un linguaggio terribile per scrivere un'interfaccia utente) durante la scrittura un'interfaccia utente per più lingue e / o dispositivi in qualcosa che è adatto a tale scopo.

Come ho detto, non sono sicuro che mi piaccia questa soluzione, ma posso vedere le situazioni in cui vale la pena considerarlo.