Zeichensatz Probleme

[Core]

Hallo Leute,
trotzdem ich auf in an allen Relevanten Stellen UTF-8 als Zeichensatz
angegeben habe werden mir Umlaute falsch dargestellt.

  
<meta http-equiv="content-type" content="text/html; utf-8" />  

~~~~~~php
  
header('Content-Type:text/html; charset=UTF-8');  

Habt ihr eine Idee wie ich das Problem lösen könnte?

[Der Martin]

Hi,

trotzdem ich auf in an allen Relevanten Stellen UTF-8 als Zeichensatz angegeben habe werden mir Umlaute falsch dargestellt.

Zeichencodierung, nicht Zeichensatz.

<meta http-equiv="content-type" content="text/html; utf-8" />
header('Content-Type:text/html; charset=UTF-8');

Dann wird es wohl daran liegen, dass dein Dokument nicht in UTF-8 codiert *ist*, auch wenn du das angibst. In eine Schachtel Pralinen kommen ja auch keine Erdnüsse, indem du einfach nur "Erdnüsse" draufschreibst.

Habt ihr eine Idee wie ich das Problem lösen könnte?

Ja - wirklich in UTF-8 speichern.

Ciao,
 Martin

[Core]

Hi Martin,
ich verwende Eclipse, da sollte doch UTF-8 als Zeichensatz schon richtig voreingestellt sein? Weißt du wie ich die Datei jetzt umkodieren kann?

[Der Martin]

Hallo,

ich verwende Eclipse, da sollte doch UTF-8 als Zeichensatz schon richtig voreingestellt sein?

keine Ahnung, ich kenne Eclipse nur dem Namen nach.

Weißt du wie ich die Datei jetzt umkodieren kann?

Im Editor deiner Wahl öffnen, als UTF-8 (vorzugsweise ohne BOM) speichern, und gut is'. Sollte so ziemlich jeder halbwegs brauchbare Editor können.

Ciao,
 Martin

[klose]

Hallo

Weißt du wie ich die Datei jetzt umkodieren kann?

Im Editor deiner Wahl öffnen, als UTF-8 (vorzugsweise ohne BOM) speichern, und gut is'. Sollte so ziemlich jeder halbwegs brauchbare Editor können.

Was hat das eigentlich für Auswirkungen, wenn ich mit BOM speichere? Mir ist da noch nie ein Unterschied aufgefallen irgendwie....

danke!

[Peter Pan]

Hi!

Im Editor deiner Wahl öffnen, als UTF-8 (vorzugsweise ohne BOM) speichern, und gut is'. Sollte so ziemlich jeder halbwegs brauchbare Editor können.

Was hat das eigentlich für Auswirkungen, wenn ich mit BOM speichere? Mir ist da noch nie ein Unterschied aufgefallen irgendwie....

Irgendwie ist es vollkommen egal welche "Byte Order" auf Deinem Hardwareuntergestell angesagt ist und deshalb war BOM schon immer eine doofe Idee. Manche Software hat damit nun Probleme und das sollte nicht verwundern.

off:PP

[Core]

@Peter Pan
Ich konnte die Einstellungen in den Projekt Properties nicht finden.
Die einzigen Encoding-Einstellungen die ich sehen konnte waren die die
den PHP Debuger betrafen,..

[dedlfix]

Hi!

Irgendwie ist es vollkommen egal welche "Byte Order" auf Deinem Hardwareuntergestell angesagt ist und deshalb war BOM schon immer eine doofe Idee.

So allgemein formuliert ist das nicht richtig. Für UTF-8 gibt es nur eine Byte-Order, da braucht es keine. Ganz doof ist die Idee aber nicht, denn man könnte zumindest anhand der BOM erkennen, dass ein Dokument UTF-8-kodiert ist. Dass Web- und einige andere Software damit Probleme hat - nunja, altes Zeug stirbt nur langsam aus.

Aber für UTF-16 und -32 ist eine BOM doch sehr sinnvoll, denn da ist unterschiedliche Byte-Order auch in den Dokumenten vorhanden.

