it-swarm.com.de

CMS-Textcodierung und allgemeine Browserdecodierung; letzte Änderung?

Ich verwalte eine CMS-basierte Website. Die Hauptsprache des CMS ist Englisch. Unser Inhalt ist hauptsächlich in Englisch, aber Nutzerbeiträge sind manchmal in anderen Sprachen verfasst. Die unterstützende mySQL-Datenbank meiner Site ist auf UTF-8-Codierung eingestellt.

Bis vor kurzem wurden "andere Sprachen" (z. B. Russisch) korrekt angezeigt. Dies trotz der Tatsache, dass das CMS im Header jeder generierten Seite deklariert:

<meta http-equiv='Content-Type' content='text/html; charset=iso-8859-1' />

Ich gehe davon aus, dass Browser diese Header-Deklaration in der Vergangenheit häufig als Hinweis verwendeten und auch den Inhalt betrachteten, um die tatsächliche Kodierung zu bestimmen. Wenn beispielsweise eine UTF-8-Codierung erkannt wurde, wurde die Überschriftsdeklaration überschrieben. So wurde der Text "Andere Sprache" korrekt angezeigt. Es hilft, dass iso-8859-codierter Text von einem UTF-8-Decoder korrekt interpretiert wird, dh iso-8859-1 ist effektiv eine Teilmenge von UTF-8.

Frage 1: iso-8859-1 ist effektiv eine Teilmenge von UTF-8, richtig?

Soweit ich weiß, hat sich in letzter Zeit nichts an der Site, der CMS-Installation oder dem Server geändert. Aber natürlich entwickelt sich die Browsertechnologie ständig weiter und es kommen ständig neue Browserversionen hinzu.

In den letzten Wochen wurden Inhalte in "anderen Sprachen" in den neuesten Versionen von Safari (5.1) Chrome (15.0.874.81) und Firefox (7.0.1) unter als Garbage (Mojibake) angezeigt am wenigsten. Alle Anzeichen sind, dass der "automatische" Textcodierungsmodus von jedem bestimmt, dass die Seiten der Site iso-8859-1-codiert sind, das Ende der Geschichte. Wenn ich den Browser manuell auf UTF-8 einstelle, verschwindet der Müll und der gesamte Text wird wie zuvor korrekt gerendert.

Frage 2: Hat sich der Standard/die Vorgehensweise geändert, so dass neuere Browser-Versionen die Header-Deklaration der Textkodierung befolgen und diese nicht überschreiben, unabhängig davon, welche Kodierung tatsächlich vorhanden ist?

Frage 3: Wenn nicht, welche anderen Faktoren könnten für das plötzliche Auftreten von Müll verantwortlich sein, bei dem es zuvor noch keinen gab? (Könnte beispielsweise eine subtile Änderung des Apache durch den Hosting-Anbieter diesen Effekt haben?)

Ich habe keine Ahnung, warum die CMS-Primärdistribution iso-8859-1-codiert ist. Ich habe mir die CMS-Dokumente angesehen und mehrere Anfragen an Support-Kanäle gesendet, aber… keine Antwort. Das CMS ist definitiv in der Lage, andere Sprachen zu unterstützen. Viele "offizielle" Alternativen sind verfügbar, und soweit ich das überprüft habe, deklarieren sie alle "utf-8" in den Kopfzeilen der generierten Seiten

Ich nehme an, dass es tief im CMS einen von der 8859-1-Codierung abhängigen Code gibt. (Nein, ich werde nicht versuchen, es zu finden!) Aber die Existenz einer großen Anzahl alternativer Sprachpakete scheint dagegen zu sprechen.

Frage 4: (Bonus!) Wenn es im CMS keinen codierungsabhängigen Code gibt, können die CMS-Entwickler aus technischen Gründen zögern, ihre Primärdistribution auf UTF-8 zu verlagern.

Frage 5: Fehlt mir irgendwann alles? Bin ich völlig oder teilweise verwirrt darüber, wie die Textkodierung funktioniert?

1
hen3ry

Utf-8- und nicht englische Zeichen werden in iso-8859-1- und iso-8859-1-Zeichen nicht gut angezeigt.

Wenn Sie wissen möchten, welche Codierung Ihr Browser auf einer Seite erkannt hat und verwendet:

In Firefox gehen Sie einfach zum Menü "Ansicht"> "Zeichenkodierung".

