Umlaute verschwinden!! htmlentities

[Siggi]

$test='Österreich';

echo htmlentities($test);

Er müsste es doch nprmal umwandeln, nicht verschlucken!!

Siggi

[dedlfix]

Tach!

$test='Österreich';
echo htmlentities($test);
Er müsste es doch nprmal umwandeln, nicht verschlucken!!

Definiere "normal"! htmlentities() ist darauf angewiesen, die verwendete Kodierung zu kennen, sonst kann es aus den Bytes keine Zeichen herauslesen. Versorge den $encoding-Parameter passend (siehe PHP-Handbuch). Aber andererseits braucht man htmlentities() nicht, wenn man die verwendete Zeichenkodierungen ordentlich dem nachfolgenden System bekanntgibt. Dann reicht nämlich ein htmlspecialchars().

dedlfix.

[suit]

$test='Österreich';
echo htmlentities($test);
Er müsste es doch nprmal umwandeln, nicht verschlucken!!

Definiere "normal"! htmlentities() ist darauf angewiesen, die verwendete Kodierung zu kennen, sonst kann es aus den Bytes keine Zeichen herauslesen. Versorge den $encoding-Parameter passend (siehe PHP-Handbuch). Aber andererseits braucht man htmlentities() nicht, wenn man die verwendete Zeichenkodierungen ordentlich dem nachfolgenden System bekanntgibt. Dann reicht nämlich ein htmlspecialchars().

bzw wenn man zum erzeugen seines Quelltexts eine Funktion wie z.B. SimpleXML nutzt entfällt auch das weitgehend, die Methoden wie z.B. addAttribute oder addChild kümmern sich schon automatisch darum - außer beim & als Elementinhalt per addChild() - das muss man manuell als & maskieren, da der Parser nicht riechen kann, ob man hier eine Referenz machen möchte oder das & im Klartext drin stehen soll.

[Gunnar Bittersmann]

@@Siggi:

nuqneH

echo htmlentities($test);

Das Wichtigste (eigentlich das Einzige), was man über htmlentities() wissen muss, ist, dass es eine der vielen unnützen Funktionen in PHP ist. Nicht verwenden!

Qapla'

[suit]

Das Wichtigste (eigentlich das Einzige), was man über htmlentities() wissen muss, ist, dass es eine der vielen unnützen Funktionen in PHP ist. Nicht verwenden!

Interessant wäre eine Funktion die "Unsichtbare oder nicht unterscheidbare Zeichen" automatisch in entities konvertiert - hier hier ggf. schon mal jemand eine entsprechende Liste erstellt die man verwenden darf?

[dedlfix]

Tach!

Interessant wäre eine Funktion die "Unsichtbare oder nicht unterscheidbare Zeichen" automatisch in entities konvertiert - hier hier ggf. schon mal jemand eine entsprechende Liste erstellt die man verwenden darf?

Wann hat man solche Zeichen - außer   - schon mal im Quelltext stehen? Was nicht händisch bearbeitet wird, also nur von der Datenquelle zum Ziel durchgereicht wird, braucht eine solche Umwandlung nicht. Für den Fall des Debuggings kann man urlencode() missbrauchen. Aber um den ersten Teil zu beantworten: strtr() (in der zweiten Variante) muss nur mit einer entsprechenden Tabelle (sprich: Array) gefüttert werden.

dedlfix.

[suit]

Interessant wäre eine Funktion die "Unsichtbare oder nicht unterscheidbare Zeichen" automatisch in entities konvertiert - hier hier ggf. schon mal jemand eine entsprechende Liste erstellt die man verwenden darf?

Wann hat man solche Zeichen - außer   - schon mal im Quelltext stehen?

Wenn man die Daten über einen Editor eingibt - TinyMCE hat z.B. eine möglichkeit, bestimmte Zeichen bereits bei der Eingabe als entities auszugeben (http://www.tinymce.com/wiki.php/configuration:entities)

Meine Konfiguration sieht hierfür so aus "160,nbsp,38,amp,34,quot,60,lt,62,gt"

Wir haben hier aber oft den Fall, dass wir technische Datenblätter hinterlegen - da wäre es äußerst hilfreich, wenn z.B. Minus-Zeichen, Bindestriche, Multiplikationszeichen einfacher als solche erkennbar wären. Ein blick in den Quelltext reicht um zu sehen ob der Redakteur die Daten richtig eingegeben und nicht verstümmelt hat - ohne dafür erst lästig das Debugging zu aktivieren.

Aber um den ersten Teil zu beantworten: strtr() (in der zweiten Variante) muss nur mit einer entsprechenden Tabelle (sprich: Array) gefüttert werden.

Das wie ist mir klar, mit gings jetzt konkret um die Liste selbst :)