Manche Software hat damit nun Probleme und das sollte nicht verwundern.

Es sollte verwundern, dass sie immer noch nichts von Unicode gehört hat - außer vielleicht wichtige Altlasten mit Gnadenbrot.

Lo!

[Gunnar Bittersmann]

@@dedlfix:

nuqneH

Es sollte verwundern, dass sie immer noch nichts von Unicode gehört hat - außer vielleicht wichtige Altlasten mit Gnadenbrot.

PHP zum Beispiel.

Qapla'

[dedlfix]

Hi!

Es sollte verwundern, dass sie immer noch nichts von Unicode gehört hat - außer vielleicht wichtige Altlasten mit Gnadenbrot.
PHP zum Beispiel.

Stimmt, aber ich habe es aufgegeben, mich zu wundern, wie lange PHP6 von der ersten Feature-Planung im Jahr 2005 bis zu seiner Ersterscheinung braucht.

Lo!

[suit]

Stimmt, aber ich habe es aufgegeben, mich zu wundern, wie lange PHP6 von der ersten Feature-Planung im Jahr 2005 bis zu seiner Ersterscheinung braucht.

Aber alles wird irgendwann fertig - Hurd ist da und und Duke Nukem Forever kommt auch :p

[Peter Pan]

Hi!

Stimmt, aber ich habe es aufgegeben, mich zu wundern, wie lange PHP6 von der ersten Feature-Planung im Jahr 2005 bis zu seiner Ersterscheinung braucht.

Aber alles wird irgendwann fertig - Hurd ist da und und Duke Nukem Forever kommt auch :p

PHP 5.3 ist längst da und hat alles was PHP 6 haben sollte - außer Unicode-Support, of course. Als nächstes wird Zend versuchen, dass ZFW 2.0 zu etablieren und da sehe ich bereits tiefschwarz, denn der Zwang namespaces zu verwenden, wird nicht auf sehr große Gegenliebe stossen - PHP ist und wird kein zwotes Java, das ist ja schon .NET. Und wer mag schon Backslashes?
PHP 6 kommt frühestens in zwei Jahren, wenn überhaupt. Ach egal - es ist Wochenende...

off:PP

[dedlfix]

Hi!

kein zwotes Java, das ist ja schon .NET.

Protest: Ja, .NET ist angetreten, um Java Konkurrenz zu machen. Aber ich finde, es hat Java in Punkto Syntax / -Features weit hinter sich gelassen. Schau mal, wieviel rot Java auf seiner Seite hat. Und einige sehr interessante Features (wie LINQ oder dynamische Typen) sind noch im Fließtext versteckt.

Lo!

[Der Martin]

Hallo,

Protest: Ja, .NET ist angetreten, um Java Konkurrenz zu machen. Aber ich finde, es hat Java in Punkto Syntax / -Features weit hinter sich gelassen. Schau mal, wieviel rot Java auf seiner Seite hat.

das sieht zwar interessant für C# und mau für Java aus, aber hier handelt es sich IMO auch mal wieder um einen unfairen Äpfel-Schrauben-Vergleich. Denn Java ist eine Programmiersprache, .net dagegen "nur" ein Framework, das potentiell verschiedene Programmiersprachen ermöglicht - wovon C# eine ist.
Würde man also Java mit VB.net vergleichen, sähe das Resultat vermutlich wieder ganz anders aus.

So long,
 Martin

[dedlfix]

Hi!

das sieht zwar interessant für C# und mau für Java aus, aber hier handelt es sich IMO auch mal wieder um einen unfairen Äpfel-Schrauben-Vergleich. Denn Java ist eine Programmiersprache, .net dagegen "nur" ein Framework, das potentiell verschiedene Programmiersprachen ermöglicht - wovon C# eine ist.

