Domanda

Quasi 5 anni fa Joel Spolsky scrisse questo articolo, "Il minimo assoluto che ogni sviluppatore di software deve assolutamente conoscere in merito a Unicode e ai set di caratteri (nessuna scusa!)".

Come molti, l'ho letto attentamente, rendendomi conto che era giunto il momento di fare i conti con questo "sostituto di ASCII".Sfortunatamente, 5 anni dopo, sento di essere ricaduto in alcune cattive abitudini in questo settore.Hai?

Non scrivo molte applicazioni specificamente internazionali, tuttavia ho contribuito a creare molti siti Web ASP.NET con connessione Internet, quindi immagino che non sia una scusa.

Quindi, a mio vantaggio (e credo di molti altri) posso ottenere qualche input dalle persone su quanto segue:

  • Come "superare" l'ASCII una volta per tutte
  • Guida fondamentale quando si lavora con Unicode.
  • Libri e siti Web (recenti) consigliati su Unicode (per sviluppatori).
  • Stato attuale di Unicode (5 anni dopo l'articolo di Joels)
  • Direzioni future.

Devo ammettere che ho un background .NET e quindi sarei felice anche di avere informazioni su Unicode nel framework .NET.Naturalmente questo non dovrebbe impedire a chiunque abbia un background diverso di commentare.

Aggiornamento:Vedere questa domanda correlata chiesto anche su StackOverflow in precedenza.

È stato utile?

Soluzione

Da quando ho letto l'articolo su Joel e alcuni altri articoli su I18n ho sempre tenuto d'occhio la codifica dei miei caratteri;E funziona davvero se lo fai in modo coerente.Se lavori in un'azienda in cui è standard utilizzare UTF-8 e tutti lo sanno / lo fanno, funzionerà.

Ecco alcuni articoli interessanti (oltre all'articolo di Joel) sull'argomento:

Una citazione dal primo articolo;Suggerimenti per l'utilizzo di Unicode:

  • Abbraccia Unicode, non combatterlo;probabilmente è la cosa giusta da fare, e se non lo fosse probabilmente dovresti farlo comunque.
  • All'interno del software, memorizza il testo come UTF-8 o UTF-16;vale a dire, scegli uno dei due e mantienilo.
  • Interscambiare dati con il mondo esterno utilizzando XML quando possibile;questo fa sparire un sacco di potenziali problemi.
  • Prova a rendere la tua applicazione basata su browser anziché scrivere il tuo client;i browser stanno diventando davvero bravi a gestire i testi del mondo.
  • Se stai utilizzando il codice della libreria di qualcun altro (e ovviamente lo sei), presumi che la sua gestione Unicode sia interrotta finché non viene dimostrata corretta.
  • Se stai effettuando una ricerca, prova ad affidare i problemi linguistici e di gestione dei caratteri a qualcuno che li capisca.
  • Vai su Amazon o da qualche altra parte e acquista l'ultima revisione dello standard Unicode stampato;contiene abbastanza bene tutto quello che devi sapere.
  • Trascorri un po' di tempo curiosando nel sito web Unicode e imparando come funzionano i grafici dei codici.
  • Se hai intenzione di lavorare seriamente con le lingue asiatiche, vai a comprare il libro O'Reilly sull'argomento di Ken Lunde.
  • Se hai un Macintosh, corri e prendi lo strumento di ispezione dei caratteri Unicode di Lord Pixel.Assolutamente fantastico.
  • Se proprio devi sporcarti i dati, vai a partecipare a una delle conferenze Unicode che si tengono due volte l'anno.Vanno tutti gli esperti e se non sai quello che ti serve sapere, lì troverai qualcuno che lo sa.

Altri suggerimenti

Ho passato un po' di tempo a lavorare con il software dei motori di ricerca: non crederesti quanti siti web offrono contenuti con intestazioni HTTP o meta tag che mentono sulla codifica delle pagine.Spesso riceverai persino un documento che contiene sia caratteri ISO-8859 che caratteri UTF-8.

Dopo aver affrontato alcuni di questi tipi di problemi, inizi a prendere davvero sul serio la corretta codifica dei caratteri dei dati che produci.

.NET Framework utilizza la codifica predefinita di Windows per l'archiviazione delle stringhe, che risulta essere UTF-16.Se non specifichi una codifica quando usi la maggior parte delle classi I/O di testo, scriverai UTF-8 senza BOM e leggerai controllando prima una BOM e poi assumendo UTF-8 (lo so per certo StreamReader E StreamWriter comportarsi in questo modo.) Questo è abbastanza sicuro per gli editor di testo "stupidi" che non capiscono una distinta base ma un po' rozzo per quelli più intelligenti che potrebbero visualizzare UTF-8 o la situazione in cui stai effettivamente scrivendo caratteri al di fuori dell'intervallo ASCII standard .

Normalmente questo è invisibile, ma può alzare la testa in modi interessanti.Ieri stavo lavorando con qualcuno che utilizzava la serializzazione XML per serializzare un oggetto in una stringa utilizzando a StringWriter, e non riusciva a capire perché la codifica fosse sempre UTF-16.Poiché una stringa in memoria sarà UTF-16 e viene applicata da .NET, questa è l'unica cosa che il framework di serializzazione XML può fare.

Pertanto, quando scrivo qualcosa che non è solo uno strumento usa e getta, specifico una codifica UTF-8 con una distinta base.Tecnicamente in .NET sarai sempre accidentalmente a conoscenza di Unicode, ma solo se il tuo utente sa rilevare la tua codifica come UTF-8.

Mi fa piangere un po 'ogni volta che vedo qualcuno chiedere: "Come posso ottenere i byte di una stringa?" e la soluzione suggerita usa Encoding.ASCII.GetBytes() :(

Regola del pollice:se non mungerai mai o non guarderai mai all'interno di una stringa e la tratterai invece rigorosamente come un blob di dati, starai molto meglio.

Anche fare qualcosa di semplice come dividere le parole o ridurre in minuscolo le stringhe diventa difficile se vuoi farlo "nel modo Unicode".

E se vuoi farlo "alla maniera Unicode", avrai bisogno di una libreria terribilmente buona.Questa roba è incredibilmente complessa.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top