UTF-16 dovrebbe essere considerato dannoso?

Farò una domanda probabilmente controversa: "Una delle codifiche più popolari, UTF-16, dovrebbe essere considerata dannosa?"

Perché faccio questa domanda?

Quanti programmatori sono consapevoli del fatto che UTF-16 è in realtà una codifica a lunghezza variabile? Con questo intendo dire che ci sono punti di codice che, rappresentati come coppie surrogate, accettano più di un elemento.

Lo so; molte applicazioni, framework e API usano UTF-16, come String di Java, String di C #, API Win32, librerie Qt GUI, libreria Unicode ICU, ecc. Tuttavia, nonostante tutto, ci sono molti bug di base nell'elaborazione di caratteri al di fuori di BMP (caratteri che devono essere codificati utilizzando due elementi UTF-16).

Ad esempio, prova a modificare uno di questi caratteri:

• 𝄞 ( U + 1D11E ) SIMBOLO MUSICALE G CLEF
• 𝕥 ( U + 1D565 ) MATEMATICO DOPPIO CAMION PICCOLO T
• 𝟶 ( U + 1D7F6 ) ZERO DI MONOSPACE MATEMATICO
• 𠂊 ( U + 2008A ) Personaggio Han

Potresti perdere alcuni, a seconda dei caratteri che hai installato. Questi personaggi sono tutti al di fuori del BMP (Basic Multilingual Plane). Se non riesci a vedere questi personaggi, puoi anche provare a guardarli nel riferimento Carattere Unicode .

Ad esempio, prova a creare nomi di file in Windows che includano questi caratteri; prova a eliminare questi caratteri con uno "spazio indietro" per vedere come si comportano in diverse applicazioni che usano UTF-16. Ho fatto alcuni test e i risultati sono piuttosto negativi:

• Opera ha problemi con la loro modifica (elimina le 2 pressioni richieste sul backspace)
• Il Blocco note non è in grado di gestirli correttamente (eliminare le 2 pressioni richieste sul backspace)
• Modifica dei nomi dei file nelle finestre di dialogo interrotte (eliminazione delle 2 pressioni richieste sul backspace)
• Tutte le applicazioni QT3 non possono gestirle: mostra due quadrati vuoti invece di un simbolo.
• Python codifica questi caratteri in modo errato se utilizzato direttamente u'X'!=unicode('X','utf-16')su alcune piattaforme quando X in carattere al di fuori di BMP.
• L'unicodedata di Python 2.5 non riesce a ottenere proprietà su tali caratteri quando python viene compilato con stringhe Unicode UTF-16.
• StackOverflow sembra rimuovere questi caratteri dal testo se modificato direttamente come caratteri Unicode (questi caratteri sono mostrati usando escape Unicode HTML).
• WinForms TextBox può generare una stringa non valida se limitata con MaxLength.

Sembra che tali bug siano estremamente facili da trovare in molte applicazioni che utilizzano UTF-16.

Quindi ... Pensi che UTF-16 debba essere considerato dannoso?

Questa è una vecchia risposta.
Vedi UTF-8 Ovunque per gli ultimi aggiornamenti.

Opinione: Sì, UTF-16 dovrebbe essere considerato dannoso . Il vero motivo esiste perché qualche tempo fa c'era una convinzione errata che Widechar sarebbe quello che è UCS-4 ora.

Nonostante l '"anglo-centrismo" di UTF-8, dovrebbe essere considerato l'unica codifica utile per il testo. Si può sostenere che non dovrebbero mai esistere codici sorgente di programmi, pagine Web e file XML, nomi di file del sistema operativo e altre interfacce di testo da computer a computer. Ma quando lo fanno, il testo non è solo per i lettori umani.

D'altra parte, l'overhead UTF-8 è un piccolo prezzo da pagare mentre presenta vantaggi significativi. Vantaggi come la compatibilità con il codice inconsapevole che passa semplicemente con le stringhe char*. Questa è una grande cosa. Ci sono alcuni personaggi utili che sono PIÙ CORTI in UTF-16 rispetto a UTF-8.

Credo che alla fine moriranno tutte le altre codifiche. Ciò implica che MS-Windows, Java, ICU e Python smettano di usarlo come preferito. Dopo lunghe ricerche e discussioni, le convenzioni di sviluppo presso la mia azienda vietano l'utilizzo di UTF-16 ovunque tranne le chiamate API OS, e questo nonostante l'importanza delle prestazioni nelle nostre applicazioni e il fatto che utilizziamo Windows. Le funzioni di conversione sono state sviluppate per convertire gli UTF8 sempre assunti std::stringin UTF-16 nativo, che Windows stesso non supporta correttamente .