Kommt drauf an, was man genau vergleicht. Der Vergleich zwischen Java und C# ist erlaubt, weil beides Programmiersprachen sind. Die Bibliotheken der jeweiligen Frameworks mal ausgelassen, gibt es eine Ebene darunter dann die JRE und die CLR von .NET. Ich nehme mal an, dass die JRE genauso Potential hat, andere Sprachen auf sie aufzusetzen, wie es bei der CLR von .NET der Fall ist. Wie auch immer, wenn man Java mit der CLR oder C# mit der JRE vergliche, hätte man einen Apfel-Birnbaum- oder Apfelbaum-Birne-Vergleich. Das war aber nicht mein Ziel, ich suchte mir schon vergleichbare Ebenen.

Würde man also Java mit VB.net vergleichen, sähe das Resultat vermutlich wieder ganz anders aus.

Nein, da musst du dir eine der anderen für .NET verfügbaren Sprachen suchen, denn VB soll C# im Funktionsumfang nicht nachstehen. (Das war zumindest vor nicht allzu langer Zeit als Ziel bekannt gegeben wurden, und wenn ich mich nicht irre, ist das in der aktuellen Version auch umgesetzt worden.)

Lo!

[Peter Pan]

Hi!

kein zwotes Java, das ist ja schon .NET.

Protest: Ja, .NET ist angetreten, um Java Konkurrenz zu machen. Aber ich finde, es hat Java in Punkto Syntax / -Features weit hinter sich gelassen. Schau mal, wieviel rot Java auf seiner Seite hat. Und einige sehr interessante Features (wie LINQ oder dynamische Typen) sind noch im Fließtext versteckt.

Das stimmt. Woher kommt aber Dein Protest im PHP-Kontext?
Dass C# sehr geil ist habe ich nie bestritten;-)

off:PP

[Gunnar Bittersmann]

@@dedlfix:

nuqneH

Es sollte verwundern, dass sie immer noch nichts von Unicode gehört hat

Kaum einer Software kann man nachsagen, so richtig Unicode-fähig zu sein.

JavaScript: 'ä' === 'a\u0308' sollte true ergeben, tut’s aber nicht.

Qapla'

[Peter Pan]

Hi!

Aber für UTF-16 und -32 ist eine BOM doch sehr sinnvoll, denn da ist unterschiedliche Byte-Order auch in den Dokumenten vorhanden.

Das meinte ich doch - warum ist das so? Dafür gibt es keinen echten Grund - warum soll ich mich darum kümmern müssen?

off:PP

[dedlfix]

Hi!

Aber für UTF-16 und -32 ist eine BOM doch sehr sinnvoll, denn da ist unterschiedliche Byte-Order auch in den Dokumenten vorhanden.
Das meinte ich doch - warum ist das so? Dafür gibt es keinen echten Grund - warum soll ich mich darum kümmern müssen?

Der Grund ist, dass Systeme mit unterschiedlichen Byte-Reihenfolgen arbeiten, das Unicode-Konsortium jedoch nicht festgelegt hat, wie die Reihenfolge in Dokumenten zu sein hat, sondern da freie Wahl gelassen hat. Jedes System darf also die Byte Order nehmen, die es mag. Und damit Systeme mit anderer Byte-Order-Vorliebe die Texte richtig herum interpretieren können, muss man die BOM an den Anfang stellen. Natürlich hätte man sich die BOM ersparen können, wenn man eine bestimmte Byte-Reihenfolge festgelegt hätte ...

Lo!

[Peter Pan]

Hi!

Aber für UTF-16 und -32 ist eine BOM doch sehr sinnvoll, denn da ist unterschiedliche Byte-Order auch in den Dokumenten vorhanden.
Das meinte ich doch - warum ist das so? Dafür gibt es keinen echten Grund - warum soll ich mich darum kümmern müssen?
Der Grund ist, dass Systeme mit unterschiedlichen Byte-Reihenfolgen arbeiten, das Unicode-Konsortium jedoch nicht festgelegt hat, wie die Reihenfolge in Dokumenten zu sein hat, sondern da freie Wahl gelassen hat.

Der Schwachsinn liegt ja genau darin.

