Ich entwerfe ein neues CMS, aber ich möchte es so gestalten, dass es all meinen zukünftigen Anforderungen wie mehrsprachigem Inhalt entspricht. Daher dachte ich, dass Unicode (UTF-8) die beste Lösung ist.
Aber mit etwas Suche habe ich diesen Artikel
Ich bin jetzt verwirrt, was ich jetzt benutzen soll UTF-8 / UTF-16 / UTF-32 / UCS-2
was für mehrsprachige Inhalte und Leistung besser ist.
PS: Ich benutze Asp.net und c # und SqlServer 2005
Vielen Dank im Voraus
Dies ist kein Problem, weil Sie sagen:
Ich benutze Asp.net und c # und SqlServer 2005
SqlServer verwendet UTF-16 an einigen Stellen (ntext, nvarchar, nchar) und UTF-8 an einigen wenigen XML-zentrierten Stellen, ohne dass Sie etwas Seltsames tun.
C # verwendet UTF-16 in all seinen Strings, mit Werkzeugen zum Codieren, wenn es um Streams und Dateien geht, die uns auf ... bringen.
ASP.NET verwendet standardmäßig UTF-8, und es ist schwer, an eine Zeit zu denken, in der es keine gute Wahl ist (selbst bei asiatischen Sprachen, die textliche Prägnanz solcher Sprachen kombiniert mit der Tatsache, dass die Namen und Symbole mit besonderer Bedeutung in HTML, CSS, Javascript, die meisten XML-Anwendungen und andere Streams, die Sie senden werden aus dem Bereich U + 0000 bis U + 007F, macht den Vorteil von UTF-16 über UTF-8 in diesem Bereich weniger signifikant als mit Klartext asiatischer Sprachen).
Das Sprechen zwischen dem UTF-16 von SqlServer und C # und dem UTF-8, das ASP.NET beim Lesen und Schreiben macht, ist für Sie mit den Standardeinstellungen erledigt, aber da dies das eine Bit ist, das Sie leicht ändern können, Meine Antwort wäre daher, UTF-8 zu verwenden. Wirklich, Sie werden eine Mischung aus -8 und -16 verwenden, aber Sie werden die meiste Zeit nicht bemerken (haben Sie bemerkt, dass Sie das schon getan haben).
SQL Server ist ein wenig weniger fehlerverzeihend, schon allein deshalb, weil bei vielen veralteten Beispielen Text für den menschlichen Verzehr erwartet wird, der in die Felder varchar, text oder char gesetzt wird. Verwenden Sie diese rein für Codes (zB liegen alle ISO-Ländercodes im Bereich von char (2), also würde nchar (2) nur Platz verschwenden) und nur nvarchar, ntext und nchar für Dinge, die Menschen statt Maschinen lesen und schreiben.
Ich bin jetzt verwirrt, was ich jetzt benutzen soll UTF-8 / UTF-16 / UTF-32 / UCS-2
was ist besser für mehrsprachig Inhalt und Leistung etc.
UCS-2 ist veraltet: Es kann nicht mehr jedes Unicode-Zeichen darstellen. UTF-8, UTF-16 und UTF-32 können alle. Aber warum gibt es drei verschiedene Möglichkeiten, die gleichen Zeichen zu kodieren?
Weil Programmierer früher zwei große Annahmen über Strings getroffen haben.
Das Problem für mehrsprachigen Text (oder sogar für einsprachigen Text, wenn diese Sprache zufällig Chinesisch, Japanisch oder Koreanisch ist) besteht darin, dass diese beiden Annahmen Sie auf 256 Zeichen beschränken. Wenn Sie mehr als das darstellen müssen, müssen Sie eine der Annahmen löschen.
Wenn Sie die Annahme # 1 beibehalten und die Annahme # 2 ablehnen, erhalten Sie eine variable Breite (oder Multi-Byte ) Codierung . Heute ist die beliebteste Codierung mit variabler Breite UTF-8.
Wenn Sie die Annahme # 1 ablehnen und die Annahme # 2 beibehalten, erhalten Sie eine Codierung mit breiten Zeichen . Unicode und UCS-2 wurden ursprünglich entwickelt, um eine 16-Bit-Codierung mit fester Breite zu verwenden, die 65.536 Zeichen ermöglichen würde. Early Adopters von Unicode, wie Sun (für Java) und Microsoft (für NT) verwendet UCS-2.
Aber ein paar Jahre später wurde klar, dass selbst das nicht für alle genug war, also wurde der Unicode-Codebereich erweitert. Wenn Sie nun eine Codierung mit fester Breite wünschen, müssen Sie UTF-32 verwenden.
Aber Sun und Microsoft hatten riesige APIs geschrieben, die auf 16-Bit-Zeichen basierten, und waren nicht begeistert, sie für 32-Bit neu zu schreiben. Glücklicherweise gab es immer noch einen Block von 2048 nicht zugewiesenen Zeichen aus der ursprünglichen "Basic Multilingual Plane" mit 65.536 Zeichen, die als "Ersatzzeichen" zugewiesen werden konnten, um paarweise ergänzende Zeichen zu verwenden: das UTF-16-Kodierungsformular. Leider erfüllt UTF-16 keine der ursprünglichen zwei Annahmen: Es ist sowohl Nicht-8-Bit als auch Variable-Breite.
Zusammenfassend:
Verwenden Sie UTF-8, wenn die Annahme von 8-Bit-Code-Einheiten wichtig ist.
Dies gilt für:
'\x00 Bytes in Strings nicht akzeptieren können und daher UTF-16 oder UTF-32 nicht verwenden können. In der Tat wurde UTF-8 ursprünglich für ein Unix-basiertes Betriebssystem (Plan 9) entwickelt
Verwenden Sie UTF-32, wenn die Annahme einer Codierung mit fester Breite wichtig ist.
Dies ist hilfreich, wenn Sie die Eigenschaften von Zeichen im Gegensatz zu ihrer Kodierung beachten, z. B. die Unicode-Entsprechungen für die ctypes.h -Funktionen wie isalpha , isdigit , toupper . usw.
Verwenden Sie UTF-16, wenn keine der beiden Annahmen so wichtig ist, aber Ihre Plattform früher UCS-2 verwendet hat.
Schreiben Sie für Windows oder für das dafür entwickelte .NET-Framework? Für Java? Dann ist UTF-16 der Standard-String-Typ. könnte es auch nutzen.
Da Sie C # verwenden, werden alle Ihre Zeichenfolgen in UTF-16 codiert. ASP.NET wird die eigentlichen HTML-Seiten in UTF-8 kodieren, aber dies geschieht hinter den Kulissen und Sie müssen sich nicht darum kümmern.
Die drei UTF-Kodierungsformen erfordern unterschiedliche Speichermengen, um ein Zeichen darzustellen:
Wenn Sie also Speicherplatz sparen möchten, verwenden Sie UTF-8, wenn Ihre Zeichen meist ASCII sind, oder UTF-16, wenn Ihre Zeichen überwiegend asiatisch sind.
Vergessen Sie zuallererst UCS-2: es ist veraltet. Es enthält nur eine Teilmenge von Unicode-Zeichen. Vergessen Sie auch UTF-32: Es ist sehr groß und sehr redundant. Es ist nicht nützlich für die Datenübertragung.
Auf Webseiten ist UTF-8 am kostengünstigsten, wenn die meisten der Sprachen, die Sie verwenden, westlich (lateinisch, kyrillisch, griechisch usw.) sind. Wenn Bandbreite und Ladezeiten kein Problem darstellen, können Sie UTF-16 ebenfalls verwenden. Stellen Sie nur sicher, dass Sie immer wissen, in welchem Format die Daten sind, wenn Sie mit byte[] umgehen. Versuchen Sie nicht, in veraltete 8-Bit-Zeichensätze wie ISO-8859 oder Windows-1252 zu konvertieren, da Sie sonst Daten verlieren.
In C # -Code sind Ihre string -Objekte intern in UTF-16, und Sie können nichts dagegen tun. Daher sind Ihre normalen Zeichenfolgenoperationen (z. B. Substring() ) von der Wahl des Ausgabeformats nicht betroffen. Man könnte argumentieren, dass es dadurch leistungsfähiger ist, UTF-16 zu kodieren, aber es lohnt sich nicht, wenn Sie es über das Internet übertragen, wo die Kosten für die Übertragung des größeren UTF-16 den kleinen Verarbeitungsgewinn überwiegen / p>
In SQL Server sollten Sie nvarchar(...) verwenden.
UTF-8 oder UTF-16 sind beide eine gute Wahl. Beide bieten Ihnen Zugriff auf die gesamte Palette von Unicode-Codepunkten, ohne 4 Bytes für jedes Zeichen zu verwenden.
Ihre Wahl wird von der Sprache, die Sie verwenden, und deren Unterstützung für diese Formate beeinflusst. Ich glaube, UTF-8 spielt am besten mit ASP.NET insgesamt, aber es hängt davon ab, was Sie tun.
UTF-8 ist oft eine gute Wahl, weil es gut mit Code funktioniert, der nur ASCII erwartet, während UTF-16 nicht. Es ist auch die effizienteste Art, Inhalte, die größtenteils aus unserem englischen Alphabet bestehen, darzustellen und dennoch das volle Repertoire von Unicode zu ermöglichen, wenn es benötigt wird. Ein guter Grund für die Wahl von UTF-16 wäre, wenn Ihre Sprache / Ihr Framework es nativ verwendet oder wenn Sie hauptsächlich Zeichen verwenden, die nicht im ASCII-Format vorliegen, wie beispielsweise asiatische Sprachen.
Er muss möglicherweise mit der Einschränkung leben, die eine neuere Version von SQL Server enthält oder auf diese aktualisiert. Normalerweise werden Sie sehen, wenn Sie anfangen, UTF-16, d. H. Den Standard-Unicode, wie er in .NET verwendet wird, zu entladen, da einige Zeichen verloren gehen und durch? Ersetzt werden. markiert in den Datenbanktabellen.
Schneller Hinweis: Grundsätzlich kann alles im Unicode Zeichensatz dargestellt werden. UTF-8 ist nur eine Codierung , die alle Zeichen in diesem Satz darstellen kann.
UCS-2 ist nicht wirklich eine Sache mehr zu benutzen. Es kann keine Zeichen über U + FFFF hinaus enthalten.
Welche der verbleibenden drei hängt davon ab, welche Art von Operationen Sie für den Text ausführen möchten. UTF-8 (in der Regel nicht immer!) Belegt weniger Speicherplatz auf der Festplatte, da es die gleichen Daten darstellt, und ist eine strenge Obermenge von ASCII, wodurch die erforderliche Transcodierung verringert werden kann. Sie können jedoch Ihre Zeichenfolge nicht indizieren oder ihre Länge in konstanter Zeit finden.
UTF-32 ermöglicht es Ihnen, die Länge der Zeichenfolge zu finden und sie in konstanter Zeit zu indizieren. Es ist keine Obermenge von ASCII wie UTF-8. Es erfordert auch, dass Sie 4 Bytes pro Codepunkt haben, aber hey, Speicherplatz ist billig.