[dedlfix]

Tach!

Wann hat man solche Zeichen - außer   - schon mal im Quelltext stehen?
Wenn man die Daten über einen Editor eingibt - TinyMCE hat z.B. eine möglichkeit, bestimmte Zeichen bereits bei der Eingabe als entities auszugeben (http://www.tinymce.com/wiki.php/configuration:entities)
Wir haben hier aber oft den Fall, dass wir technische Datenblätter hinterlegen - da wäre es äußerst hilfreich, wenn z.B. Minus-Zeichen, Bindestriche, Multiplikationszeichen einfacher als solche erkennbar wären. Ein blick in den Quelltext reicht um zu sehen ob der Redakteur die Daten richtig eingegeben und nicht verstümmelt hat - ohne dafür erst lästig das Debugging zu aktivieren.

Es ist aber auch umständlich, die Quelltextansicht aufzurufen und die richtige Stelle zu finden. Und nur dafür den HTML-Code unnötig aufblähen? Wäre es da nicht sinnvoller, eine Browser-Erweiterung zu erstellen, die ein Zeichen beim Hovern tooltipt oder vielleicht Text markieren und im Kontextmenü eine Funktion aufrufen, die weitere Informationen dazu anzeigt?

dedlfix.

[suit]

Es ist aber auch umständlich, die Quelltextansicht aufzurufen und die richtige Stelle zu finden. Und nur dafür den HTML-Code unnötig aufblähen? Wäre es da nicht sinnvoller, eine Browser-Erweiterung zu erstellen, die ein Zeichen beim Hovern tooltipt oder vielleicht Text markieren und im Kontextmenü eine Funktion aufrufen, die weitere Informationen dazu anzeigt?

Mit einem Entwicklungswerkzeug im Browser ist ersteres kein Problem.

[Gunnar Bittersmann]

@@dedlfix:

nuqneH

Wann hat man solche Zeichen - außer   - schon mal im Quelltext stehen?

Wenn man richtige Gedankenstriche verwendet: '–', nicht '-'. Tut nicht jeder, seufz.

In Monospace-Schriften, die meist in Editoren verwendet werden, sind die Zeichen schwer bis gar nicht zu unterscheiden; escapen mit – kann da durchaus sinnvoll sein.

Analog bei richtigen Minuszeichen (−).

Qapla'

[dedlfix]

Tach!

Wann hat man solche Zeichen - außer   - schon mal im Quelltext stehen?
Wenn man richtige Gedankenstriche verwendet: '–', nicht '-'. Tut nicht jeder, seufz.

Korrekt wären dann aber keine HTML-NCRs oder Entity-Referenzen (auch nicht das von mir erwähnte  ) sondern die jeweilige Schreibweise für String-Literale in der verwendeten Programmiersprache. Also sowas wie \xA0 oder \u2342. Zu früh in der Verarbeitungskette auf ein bestimmtes Ausgabemedium hinzuarbeiten, bereitet nur Probleme, wenn der Code dann doch mal woandershin abzweigen soll.

dedlfix.

[Gunnar Bittersmann]

@@dedlfix:

nuqneH

Korrekt wären dann aber keine HTML-NCRs oder Entity-Referenzen (auch nicht das von mir erwähnte  ) sondern die jeweilige Schreibweise für String-Literale in der verwendeten Programmiersprache.

Kommt drauf an, ob nicht aus irgendeinem Grund die Zeichen im generierten HTML-Code unterscheidbar haben möchte. So denn überhaupt HTML generiert wird. Und mir fällt auch nicht wirklich ein Grund ein.

Zu früh in der Verarbeitungskette auf ein bestimmtes Ausgabemedium hinzuarbeiten, bereitet nur Probleme, wenn der Code dann doch mal woandershin abzweigen soll.

Da hast du zweifelslos recht.

Qapla'

[Gunnar Bittersmann]

@@Gunnar Bittersmann:

nuqneH

Und mir fällt auch nicht wirklich ein Grund ein.

Ha, doch. Auch im PHP-Code sind   und – besser lesbar als irgendwelche Codepoints.

Qapla'