Jedes System darf also die Byte Order nehmen, die es mag. Und damit Systeme mit anderer Byte-Order-Vorliebe die Texte richtig herum interpretieren können, muss man die BOM an den Anfang stellen. Natürlich hätte man sich die BOM ersparen können, wenn man eine bestimmte Byte-Reihenfolge festgelegt hätte ...

Das ist ein ISO-Standard: ersetze Byte durch Oktett und Du bist durch!

Die Thematik hatte ich erst neulich: "was ist 4 << 3"?
(ZCE-Prüfungs-Frage im Vorbereitungs-Kurs)
Zends Musterlösung ist falsch! Die sagen 0!
Mindeestens 90% der von mir befragten Informatiker halten allerdings deren Lösung für richtig - sie denken zu krude.
Ja, es geht dabei um Bits, aber das Problem ist gelöst, wenn man konsequent zuende denkt - als Entwickler interessiert mich keine Repräsentation der Daten im physikalischen Speicher - als Mensch schon.

Die literale Darstellung von Zahlen sollte eindeutig bleiben.

off:PP

[Der Martin]

Hallo,

Die Thematik hatte ich erst neulich: "was ist 4 << 3"?
(ZCE-Prüfungs-Frage im Vorbereitungs-Kurs)
Zends Musterlösung ist falsch! Die sagen 0!

da würde mich jetzt aber *brennend* deren Begründung und/oder Herleitung interessieren. Ich bekomme nämlich nicht 0 heraus, sondern 32.

Oder meinten die vielleicht eher einen Right Shift? Oder hast du einfach falsch gelesen?

Denn:  4 >> 3 = 0

Mindeestens 90% der von mir befragten Informatiker halten allerdings deren Lösung für richtig

Für meinen korrigierten Fall halte ich das auch für die richtige Lösung - was käme sonst in Frage?

Ja, es geht dabei um Bits, aber das Problem ist gelöst, wenn man konsequent zuende denkt - als Entwickler interessiert mich keine Repräsentation der Daten im physikalischen Speicher - als Mensch schon.

Ja, aber der Bitshift-Operator arbeitet mit dem Zahlenwert als solchem, der seinerseits unabhängig davon ist, ob diese Zahlen im Speicher als MSB-first oder LSB-first abgelegt sind.

Die literale Darstellung von Zahlen sollte eindeutig bleiben.

Eben.

So long,
 Martin

[Jens Holzkämper]

Tach,

Der Grund ist, dass Systeme mit unterschiedlichen Byte-Reihenfolgen arbeiten, das Unicode-Konsortium jedoch nicht festgelegt hat, wie die Reihenfolge in Dokumenten zu sein hat, sondern da freie Wahl gelassen hat.

Der Schwachsinn liegt ja genau darin.

wieso Schwachsinn, es gibt nunmal beide Systeme und das Unicode Consortium wollte beide unterstützen, hat einen Weg dafür gefunden und festgelegt und sogar einen Fallback für Dokumente ohne BOM festgelegt.

Natürlich hätte man sich die BOM ersparen können, wenn man eine bestimmte Byte-Reihenfolge festgelegt hätte ...

Das ist ein ISO-Standard: ersetze Byte durch Oktett und Du bist durch!

UTF-16 ist auch ein ISO-Standard.

mfg
Woodfighter

[Gunnar Bittersmann]

@@klose:

nuqneH

Was hat das eigentlich für Auswirkungen, wenn ich mit BOM speichere?

Ja, das kann zu Darstellungsproblemen führen. S.a. BOM in HTML.

Qapla'

[Peter Pan]

Hi!

ich verwende Eclipse, da sollte doch UTF-8 als Zeichensatz schon richtig voreingestellt sein?

Nein, das wäre sinnvoll- muss aber nicht der Fall sein.

Weißt du wie ich die Datei jetzt umkodieren kann?

Was sagen denn die Project-Properties in Eclipse zum Thema "Text file encoding"? (Rechte Maustaste auf das Projekt und dann ganz unten 'Properties')

off:PP

[Core]

@Peter Pan
Ich habe die Einstellung "Text file encoding" nicht gefunden.
Die einzige Encoding Einstellung betrifft den PHP Debuger.