Alle persone che dicono " usa ciò che è necessario dove è necessario ", dico: c'è un enorme vantaggio nell'usare la stessa codifica ovunque, e non vedo motivi sufficienti per fare diversamente. In particolare, penso che l'aggiunta wchar_ta C ++ sia stata un errore, così come lo sono le aggiunte Unicode a C ++ 0x. Ciò che deve essere richiesto dalle implementazioni STL è che ogni std::stringo char*parametro sarebbe considerato compatibile con unicode.

Sono anche contrario all'approccio " usa quello che vuoi ". Non vedo alcun motivo per tale libertà. C'è abbastanza confusione sull'argomento del testo, risultante in tutto questo software rotto. Detto questo, sono convinto che i programmatori debbano finalmente raggiungere il consenso su UTF-8 come un modo corretto. (Vengo da un paese di lingua non ascii e sono cresciuto su Windows, quindi mi sarei aspettato per ultimo di attaccare UTF-16 per motivi religiosi).

Vorrei condividere maggiori informazioni su come scrivo il testo su Windows e su ciò che consiglio a tutti gli altri per la correttezza unicode verificata in fase di compilazione, la facilità d'uso e una migliore multipiattaforma del codice. Il suggerimento differisce sostanzialmente da quello che di solito è raccomandato come il modo corretto di usare Unicode su Windows. Tuttavia, la ricerca approfondita di queste raccomandazioni ha portato alla stessa conclusione. Quindi ecco qui:

• Non utilizzare wchar_to std::wstringin luoghi diversi dal punto adiacente alle API che accettano UTF-16.
• Non utilizzare _T("")o L""UTF-16 letterali (IMO Questi dovrebbero essere prese fuori dello standard, come una parte di UTF-16 disapprovazione).
• Non utilizzare tipi, funzioni o loro derivati ​​sensibili alla _UNICODEcostante, come LPTSTRo CreateWindow().
• Tuttavia, _UNICODEsempre definito, per evitare che le char*stringhe di passaggio a WinAPI vengano compilate silenziosamente
• std::stringse in char*qualsiasi parte del programma sono considerati UTF-8 (se non diversamente specificato)
• Tutte le mie stringhe sono std::string, anche se puoi passare char * o letter letter a convert(const std::string &).

• usa solo le funzioni Win32 che accettano widechars ( LPWSTR). Mai quelli che accettano LPTSTRo LPSTR. Passare i parametri in questo modo:

  ::SetWindowTextW(Utils::convert(someStdString or "string litteral").c_str())
  

  (La politica utilizza le funzioni di conversione di seguito.)

• Con stringhe MFC:

  CString someoneElse; // something that arrived from MFC. Converted as soon as possible, before passing any further away from the API call:
  
  std::string s = str(boost::format("Hello %s\n") % Convert(someoneElse));
  AfxMessageBox(MfcUtils::Convert(s), _T("Error"), MB_OK);
  

• Lavorare con file, nomi di file e fstream su Windows:

  • Non passare mai std::stringo const char*argomenti del nome file alla fstreamfamiglia. MSVC STL non supporta gli argomenti UTF-8, ma ha un'estensione non standard che dovrebbe essere utilizzata come segue:

  • Converti gli std::stringargomenti in std::wstringcon Utils::Convert:

    std::ifstream ifs(Utils::Convert("hello"),
                      std::ios_base::in |
                      std::ios_base::binary);
    

    Dovremo rimuovere manualmente la conversione, quando cambierà l'atteggiamento di MSVC nei confronti fstream.

  • Questo codice non è multipiattaforma e potrebbe essere necessario modificarlo manualmente in futuro
  • Vedi fstreamcaso di ricerca / discussione unicode 4215 per maggiori informazioni.
  • Non produrre mai file di output di testo con contenuto non UTF8
  • Evitare l'uso fopen()per motivi RAII / OOD. Se necessario, utilizzare le _wfopen()convenzioni WinAPI sopra.

// For interface to win32 API functions
std::string convert(const std::wstring& str, unsigned int codePage /*= CP_UTF8*/)
{
    // Ask me for implementation..
    ...
}

std::wstring convert(const std::string& str, unsigned int codePage /*= CP_UTF8*/)
{
    // Ask me for implementation..
    ...
}

// Interface to MFC
std::string convert(const CString &mfcString)
{
#ifdef UNICODE
    return Utils::convert(std::wstring(mfcString.GetString()));
#else
    return mfcString.GetString();   // This branch is deprecated.
#endif
}

