Wir erstellen ein (Java) Webprojekt mit Eclipse. Standardmäßig verwendet Eclipse Cp1252 encoding auf Windows-Rechnern (die wir verwenden).
Da wir (neben Europa) auch Entwickler in China haben, habe ich mich gefragt, ob das wirklich die Codierung ist.
Mein erster Gedanke war, in UTF-8 zu konvertieren, weil "alle Zeichensätze unterstützt" . Aber ist das wirklich weise? Sollten wir stattdessen eine andere Kodierung wählen? Ich sehe einige Probleme:
1) Wie interpretiert Webbrowser die Dateien standardmäßig? Kommt es darauf an, welche Sprachversion man benutzt? Was ich hier möchte, ist, dass wir die verwendeten Kodierungsschemata ausführlich deklarieren sollten:
<?xml version='1.0' encoding='UTF-8' ?> declarations. @CHARSET "UTF-8"; . <meta http-equiv="Content-Script-Type" content="text/javascript; charset=utf-8"> oder <script type="text/javascript" charset="utf-8"> für bestimmte Skripte definieren. Was passiert, wenn wir die CSS-Datei ohne @CHARSET "UTF-8"; -Deklaration verlassen? Wie entscheidet der Browser, wie es codiert ist?
2) Ist es ratsam, UTF-8 zu verwenden, weil es ist so flexibel ist. Indem wir unseren Code in Cp1252 (oder vielleicht ISO-8859-1 ) sperren, kann ich sicherstellen, dass ausländische Entwickler keine Sonderzeichen in Dateien einfügen. Dies verhindert effektiv, dass sie beispielsweise chinesische Kommentare einfügen (wir sollten 100% Englisch verwenden). Wenn UTF-8 erlaubt wird, können Entwickler manchmal auch seltsame Zeichen einführen, die mit dem menschlichen Auge schwer oder gar nicht wahrnehmbar sind. Dies tritt auf, wenn Leute zum Beispiel Text kopieren oder versehentlich eine komische Tastaturkombination drücken.
Es scheint, dass das Zulassen von UTF-8 im Projekt nur Probleme bringt ...
3) Für die Internationalisierung hielt ich anfänglich UTF-8 für eine gute Sache ("Wie können Sie Übersetzungen hinzufügen, wenn die Dateicodierung die benötigten Zeichen nicht unterstützt?"). Wie sich jedoch herausstellte, müssen Java-Ressourcenpakete (.properties-Dateien) mit ISO-8859-1 codiert werden, da sie andernfalls möglicherweise nicht mehr funktionieren. Stattdessen werden die internationalen Zeichen in die \uXXXX -Notation konvertiert, z. B. \u0009 , und die Dateien werden mit ISO-8859-1 codiert. Also ... wir können nicht einmal UTF-8 dafür verwenden.
Für Binärdateien ... nun, das Kodierungsschema ist nicht wirklich wichtig (ich nehme an, man kann sagen, dass es gar nicht existiert).
Wie sollten wir diese Probleme angehen?
Mein erster Gedanke war, zu UTF-8 zu konvertieren, weil "es alle Zeichensätze unterstützt". Aber ist das wirklich weise?
Mach es. Du willst die Weltherrschaft.
1) Wie interpretiert Webbrowser die Dateien standardmäßig? Kommt es darauf an, welche Sprachversion man benutzt?
Es verwendet den Content-Type Response-Header dafür (Anmerkung, der Antwortkopf real , nicht das HTML-Metatag). Ich sehe / weiß, dass Sie ein Java-Entwickler sind, hier sind JSP / Servlet gezielte Antworten: Einstellung <%@page pageEncoding="UTF-8" %> oben auf der JSP-Seite wird implizit dieses Recht und Einstellung response.setCharacterEncoding("UTF-8") in Servlet / Filter macht das gleiche. Wenn dieser Header abwesend ist, ist es vollständig dem Browser überlassen, die Codierung zu bestimmen. MSIE wird die Plattform-Standardcodierung verwenden. Firefox ist ein bisschen schlauer und wird die Kodierung basierend auf dem Seiteninhalt erraten.
2) Ist es ratsam, UTF-8 zu verwenden, weil es so flexibel ist? Indem wir unseren Code in Cp1252 (oder vielleicht ISO-8859-1) sperren, kann ich sicherstellen, dass ausländische Entwickler keine Sonderzeichen in Dateien einfügen.
Ich würde nur ein Dokument schreiben, in dem Team-Coding-Konventionen beschrieben werden, und das unter den Entwicklern verbreiten. Jeder selbst respektierte Entwickler weiß, dass er riskiert, gefeuert zu werden, wenn er dies nicht tut.
3) Für die Internationalisierung hielt ich zunächst UTF-8 für eine gute Sache ("Wie können Sie Übersetzungen hinzufügen, wenn die Dateicodierung die benötigten Zeichen nicht unterstützt?"). Wie sich jedoch herausstellte, müssen Java-Ressourcenpakete (.properties-Dateien) mit ISO-8859-1 codiert werden, da sie andernfalls möglicherweise nicht mehr funktionieren.
Dies ist seit Java 1.6 mit neuem Properties#load() Methode eine Reader und die neue ResourceBundle.Control Klasse, in der Sie das Laden der Bundle-Datei steuern können. In JSP / Servlet-Begriffen wird normalerweise ein ResourceBundle verwendet. Setzen Sie den Nachrichtenpaketnamen auf den vollständig qualifizierten Klassennamen der benutzerdefinierten ResourceBundle -Implementierung, und dieser wird verwendet.
Für Binärdateien ... nun, das Codierungsschema ist nicht wirklich wichtig (ich nehme an, man kann sagen, dass es gar nicht existiert).
Die Codierung ist in der Tat nur interessant, wenn man computerlesbare Binärdaten in menschenlesbare Zeichendaten umwandeln will. Für "echten" binären Inhalt macht es in der Tat keinen Sinn, da das Binärformat keine sinnvollen Zeichendaten darstellt.
ResourceBundle.Control Beispiel Ich würde definitiv UTF-8 gegenüber allen anderen Kodierungsschemata empfehlen.
Stellen Sie sicher, dass Ihr DBMS vollständig UTF-8-kompatibel ist, wenn Sie mehrsprachige Daten in einer Datenbank speichern
Stellen Sie außerdem sicher, dass alle Dateien, einschließlich CSS, JavaScript, Anwendungsvorlagendateien, in UTF-8 mit BOM codiert sind. Andernfalls werden die charset -Direktiven möglicherweise vom Browser nicht richtig interpretiert.
Wir haben über 30 Sprachen in einem großen datenbankgestützten CMS und es funktioniert wie ein Zauber. Der Client hat menschliche Editoren für alle Sprachen, die die Dateneingabe durchführen.
Es kann zu Kollationsproblemen mit einigen Sprachen kommen (das Beispiel der gefürchteten türkischen Punktlosen i - ı - wenn es sich nicht um Groß- und Kleinschreibung handelt). Es gibt immer eine Antwort darauf, aber es wird sehr datenbankspezifisch sein.
Ich bin nicht vertraut mit den Besonderheiten von Java Resource Bundles. Wir verwenden einige Java-Bibliotheken wie markdownj , die UTF-8-kodierten Text problemlos in und aus der Datenbank verarbeiten.
Bearbeitet, um die Kommentare des OP zu beantworten:
Ich denke, der Hauptgrund für das Mainstreaming von UTF-8 ist, dass Sie nie wissen, in welche Richtung sich Ihre Systeme entwickeln werden. Sie können annehmen, dass Sie nur eine Sprache heute behandeln werden, aber das ist selbst in perfekt monolingualen Umgebungen nicht wahr, da Sie möglicherweise Namen oder Referenzen speichern müssen, die Nicht-US-ASCII-Oktettwerte enthalten.
Außerdem ändert ein UTF-8-codierter Zeichenstrom die US-ASCII-Oktettwerte nicht, und dies bietet volle Kompatibilität mit nicht UTF-8-aktivierten Dateisystemen oder anderer Software.
Die heutigen modernen Browser interpretieren UTF-8 korrekt, vorausgesetzt, die Anwendung / Textdatei wurde mit UTF-8 codiert und Sie fügen% ce_de% auf jeder Seite ein, die an einen Browser geliefert wird.
Überprüfen Sie, ob Ihre Middleware (PHP, JSP usw.) UTF-8 überall unterstützt, und zwar in Verbindung mit Ihrer Datenbank.
Ich sehe nicht, was das Problem bei Entwicklern ist, die möglicherweise mit Daten umgehen, die sie nicht verstehen. Ist das nicht auch potenziell der Fall, wenn wir mit Daten in unseren eigenen Sprachen umgehen? Zumindest mit einem vollständigen Unicode-System werden sie in der Lage sein zu erkennen, ob die Glyphen, die sie im Browser oder in der Datenbank sehen, mit der Sprache übereinstimmen, mit der sie sich befassen sollen, anstatt Streams von ???? ?????? ??? ????
Ich glaube, dass die Verwendung von UTF-8 als Zeichencodierung für alles eine sichere Sache ist. Dies sollte für fast jede Situation funktionieren, und Sie sind bereit für den Tag, an dem Ihr Chef vorbeikommt und darauf besteht, dass Sie mehrsprachig werden müssen.
Tags und Links character-encoding utf-8 special-characters