PhpED Umlaute umwandeln

[Laire]

Hallo,

gibt es bei PhpED die möglichkeit, umlaute automatisch umzuwandeln?

z.B. ü -> ü

Finde dafür keine Einstellung....

[PHP-Desaster]

Das ist doch eine einfache Suchen und Ersetzen Funktion. Und das kann PhpED sogar direkt über mehrere Dateien hinweg. Oder woran haperts?

[Laire]

hm finde ich etwas kompleziert, in anderen editoren kenne ich die Funktion, das es gleich beim Tippen ersetzt wird...

[pekka]

z.B. ü -> ü

[unset]

Das Forum verschluckt das Entity. Ein klick auf "Zitat" zeigt, dass er "ü" meint.

[pekka]

Tools > Settings > Editor > Autocorrection

[PHP-Desaster]

Re: PhpED Umlaute umwandeln

Warum nutzt du eigentlich solche Entitäten? Zeichensatz vernünftig einstellen und du kannst dir so einen Käse sparen.

[wahsaga]

Re: Re: PhpED Umlaute umwandeln

Original geschrieben von PHP-Desaster
Warum nutzt du eigentlich solche Entitäten?

Versteh ich auch nicht. Selbst wenn man noch kein UTF-8 verwendet, sondern ISO-8859-1, sind da deutsche Umlaute schon "enthalten".

Aber es gibt offenbar ziemlich viele Leute, die meinen, wenn sie dafür dennoch weiterhin die Entity-Schreibweise verwenden, würden sie "auf Nummer Sicher gehen" oder sowas ...

[php_fussel]

Aber es gibt offenbar ziemlich viele Leute, die meinen, wenn sie dafür dennoch weiterhin die Entity-Schreibweise verwenden, würden sie "auf Nummer Sicher gehen" oder sowas ...

... da gehöre ich auch zu ... *duckundweg!

Gruß php_fussel

[Laire]

Hm dann arbeitete ich nach überholten Richtlinien, mir wurde mal gesagt um größtmögliche Kompatibiltät zu gewährleisten, zum Beispiel auch im Bereich Barrierefreies Internet (Textbrowser, Screenreader usw.)

[PHP-Desaster]

Ich habe die Erfahrung gemacht, dass man sich damit nur weitere Probleme holt. Zum Beispiel wenn die HTML-Seite mit einem XML-Parser gelesen werden soll. Der kennt die Entitäten von sich aus nicht.
Ich stelle einfach mal ganz frech die Behauptung in den Raum, dass die Nutzung solcher Entitäten genau so dösig ist, wie die Nutzung eines Zeichensatzes != UTF-8.

[pekka]

Es gibt nach wie vor Situationen, in denen man ohne Entitäten nicht auskommt. Entwickelt man zum Beispiel Javascript-Newsticker oder sonstige Dinge, die in fremde Seiten eingebaut werden sollen deren Codierung man nicht kennt, sind entities die einzige mir bekannte Methode, Umlaute einigermaßen zuverlässig und Kodierungsunabhängig zu maskieren.

Das XML-Argument halte ich nicht für Stichhaltig - wenn eine HTML-Datei mit einem XML-Parser gelesen werden soll, ist bereits was schiefgelaufen.

[PHP-Desaster]

Entwickelt man zum Beispiel Javascript-Newsticker oder sonstige Dinge, die in fremde Seiten eingebaut werden sollen deren Codierung man nicht kennt, sind entities die einzige mir bekannte Methode, Umlaute einigermaßen zuverlässig und Kodierungsunabhängig zu maskieren.

Ok, das ist ein Argument. Ist aber definitiv eine Ausnahmesituation.

Das XML-Argument halte ich nicht für Stichhaltig - wenn eine HTML-Datei mit einem XML-Parser gelesen werden soll, ist bereits was schiefgelaufen.

Leider hat man nicht immer die Möglichkeit, auf eine XML-Schnittstelle zuzugreifen. Und wenn die Website valide ist, ist dies oft die einzige Möglichkeit, an die Informationen zu kommen. Ich habe häufig damit zu tun und da machen solche Entitäten schnell mal Probleme, die einfach vermieden werden könnten. Ist aber wahrscheinlich eine genauso spezielle Situation wie der JS-Newsticker.

[wahsaga]

Original geschrieben von pekka
Es gibt nach wie vor Situationen, in denen man ohne Entitäten nicht auskommt. Entwickelt man zum Beispiel Javascript-Newsticker oder sonstige Dinge, die in fremde Seiten eingebaut werden sollen

Es stellt zugegebenermaßen einen Sonderfall dar, wenn man sich ausserhalb der eigenen Projektumgebung bewegt, wo man nicht alles selber unter Kontrolle hat.

Auch dann könnte man bspw. eine bestimmte Kodierung festlegen, oder sie über einen zusätzlichen bei der Einbindung anzugebenden Parameter konfigurierbar machen. (Theorie - dass das in der Praxis nicht reibungslos funktioniert, zeigen z.B. auch immer wieder die Trackbacks in Weblogs, wo plötzlich komische Zeichen auftauchen, weil nicht erfolgreich eine gemeinsame Kodierung ausgehandelt wurde.)


Gerade bei JavaScript sollte das aber eigentlich weniger Probleme machen. Die Kodierung, in der eine JavaScript-Ressource erstellt wurde, lässt sich auch mitgeben - und dann sollte ein funktionsfähiger Browser eigentlich auch keine Probleme haben, Daten aus einem in anderer Kodierung vorliegenden JavaScript zur Kodierung des aktuellen HTML-Dokumentes "passend" zu konvertieren. ("Passend" in Anführungszeichen, weil das natürlich gar nicht immer verlustfrei möglich ist.)