CString convert(const std::string &s)
{
#ifdef UNICODE
    return CString(Utils::convert(s).c_str());
#else
    Exceptions::Assert(false, "Unicode policy violation. See W569"); // This branch is deprecated as it does not support unicode
    return s.c_str();   
#endif
}

I punti di codice Unicode non sono caratteri! A volte non sono nemmeno glifi (forme visive).

Qualche esempio:

• Codici numerici romani come "ⅲ". (Un singolo personaggio che assomiglia a "iii".)
• Personaggi accentati come "á", che possono essere rappresentati come un singolo carattere combinato "\ u00e1" o come carattere e segni diacritici separati "\ u0061 \ u0301".
• Caratteri come il sigma minuscolo greco, che hanno forme diverse per le posizioni delle parole medio ("σ") e fine ("ς"), ma che dovrebbero essere considerati sinonimi per la ricerca.
• Trattino discrezionale Unicode U + 00AD, che potrebbe essere visualizzato o meno visivamente, a seconda del contesto, e che viene ignorato per la ricerca semantica.

L'unico modo per ottenere correttamente l'editing Unicode è utilizzare una libreria scritta da un esperto o diventare un esperto e scriverne uno tu stesso. Se stai solo contando i punti di codice, stai vivendo in uno stato di peccato.

Esiste una semplice regola empirica su quale Unicode Transformation Form (UTF) utilizzare: - utf-8 per l'archiviazione e la comunicazione - utf-16 per l'elaborazione dei dati - potresti utilizzare utf-32 se la maggior parte dell'API della piattaforma che usi è utf-32 (comune nel mondo UNIX).

La maggior parte dei sistemi oggi utilizza utf-16 (Windows, Mac OS, Java, .NET, ICU, Qt). Vedi anche questo documento: http://unicode.org/notes/tn12/

Tornando a "UTF-16 come dannoso", direi: sicuramente no.

Le persone che hanno paura dei surrogati (pensando di trasformare Unicode in una codifica a lunghezza variabile) non comprendono le altre complessità (molto più grandi) che rendono molto complessa la mappatura tra caratteri e un codice Unicode: combinare caratteri, legature, selettori di variazioni , personaggi di controllo, ecc.

Basta leggere questa serie qui http://www.siao2.com/2009/06/29/9800913.aspx e vedere come UTF-16 diventa un problema facile.

Si assolutamente.

Perché? Ha a che fare con l' esercizio del codice .

Se guardi queste statistiche sull'utilizzo dei punti di codice su un corpus di grandi dimensioni di Tom Christiansen vedrai che i punti di codice BMP trans-8 bit vengono utilizzati più ordini se la grandezza è maggiore dei codici non BMP:

 2663710 U+002013 ‹–›  GC=Pd    EN DASH
 1065594 U+0000A0 ‹ ›  GC=Zs    NO-BREAK SPACE
 1009762 U+0000B1 ‹±›  GC=Sm    PLUS-MINUS SIGN
  784139 U+002212 ‹−›  GC=Sm    MINUS SIGN
  602377 U+002003 ‹ ›  GC=Zs    EM SPACE

 544 U+01D49E ‹𝒞›  GC=Lu    MATHEMATICAL SCRIPT CAPITAL C
 450 U+01D4AF ‹𝒯›  GC=Lu    MATHEMATICAL SCRIPT CAPITAL T
 385 U+01D4AE ‹𝒮›  GC=Lu    MATHEMATICAL SCRIPT CAPITAL S
 292 U+01D49F ‹𝒟›  GC=Lu    MATHEMATICAL SCRIPT CAPITAL D
 285 U+01D4B3 ‹𝒳›  GC=Lu    MATHEMATICAL SCRIPT CAPITAL X

Prendi il detto TDD: "Il codice non testato è un codice non funzionante" e riformulalo come "Il codice non esercitato è un codice non funzionante" e pensa a quanto spesso i programmatori devono gestire codici non BMP.

I bug relativi alla mancata gestione di UTF-16 come codifica a larghezza variabile hanno molte più probabilità di passare inosservati rispetto ai bug equivalenti in UTF-8 . Alcuni linguaggi di programmazione non garantiscono comunque di fornirti UTF-16 invece di UCS-2, e alcuni cosiddetti linguaggi di programmazione di alto livello offrono l'accesso a unità di codice anziché a punti di codice (anche C dovrebbe dare accesso a punti di codice se si utilizza wchar_t, indipendentemente da ciò che alcune piattaforme possono fare).

Suggerirei che pensare che UTF-16 possa essere considerato dannoso dice che è necessario acquisire una maggiore comprensione dell'unicode .