In den Main Settings steht eigentlich alles auf UTF-8 soweit ich das beurteilen kann. Die Properties der Files gaben keinen Aufschluss(Eclipse).

[Sven Rautenberg]

Moin!

Hi Martin,
ich verwende Eclipse, da sollte doch UTF-8 als Zeichensatz schon richtig voreingestellt sein? Weißt du wie ich die Datei jetzt umkodieren kann?

Nein, eher nicht.

Ich kann zwar nicht für Eclipse direkt sprechen, sondern nur für das darauf basierende Zend Studio, aber in diesem ist die Standardcodierung auf "CP 1252" eingestellt (das ist das Windows-Encoding mit Eurozeichen, was etwas mehr Zeichen enthält als ISO-8859-1).

Wenn man daran also nix umstellt, hat man ein Problem. Ich empfehle ja, hier global UTF-8 einzustellen - für neue Projekte will man sowieso nix anderes haben. Und direkt daneben gleich das Zeilenende auf "Unix" stellen hätte auch gewisse Vorteile.

- Sven Rautenberg

[dedlfix]

Hi!

Und direkt daneben gleich das Zeilenende auf "Unix" stellen hätte auch gewisse Vorteile.

Welche denn? Das jeweils eingesparte Zeichen kannst du sicher nicht gemeint haben. Mir fällt da nur die Vermeidung einer "komischen" Darstellung in Unix-Text-Konsolen-Tools ein, also das Wegbleiben von ^M-Darstellungen am Zeilenende. Allerdings steht als (schwerwiegenderer) Nachteil, das komplette Nichtvorhandensein von Zeilen, wenn man die Datei unter Windows mal eben schnell mit Notepad öffnet. (Ja, ich weiß, es gibt andere (bessere) Editoren, aber solche gibt es auch für die Unix-Kommandozeile.)

Lo!

[Gunnar Bittersmann]

@@Core:

nuqneH

ich verwende Eclipse, da sollte doch UTF-8 als Zeichensatz schon richtig voreingestellt sein?

Der Martin hatte es schon gesagt: UTF-8 ist kein Zeichensatz, sondern eine Zeichencodierung. [Zeichencodierungen: grundlegende Konzepte, Zeichencodierung für Anfänger]

Weißt du wie ich die Datei jetzt umkodieren kann?

Du kannst die Zeichencodierung bei den Projekteinstellungen (Projekteigenschaften?) und bei den Dateieinstellungen ändern. (Hab ein englisches Eclipse, da heißt es jeweils „properties“.)

Qapla'

[MudGuard]

Hi,

In eine Schachtel Pralinen kommen ja auch keine Erdnüsse, indem du einfach nur "Erdnüsse" draufschreibst.

"kann Spuren von Erdnüssen enthalten" ...

(besonders gelungen fand ich diesen Hinweis auf einer Tüte, die gesalzene Erdnüssen enthalten sollte ...)

cu,
Andreas

[Cheatah]

Hi,

es wird Dein Problem nicht lösen, weil die entscheidende Angabe korrekt ist; dennoch:

<meta http-equiv="content-type" content="text/html; utf-8" />

  

> header('Content-Type:text/html; charset=UTF-8');  
> 

~~~  
  
Vergleiche mal die beiden Content-Types. Nur einer davon ist richtig. Und ich meine nicht die Groß- und Kleinschreibung.  
  
Cheatah  

-- 
X-Self-Code: sh:( fo:} ch:~ rl:| br:> n4:& ie:% mo:) va:) de:] zu:) fl:{ ss:) ls:~ js:|  
X-Self-Code-Url: http://emmanuel.dammerer.at/selfcode.html  
X-Will-Answer-Email: No  
X-Please-Search-Archive-First: Absolutely Yes

[hotti]

hi,

Habt ihr eine Idee wie ich das Problem lösen könnte?
header('Content-Type:text/html; charset=UTF-8');

Ja, schau mal, ob der Header auch tatsächlich so gesendet wird (FF Live HTTP Headers).

Hotti