http://support.mozilla.com/en-US/kb/Menu%20Reference

  • Stellen Sie sicher, dass UF-8 automatisch ausgewählt wird, wenn Sie eine Seite lesen und wenn Sie Text in das CMS eingeben, der veröffentlicht werden soll .

  • Wenn möglich, konfigurieren Sie die cms für die Verwendung von HTML-Zeichenentitäten.

  • Ersetzen Sie das Meta-Tag durch utf-8 oder durch die Zeichencodierung, die auf Ihrer Site gut angezeigt wird.

  • Bitte beachten Sie, dass möglicherweise unsichtbare Zeichen angezeigt werden, wenn Sie die falsche Codierung verwenden

1
Osvaldo

Soweit ich weiß, wird die vom Browser verwendete Zeichenkodierung in der folgenden Reihenfolge festgelegt:

  1. Der Inhaltstyp Antwortheader wie vom Server gesendet.
  2. Wenn nicht # 1, dann das Content-Type META-Tag.
  3. Wenn keine der oben genannten Optionen zutrifft, basiert die Standardeinstellung des Browsers, von der ich ausgehe, zunächst auf der Standardsprache des Systems.

AFAIK Die Standardkodierung im Browser hat sich nicht geändert. Und ich bezweifle sehr, dass das einfache Aktualisieren auf die neueste Version eines Browsers die bereits festgelegte Standardeinstellung beeinträchtigen würde.

Auch Ich glaube nicht, dass es überhaupt möglich ist, genau abzuleiten die korrekte Zeichenkodierung durch Analyse des Seiteninhalts. Es muss gesagt werden, oder es fällt auf die Standardeinstellungen des Browsers zurück. Auf dem Computer, auf dem ich mich gerade befinde, sind sowohl Firefox 3.6 als auch Chrome 14 standardmäßig auf ISO-8859-1 eingestellt.

Frage 1: iso-8859-1 ist effektiv eine Teilmenge von UTF-8, richtig?

Leider ist dies nicht der Fall - US-ASCII ist eine Teilmenge von utf-8, aber Nicht-ASCII-Zeichen in ISO-8859-1 sind anders codiert als in utf-8.

Frage 2: Hat sich der Standard/die Vorgehensweise geändert, so dass neuere Browser-Versionen die Header-Deklaration der Textkodierung befolgen und diese nicht überschreiben, unabhängig davon, welche Kodierung tatsächlich vorhanden ist?

Änderungen sind mir nicht bekannt. Dies würde sicherlich viele Websites brechen? Ein Browser kann die von der Site festgelegte Zeichenkodierung nicht überschreiben, und zwar anhand dessen, was er für die Zeichenkodierung hält ! Kann es?!

Frage 3: Wenn nicht, welche anderen Faktoren könnten für das plötzliche Auftreten von Müll verantwortlich sein, bei dem es zuvor noch keinen gab? (Könnte beispielsweise eine subtile Änderung des Apache durch den Hosting-Anbieter diesen Effekt haben?)

Ja, ich würde vermuten, dass eine Änderung der Serverkonfiguration dies verursacht. Der Antwortheader für den Inhaltstyp (wie oben erwähnt) wurde möglicherweise geändert.

Frage 4: (Bonus!) Wenn es im CMS keinen codierungsabhängigen Code gibt, können die CMS-Entwickler aus technischen Gründen zögern, ihre Primärdistribution auf UTF-8 zu verlagern.

Wie alt ist das CMS? In was ist es geschrieben? Historisch gesehen verarbeitet PHP Mehrbyte-Strings nicht so gut. Es gibt viele Funktionen in PHP, die nur für Einzelbyte-Strings funktionieren. Einige der Multi-Byte-Funktionen sind nur mit PHP 5 verfügbar.

1
MrWhite

Fortsetzen

Ihr Server hatte und hat jetzt nicht AddDefaultCharset (nämlich - AddDefaultCharset utf-8).

Dies ist einer der Gründe für die beschriebene frühere und aktuelle Ansicht.

Geben Sie es über htaccess zurück (versuchen Sie es)

Bonusantwort auf Q.4

  • charset-abhängige Codeänderungen zur Textbearbeitung sind vorhanden immer - die meisten String-Funktionen haben Paare als mb * ()
  • wenn Sie anfangen, an 8-Bit-Texte in (My) SQL zu denken, müssen Sie an DB-Zeichensatz | Client-Zeichensatz | Verbindungszeichensatz | natürliche Zeichenfolgengröße denken. Geschlossene Augen und schlechtes Gedächtnis scheinen die bessere Wahl zu sein (Mantra "Englisch beherrsche die Welt")

Bonusantwort auf Q.5

Nein, du vermisst nichts. Alte gute Ergebnisse wurden nur gefälscht, man muss mit 8bit Kopfschmerzen von den ersten Saiten vor Ort bekommen

0
Lazy Badger