Dato che sono stato sottoposto a downgrade per aver presentato la mia opinione su una domanda soggettiva, mi permetta di elaborare. Cosa ti disturba esattamente di UTF-16? Preferiresti se tutto fosse codificato in UTF-8? UTF-7? O che dire di UCS-4? Naturalmente alcune applicazioni non sono progettate per gestire il codice dei caratteri di sempre, ma sono necessarie, soprattutto nel dominio dell'informazione globale di oggi, per la comunicazione tra i confini internazionali.

Ma davvero, se ritieni che UTF-16 debba essere considerato dannoso perché confuso o può essere implementato in modo improprio (unicode certamente può essere), quale metodo di codifica dei caratteri sarebbe considerato non dannoso?

EDIT: Per chiarire: Perché considerare le implementazioni improprie di uno standard riflettono la qualità dello standard stesso? Come altri hanno successivamente notato, semplicemente perché un'applicazione utilizza uno strumento in modo inappropriato, non significa che lo strumento stesso sia difettoso. Se così fosse, potremmo probabilmente dire cose come "var keyword considerata dannosa" o "threading considerato dannoso". Penso che la domanda confonda la qualità e la natura dello standard con le difficoltà che molti programmatori hanno nell'implementarlo e nell'usarlo correttamente, cosa che provengo più dalla loro mancanza di comprensione del funzionamento dell'unicode, piuttosto che dall'unicode stesso.

Non c'è nulla di sbagliato nella codifica Utf-16. Ma le lingue che trattano le unità a 16 bit come caratteri dovrebbero probabilmente essere considerate mal progettate. Avere un tipo chiamato ' char' che non rappresenta sempre un personaggio è piuttosto confuso. Poiché la maggior parte degli sviluppatori si aspetta che un tipo di carattere rappresenti un punto di codice o un carattere, molto probabilmente il codice si interromperà se esposto a caratteri oltre BMP.

Si noti tuttavia che anche l'uso di utf-32 non significa che ogni punto di codice a 32 bit rappresenterà sempre un carattere. A causa della combinazione di caratteri, un personaggio reale può essere costituito da diversi punti di codice. Unicode non è mai banale.

BTW. Esiste probabilmente la stessa classe di bug con piattaforme e applicazioni che prevedono caratteri a 8 bit, alimentati da Utf-8.

La mia scelta personale è quella di utilizzare sempre UTF-8. È lo standard su Linux per quasi tutto. È retrocompatibile con molte app legacy. Esiste un sovraccarico minimo in termini di spazio extra utilizzato per i caratteri non latini rispetto agli altri formati UTF e un notevole risparmio di spazio per i caratteri latini. Sul web, le lingue latine regnano sovrane e penso che lo faranno per il prossimo futuro. E per affrontare uno dei principali argomenti del post originale: quasi tutti i programmatori sono consapevoli del fatto che UTF-8 a volte avrà caratteri multi-byte. Non tutti lo affrontano correttamente, ma di solito sono consapevoli, il che è più di quanto si possa dire per UTF-16. Ma, ovviamente, devi scegliere quello più appropriato per la tua applicazione. Ecco perché ce n'è più di uno in primo luogo.

Bene, esiste una codifica che utilizza simboli di dimensioni fisse. Intendo sicuramente UTF-32. Ma 4 byte per ogni simbolo sono troppo spazio sprecato, perché dovremmo usarlo nelle situazioni quotidiane?

A mio avviso, la maggior parte dei problemi appare dal fatto che alcuni software sono rimasti indietro rispetto allo standard Unicode, ma non sono stati pronti a correggere la situazione. Opera, Windows, Python, Qt - tutti apparivano prima che UTF-16 diventasse ampiamente noto o addirittura venisse alla luce. Posso confermare, tuttavia, che in Opera, Esplora risorse e Blocco note non ci sono più problemi con i caratteri al di fuori di BMP (almeno sul mio PC). Ma comunque, se i programmi non riconoscono le coppie surrogate, allora non usano UTF-16. Qualunque problema sorga dalla gestione di tali programmi, non hanno nulla a che fare con UTF-16 stesso.

Tuttavia, penso che i problemi del software legacy con solo il supporto BMP siano in qualche modo esagerati. I personaggi al di fuori di BMP si incontrano solo in casi e aree molto specifici. Secondo le FAQ ufficiali Unicode , "anche nel testo dell'Asia orientale, l'incidenza delle coppie surrogate dovrebbe essere in media inferiore all'1% di tutto l'archiviazione del testo". Naturalmente, i caratteri al di fuori di BMP non dovrebbero essere trascurati perché un programma non è conforme a Unicode altrimenti, ma la maggior parte dei programmi non è progettata per lavorare con testi contenenti tali caratteri. Ecco perché se non lo supportano, è spiacevole, ma non una catastrofe.

Ora consideriamo l'alternativa. Se UTF-16 non esistesse, non avremmo una codifica adatta per il testo non ASCII e tutto il software creato per UCS-2 dovrebbe essere completamente riprogettato per rimanere conforme Unicode. Quest'ultimo molto probabilmente rallenterebbe solo l'adozione di Unicode. Inoltre non saremmo stati in grado di mantenere la compatibilità con il testo in UCS-2 come UTF-8 rispetto ad ASCII.

Ora, mettendo da parte tutti i problemi legati all'eredità, quali sono gli argomenti contro la codifica stessa? Dubito davvero che gli sviluppatori al giorno d'oggi non sappiano che UTF-16 è di lunghezza variabile, è scritto ovunque a partire da Wikipedia. UTF-16 è molto meno difficile da analizzare rispetto a UTF-8, se qualcuno ha indicato la complessità come un possibile problema. Inoltre è sbagliato pensare che sia facile sbagliare nel determinare la lunghezza della stringa solo in UTF-16. Se usi UTF-8 o UTF-32, dovresti comunque essere consapevole che un punto di codice Unicode non significa necessariamente un carattere. A parte questo, non penso che ci sia qualcosa di sostanziale contro la codifica.

Pertanto non penso che la codifica stessa debba essere considerata dannosa. UTF-16 è un compromesso tra semplicità e compattezza e non vi è alcun danno nell'uso di ciò che è necessario dove è necessario . In alcuni casi devi rimanere compatibile con ASCII e hai bisogno di UTF-8, in alcuni casi vuoi lavorare con il lavoro con gli ideogrammi Han e conservare lo spazio usando UTF-16, in alcuni casi hai bisogno di rappresentazioni universali di caratteri per indicare un fisso- codifica della lunghezza. Usa ciò che è più appropriato, fallo e basta.

Anni di lavoro sull'internazionalizzazione di Windows, specialmente nelle lingue dell'Asia orientale, potrebbero avermi corrotto, ma mi rivolgo a UTF-16 per le rappresentazioni di stringhe interne al programma e UTF-8 per l'archiviazione di file o di rete di documenti simili a testi in chiaro. UTF-16 di solito può essere elaborato più velocemente su Windows, quindi questo è il principale vantaggio dell'utilizzo di UTF-16 in Windows.

Fare il salto in UTF-16 ha migliorato notevolmente l'adeguatezza della media dei prodotti che gestiscono il testo internazionale. Ci sono solo alcuni casi ristretti in cui le coppie surrogate devono essere considerate (eliminazioni, inserzioni e interruzione di linea, in sostanza) e il caso medio è per lo più passante diretto. E a differenza delle codifiche precedenti come le varianti JIS, UTF-16 limita le coppie surrogate a un intervallo molto ristretto, quindi il controllo è molto rapido e funziona avanti e indietro.

Certo, è più o meno veloce anche in UTF-8 correttamente codificato. Ma ci sono anche molte applicazioni UTF-8 rotte che codificano erroneamente coppie surrogate come due sequenze UTF-8. Quindi UTF-8 non garantisce neanche la salvezza.

IE gestisce le coppie di surrogati ragionevolmente bene dal 2000 circa, anche se in genere le sta convertendo da pagine UTF-8 in una rappresentazione UTF-16 interna; Sono abbastanza sicuro che anche Firefox abbia capito bene, quindi non mi interessa davvero cosa fa Opera.

UTF-32 (aka UCS4) è inutile per la maggior parte delle applicazioni poiché è così esigente in termini di spazio, quindi è praticamente un non avviatore.

UTF-8 è sicuramente la strada da percorrere, eventualmente accompagnata da UTF-32 per uso interno in algoritmi che richiedono un accesso casuale ad alte prestazioni (ma che ignora la combinazione di caratteri).

Sia UTF-16 che UTF-32 (così come le loro varianti LE / BE) soffrono di problemi di endianess, quindi non dovrebbero mai essere usati esternamente.

UTF-16? decisamente dannoso. Solo il mio granello di sale qui, ma ci sono esattamente tre codifiche accettabili per il testo in un programma:

• ASCII: quando si tratta di cose di basso livello (es. Microcontrollori) che non possono permettersi di meglio
• UTF8: archiviazione in supporti a larghezza fissa come file

• codici interi ("CP"?): un array dei numeri interi più grandi che sono convenienti per il tuo linguaggio di programmazione e la tua piattaforma (decade in ASCII nel limite delle risorse basse). Dovrebbe essere int32 su computer più vecchi e int64 su qualsiasi cosa con indirizzamento a 64 bit.

• Ovviamente le interfacce per il codice legacy utilizzano la codifica necessaria per far funzionare correttamente il vecchio codice.

Unicode definisce i punti di codice fino a 0x10FFFF (1.114.112 codici), tutte le applicazioni in esecuzione in un ambiente multilingue che si occupa di stringhe / nomi di file ecc. Dovrebbero gestirlo correttamente.

Utf-16 : copre solo 1.112.064 codici. Sebbene quelli alla fine di Unicode provengano dagli aerei 15-16 (area di uso privato). Non può crescere ulteriormente in futuro se non rompendo il concetto di Utf-16 .

Utf-8 : copre teoricamente 2.216.757.376 codici. L'intervallo corrente di codici Unicode può essere rappresentato da una sequenza massima di 4 byte. Non ha problemi di ordine dei byte , è "compatibile" con ASCII.

Utf-32 : copre teoricamente 2 ^ 32 = 4.294.967.296 codici. Attualmente non è codificato a lunghezza variabile e probabilmente non lo sarà in futuro.

Questi fatti si spiegano da soli. Non capisco a favore dell'uso generale di Utf-16 . È codificato a lunghezza variabile (non è possibile accedervi tramite indice), ha problemi a coprire l'intero intervallo Unicode anche al momento, l'ordine dei byte deve essere gestito, ecc. Non vedo alcun vantaggio se non che è usato nativamente in Windows e in alcuni altri posti. Anche se durante la scrittura di codice multipiattaforma è probabilmente meglio usare Utf-8 in modo nativo e fare conversioni solo agli end point in modo dipendente dalla piattaforma (come già suggerito). Quando è necessario l'accesso diretto tramite indice e la memoria non è un problema, è necessario utilizzare Utf-32 .

Il problema principale è che molti programmatori che si occupano di Windows Unicode = Utf-16 non sanno nemmeno o ignorano il fatto che è codificato a lunghezza variabile.

Il modo in cui è normalmente nella piattaforma * nix è abbastanza buono, le stringhe c (char *) interpretate come codificate Utf-8 , le stringhe c larghe (wchar_t *) interpretate come Utf-32 .

Aggiungi questo alla lista:

Lo scenario presentato è semplice (anche più semplice di come lo presenterò qui di quanto non fosse in origine!): 1.A WinForms TextBox si trova su un modulo, vuoto. Ha una lunghezza massima impostata su 20 .

2.L'utente digita nella TextBox o forse incolla il testo in essa.

3.Non importa che cosa digiti o incolli nella TextBox, sei limitato a 20, anche se emetterà simpaticamente un segnale di testo oltre i 20 (YMMV qui; ho cambiato il mio schema sonoro per darmi quell'effetto!).

4. Il piccolo pacchetto di testo viene quindi inviato da qualche altra parte, per iniziare un'avventura emozionante.

Questo è uno scenario semplice e chiunque può scriverlo nel tempo libero. L'ho scritto da solo in più linguaggi di programmazione usando WinForms, perché ero annoiato e non l'avevo mai provato prima. E con il testo in più lingue effettive perché sono cablato in quel modo e ho più layout di tastiera di chiunque altro nell'intero universo.

Ho anche chiamato la forma Magic Carpet Ride , per aiutare a migliorare la noia.

Questo non ha funzionato, per quello che vale.

Quindi, invece, ho inserito i seguenti 20 caratteri nel mio modulo Magic Carpet Ride :

0123401234012340123 𠀀

Uh Oh.

Quest'ultimo personaggio è U + 20000, il primo ideografo Extension B di Unicode (aka U + d840 U + dc00, per i suoi amici intimi di cui non si vergogna di essere travestito, per così dire, di fronte) ....

E ora abbiamo una partita a baseball.

Perché quando parla TextBox.MaxLength

Ottiene o imposta il numero massimo di caratteri che è possibile immettere manualmente nella casella di testo.

ciò che significa veramente è

Ottiene o imposta il numero massimo di unità di codice LE UTF-16 che possono essere inserite manualmente nella casella di testo e troncerà senza pietà la schifezza vivente di qualsiasi stringa che tenta di giocare a giochi carini con l'idea di carattere linguistico che solo qualcuno ossessionato come quel compagno Kaplan troverà offensivo (accidenti ha bisogno di uscire di più!).

Proverò a vedere come aggiornare il documento ....
I lettori abituali che ricordano le mie serie da UCS-2 a UTF-16 noteranno la mia infelicità con la nozione semplicistica di TextBox.MaxLength e come dovrebbe gestire almeno questo caso dove il suo comportamento draconiano crea una sequenza illegale, quella che altre parti del Framework .Net possono lanciare a

• System.Text.EncoderFallbackException: impossibile tradurre il carattere Unicode \ uD850 all'indice 0 nella tabella codici specificata. *

eccezione se si passa questa stringa altrove nel .Net Framework (come stava facendo il mio collega Dan Thompson).

Ora va bene, forse l'intera serie da UCS-2 a UTF-16 è fuori dalla portata di molti.
Ma non è ragionevole aspettarsi che TextBox.Text non produca System.Stringche non provocherà il lancio di un altro pezzo di .Net Framework? Voglio dire, non è che ci sia una possibilità sotto forma di un evento sul controllo che ti dice dell'imminente troncamento in cui puoi facilmente aggiungere la convalida più intelligente - convalida che il controllo stesso non si preoccupa di fare. Vorrei arrivare al punto di dire che questo controllo punk sta infrangendo un contratto di sicurezza che potrebbe anche portare a problemi di sicurezza se si può classificare causando eccezioni impreviste per terminare un'applicazione come una sorta di negazione del servizio. Perché qualsiasi processo o metodo o algoritmo o tecnica WinForms dovrebbe produrre risultati non validi?

Fonte: Blog su Michael S. Kaplan MSDN

Non direi necessariamente che UTF-16 è dannoso. Non è elegante, ma serve al suo scopo di retrocompatibilità con UCS-2, proprio come GB18030 fa con GB2312 e UTF-8 fa con ASCII.

Ma apportare una modifica fondamentale alla struttura di Unicode a metà flusso, dopo che Microsoft e Sun avevano creato enormi API attorno a caratteri a 16 bit, era dannoso. L'incapacità di diffondere la consapevolezza del cambiamento era più dannosa.

UTF-16 è il miglior compromesso tra gestione e spazio ed è per questo che la maggior parte delle piattaforme principali (Win32, Java, .NET) lo usano per la rappresentazione interna delle stringhe.

Non ho mai capito il punto di UTF-16. Se si desidera la rappresentazione più efficiente in termini di spazio, utilizzare UTF-8. Se vuoi essere in grado di trattare il testo come lunghezza fissa, usa UTF-32. Se non si desidera nessuno dei due, utilizzare UTF-16. Peggio ancora, dal momento che tutti i caratteri comuni (piano multilingue di base) in UTF-16 rientrano in un singolo punto di codice, i bug che presuppongono che UTF-16 sia di lunghezza fissa saranno sottili e difficili da trovare, mentre se si tenta di farlo questo con UTF-8, il tuo codice fallirà velocemente e ad alta voce non appena proverai a internazionalizzare.

_{Dal momento che non posso ancora commentare, inserisco questo come una risposta, dal momento che sembra che non potrei altrimenti contattare gli autori di utf8everywhere.org. È un peccato che non ottengo automaticamente il privilegio di commento, poiché ho abbastanza reputazione su altri cambi di stack.}

Ciò si intende come un commento al parere: Sì, UTF-16 dovrebbe essere considerata una risposta dannosa .

Una piccola correzione:

Per evitare che uno passi accidentalmente un UTF-8 char*nelle versioni di stringa ANSI delle funzioni dell'API di Windows, si dovrebbe definire UNICODE, no _UNICODE. _UNICODEfunzioni come mappe _tcslenper wcslen, non MessageBoxa MessageBoxW. Invece, il UNICODEdefine si occupa di quest'ultimo. Per prova, questo è dall'intestazione di MS Visual Studio 2005 WinUser.h:

#ifdef UNICODE
#define MessageBox  MessageBoxW
#else
#define MessageBox  MessageBoxA
#endif // !UNICODE

Come minimo, questo errore dovrebbe essere corretto utf8everywhere.org.

Un consiglio:

Forse la guida dovrebbe contenere un esempio di uso esplicito della versione a stringa larga di una struttura di dati, per rendere meno facile perdere / dimenticare. L'uso di versioni di stringhe di strutture dati oltre all'uso di versioni di stringhe di funzioni rende ancora meno probabile che si chiami accidentalmente una versione di stringa ANSI di tale funzione.

Esempio dell'esempio:

WIN32_FIND_DATAW data; // Note the W at the end.
HANDLE hSearch = FindFirstFileW(widen("*.txt").c_str(), &data);
if (hSearch != INVALID_HANDLE_VALUE)
{
    FindClose(hSearch);
    MessageBoxW(nullptr, data.cFileName, nullptr, MB_OK);
}

Qualcuno ha detto che UCS4 e UTF-32 erano uguali. No, ma so cosa intendi. Uno di questi è una codifica dell'altro, però. Vorrei che avessero pensato di specificare l'endianità dal primo in modo che non avremmo combattuto la battaglia dell'endianità anche qui. Non avrebbero potuto vederlo arrivare? Almeno UTF-8 è lo stesso ovunque (a meno che qualcuno non stia seguendo le specifiche originali con 6 byte).

Se si utilizza UTF-16 si deve includere la gestione per i caratteri multibyte. Non puoi andare all'ennesimo carattere indicizzando 2N in un array di byte. Devi percorrerlo o avere indici di caratteri. Altrimenti hai scritto un bug.

L'attuale bozza delle specifiche di C ++ afferma che UTF-32 e UTF-16 possono avere varianti little-endian, big-endian e non specificate. Veramente? Se Unicode avesse specificato che tutti dovevano fare little-endian sin dall'inizio, sarebbe stato tutto più semplice. (Sarei andato bene anche con il big-endian.) Invece, alcune persone l'hanno implementato in un modo, un altro e ora siamo bloccati con la stupidità per niente. A volte è imbarazzante essere un ingegnere del software.

Non penso che sia dannoso se lo sviluppatore è abbastanza attento.
E dovrebbero accettare questo compromesso se lo sanno anche bene.

Come sviluppatore di software giapponese, trovo UCS-2 abbastanza grande e limitare lo spazio apparentemente semplifica la logica e riduce la memoria di runtime, quindi usare utf-16 sotto la limitazione di UCS-2 è abbastanza buono.

Esistono file system o altre applicazioni che presuppongono che i punti di codice e i byte siano proporzionali, in modo che il numero di punti di codice non elaborati possa essere adattato a un archivio di dimensioni fisse.

Un esempio è NTFS e VFAT che specifica UCS-2 come codifica di archiviazione del nome file.

Se quell'esempio vuole davvero estendersi per supportare UCS-4, potrei essere d'accordo usando utf-8 per tutto comunque, ma la lunghezza fissa ha buoni punti come:

1. può garantire la dimensione in base alla lunghezza (la dimensione dei dati e la lunghezza del punto di codice sono proporzionali)
2. può utilizzare il numero di codifica per la ricerca hash
3. i dati non compressi sono di dimensioni ragionevoli (rispetto a utf-32 / UCS-4)

In futuro, quando la potenza di memoria / elaborazione sarà economica anche in tutti i dispositivi incorporati, potremmo accettare che il dispositivo sia un po 'lento per mancamenti di cache aggiuntivi o guasti di pagina e utilizzo di memoria extra, ma questo non accadrà nel prossimo futuro immagino ...

"Una delle codifiche più popolari, UTF-16, dovrebbe essere considerata dannosa?"

Molto probabilmente, ma le alternative non dovrebbero necessariamente essere considerate molto migliori.

Il problema fondamentale è che ci sono molti concetti diversi su: glifi, caratteri, punti di codice e sequenze di byte. Il mapping tra ciascuno di questi è non banale, anche con l'aiuto di una libreria di normalizzazione. (Ad esempio, alcuni caratteri in lingue europee che sono scritti con una scrittura latina non sono scritti con un singolo punto di codice Unicode. E questo è alla fine più semplice della complessità!) Ciò che significa che ottenere tutto corretto è abbastanza sorprendente difficile; ci si aspettano bizzarri bug (e invece di lamentarsi qui, informa i manutentori del software in questione).

L'unico modo in cui UTF-16 può essere considerato dannoso al contrario, diciamo, UTF-8 è che ha un modo diverso di codificare punti di codice al di fuori del BMP (come una coppia di surrogati). Se il codice desidera accedere o scorrere per punto di codice, significa che deve essere consapevole della differenza. OTOH, significa che un corpus sostanziale di codice esistente che assume "caratteri" può sempre adattarsi a una quantità di due byte - un presupposto abbastanza comune, se sbagliato, può almeno continuare a funzionare senza ricostruire tutto. In altre parole, almeno riesci a vedere quei personaggi che non vengono gestiti bene!

Vorrei rovesciare la tua domanda e dire che l'intero maledetto shebang di Unicode dovrebbe essere considerato dannoso e tutti dovrebbero usare una codifica a 8 bit, tranne che ho visto (negli ultimi 20 anni) dove questo porta: orribile confusione sulle varie codifiche ISO 8859, oltre all'intero set di quelle utilizzate per il cirillico, e la suite EBCDIC, e ... beh, Unicode per tutti i suoi difetti batte questo. Se non fosse stato un brutto compromesso tra incomprensioni di diversi paesi.