nicht angemeldet
Matthias Apsel
dedlfix
dedlfix
dedlfix
dedlfix
Matthias Apsel
dedlfix
Matthias Apsel
Matthias Apsel
Hallo!
Wieder so eine Frage, wo ich jahrelang stöbern könnte...
Gibt es eine php-Funktion, die so ähnlich arbeitet wie htmlspecialchars() oder htmlentities() - nur andersrum? Also nicht html_entity_decode()! Ich brauche Umlaute codiert (ü => ü) aber html-Tags sollen unangetastet bleiben! Am Besten noch Anführungszeichen escaped.
Ich habe vor User-Input direkt in eine .php schreiben zu lassen (Übersetzung) was dann direkt über include() eingebunden wird. Allerdings kommen da immer wieder auch mal html-Tags vor!
Im Moment habe ich htmlentities(); am Wickel, aber das entschärft mir aber auch alle verbauten html-Tags... :( Die hätte ich allerdings gerne im echo-fähigen Format!
Nach dem Prinzip:
User Input:
Ich hätte gerne eine <font size="3">korrekte</font> Kodierung!
==> per _POST ==> $Array[] ==> foreach ==> fputs(sprache.php);
Output in der php-Datei:
Ich hätte gerne eine <font size="3">korrekte</font> Kodierung!
Output auf der Website:
Ich hätte gerne eine korrekte Kodierung!
Wobei "korrekte" eben html-mäßig fontsize 3 hat...
Gibt es sowas schon in php implementiert, oder muß ich das von Hand selber bauen?
Dankbar für jeden Hinweis,
chris
Moin!
Wieder so eine Frage, wo ich jahrelang stöbern könnte...
Wieder so eine Idee, wo man jahrelang die Sicherheitslücken am abdichten wäre...
Gibt es eine php-Funktion, die so ähnlich arbeitet wie htmlspecialchars() oder htmlentities() - nur andersrum? Also nicht html_entity_decode()! Ich brauche Umlaute codiert (ü => ü) aber html-Tags sollen unangetastet bleiben! Am Besten noch Anführungszeichen escaped.
Ich habe vor User-Input direkt in eine .php schreiben zu lassen (Übersetzung) was dann direkt über include() eingebunden wird. Allerdings kommen da immer wieder auch mal html-Tags vor!
Wenn HTML-Tags unangetastet bleiben, dann doch sicher auch sowas hier:
Hallo <b>Welt</b><?php call_world_domination(); ?>
Und damit hast du dann verloren.
Selbst mit HTML allein hast du verloren, mit XSS und CSRF kann man genug Schaden anrichten.
Im Moment habe ich htmlentities(); am Wickel, aber das entschärft mir aber auch alle verbauten html-Tags... :( Die hätte ich allerdings gerne im echo-fähigen Format!
Nach dem Prinzip:User Input:
Ich hätte gerne eine <font size="3">korrekte</font> Kodierung!
==> per _POST ==> $Array[] ==> foreach ==> fputs(sprache.php);Output in der php-Datei:
Ich hätte gerne eine <font size="3">korrekte</font> Kodierung!
Die Kodierung muss aber sowieso korrekt sein. Ich verstehe dein Ansinnen nicht.
Das Eingabeformular des HTML schickt die Daten in einer Kodierung. Diese muss bekannt sein und bei htmlentities() berücksichtigt werden, ansonsten kommt Müll raus.
Man kann das an dieser Stelle aber auch weglassen, und hat bei der Ausgabe einfach dieselbe Kodierung. Funktioniert auch.
Nur mindestens zwei Dinge sind böse: 1. PHP Code Include, und 2. Userdefiniertes HTML mit beliebiger Javascript-Einbindung.
Output auf der Website:
Ich hätte gerne eine korrekte Kodierung!
Wobei "korrekte" eben html-mäßig fontsize 3 hat...Gibt es sowas schon in php implementiert, oder muß ich das von Hand selber bauen?
Wenn du das Risiko grundsätzlich tragen willst: Es gibt nur genau eine Library, die dir dein HTML saubermacht: HTMLPurifier. Es gibt mehr Libarys, die das versuchen, aber daran scheitern. Offensichtlich ist das ein sehr schwieriges Unterfangen. Siehe z.B. diesen Vergleich: http://blog.astrumfutura.com/2010/08/html-sanitisation-the-devils-in-the-details-and-the-vulnerabilities/
Das Ausführen von PHP zu unterlassen wäre hingegen sehr simpel: Nimm einfach kein include() und kein require(). Diese Funktionen sind sowieso überflüssig, weil du ja nur HTML in den Dateien hast. Du musst also den darin nicht enthaltenen PHP-Code auch nicht ausführen.
readfile() wäre die einfache Alternative. Oder eine Kombination aus file_get_contents() und echo.
Aber ich hätte da jetzt echt Angst um deine Website.
- Sven Rautenberg
Oh wow!
Danke für die rote Lampe!!! Das man so auch php-funktionen einschleusen könnte, hatte ich gar nicht aufm Radar!
Und überhaupt Danke für die Antworten!!!
Eine gewisse Sicherheit ist in meinen Augen gegeben, da die erstellte Datei erst noch ins System eingetragen werden muß. Das passiert von Hand. Da müßte man also nochmal ein paar rote Ampeln aufstellen, daß man die Datei sorgfältig prüfen muß, bevor man sie tatsächlich einbindet. Oder ist das Risiko tatsächlich viel höher als ich verstehe???
Um mal ein bißchen näher ins Detail zu gehen, hier mal die Art der Verarbeitung:
Ich habe die gesamte Übersetzung in einem Array namens $loc_lang[]. Dieses liegt für die verschiedenen Sprachen in einer entsprechenden Datei: sprache.php, die dann in jede Seite includiert wird. Wenn ihr nun sagt, 'das ist absolut unsicher', dann glaube ich das und muß nun umbauen, so daß bei jedem Seitenaufruf eine Text-Datei eingelesen und konvertiert wird, in das Array eingelesen werden muß. Das dürfte ein ziemlich Ressourcen-intensiver Sortier- und Zuweisungsvorgang sein...
In diesem Falle könnt ihr den Rest des postings skippen!
deutsch.php (wird per dropdown vom User ausgewählt und die entsprechende php wird includiert)
Auszug:
<?php
...
$loc_lang["remove"] = "entfernen";
$loc_lang["select_country"] = "Wähle Land!";
$loc_lang["country_other"] = "Anderes";
$loc_lang["shipping"] = "Versand";
$loc_lang["choose_payment"] = "Wähle Zahlung!";
$loc_lang["banktransfer"] = "Überweisung";
$loc_lang["paypal"] = "PayPal";
$loc_lang["payondelivery"] = "Nachnahme";
$loc_lang["reset_kart"] = "Verwerfe Warenkorb";
$loc_lang["total"] = "Gesamt";
...
$loc_lang["admin_notelangfile"] = "Beachten Sie, daß Sie eine übersetzte \"sprache.php\" im Verzeichnis shop/locale brauchen!!!<br>Sie können die Sprachdatei <a href=\"../translate.php\" target=\"_blank\">hier</a> übersetzen. Weiter unten können Sie vorhandene Dateien verarbeiten!";
...
?>
Englisch habe ich noch selbst hinbekommen, damit ists aber Schluß bei mir mit den Sprachen.
In der translate.php (Wo man das gesamte Array dann übersetzt) stark vereinfacht
include('../locale/deutsch.php');
foreach($loc_lang as $key => $value)
{
echo "<textarea name=\"$key\">$value</textarea>
}
das geht per $_POST an save_new_lang.php: ebenfalls stark vereinfacht!
foreach($_POST as $key => $value)
{
$str = "\$loc_lang[\"$key\"] = \"$value\";\n";
fputs($fHandle, $str);
}
So, jetzt haben wir die Datei im Verzeichnis. Damit diese auch verfügbar wird, muß sie noch in ein anderes include-file eingetragen werden, nämlich conf.php:
selbes Schema, selbes Format, nur daß dort dann folgendes auftaucht:
<?php
...
$conf["lang"]["0"] = "deutsch";
$conf["lang"]["1"] = "english";
...
?>
Jetzt muß die eben erstellte Sprache.php hier eingetragen sein, um wirklich benutzt zu werden.
Nun wäre das der Moment, wo sich alle Weichen stellen, nicht wahr? Entweder, ich trage sie ungesehen ein, oder eben nicht.
Schlußendlich wirds dann wieder irgendwo angezeigt: Beispiel.php
<?php
include('../locale/neue_sprache.php');
include('header.html');
echo "<body>\nHier wäre irgendein Inhalt, tables etc...<br>\n";
echo "<table><tr><td>{$loc_lang["irgendwas"]}</td></tr></table>\n";
echo "</body>\n</html>";
?>
Und somit stellt sich die Frage:
Würdet ihr das sein lassen und alles per text->php->text konvertieren, oder ist das eigentlich in Ordnung, solange im letzten Schritt Vorkehrungen getroffen werden? (Z.Bsp. daß nur valide <a href>'s gesetzt werden und so?)
Schönen Dank!
chris
Om nah hoo pez nyeetz, chris_blues!
Schlußendlich wirds dann wieder irgendwo angezeigt: Beispiel.php
<?php
include('../locale/neue_sprache.php');
include('header.html');
echo "<body>\nHier wäre irgendein Inhalt, tables etc...<br>\n";
echo "<table><tr><td>{$loc_lang["irgendwas"]}</td></tr></table>\n";
echo "</body>\n</html>";
?>
Das so zu machen ist auch nicht geschickt. Statt
~~~php
echo "<body>\nHier wäre irgendein Inhalt, tables etc...<br>\n";
echo "<table><tr><td>{$loc_lang["irgendwas"]}</td></tr></table>\n";
echo "</body>\n</html>";
ist besser
<body>
ganz viel Inhalt
<p>Im wahren Warenkorb befinden sich wahre Waren für <?php echo $preis;?> Euronen.</p>
ganz viel mehr Inhalt
</body>
Wobei man je nach Serverkonfiguration auch schreiben darf:
<p>Im wahren Warenkorb befinden sich wahre Waren für <?=$preis?> Euronen.</p>
Matthias
<body>
ganz viel Inhalt
<p>Im wahren Warenkorb befinden sich wahre Waren für <?php echo $preis;?> Euronen.</p>
ganz viel mehr Inhalt
</body>
Guter Tip! Diese ewige Escaperei ist auch wirklich anstrengend!
Hach es gibt so viel zu lernen, alle Wege führen nach Rom, wähle einen... :-/
Nur, was ich hier mich hier noch wundere, wie käme die Übersetzung da jetzt ins Spiel? Das ist ja nun gar nicht variabel, abgesehen von dem $preis.
Ist vllt ne doofe Frage, aber außer `echo $loc_lang["bla"];`{:.language-php} gibts da nicht so viele Möglichkeiten oder?
Nur, was ich hier mich hier noch wundere, wie käme die Übersetzung da jetzt ins Spiel? Das ist ja nun gar nicht variabel, abgesehen von dem $preis.
Ist vllt ne doofe Frage, aber außerecho $loc_lang["bla"];gibts da nicht so viele Möglichkeiten oder?
Richtig, in dem Fall müsstest du die Texte dann doch mit PHP ausgeben. Die HTML-Tags solltest du aber weiterhin direkt notieren. Also statt
<p>Im wahren Warenkorb befinden sich wahre Waren für <?=$preis?> Euronen.</p>
schreibt man dann üblicherweise:
<p><?php echo htmlspecialchars(translate('Im wahren Warenkorb befinden sich wahre Waren für %1$s Euronen.', $preis)) ?></p>
Wobei die translate-Funktion das Pattern zuerst übersetzt und dann mit allen Parametern an sprintf weitergibt, in etwa so:
function translate ($pattern) {
$options = func_get_args();
array_shift($options);
if (isset($translationArray[$pattern])) {
$pattern = $translationArray[$pattern]
}
return sprintf($pattern, $options);
}
<p><?php echo htmlspecialchars(translate('Im wahren Warenkorb befinden sich wahre Waren für %1$s Euronen.', $preis)) ?></p>Wobei die translate-Funktion das Pattern zuerst übersetzt und dann mit allen Parametern an sprintf weitergibt, in etwa so:
function translate ($pattern) {
$options = func_get_args();
array_shift($options);
if (isset($translationArray[$pattern])) {
$pattern = $translationArray[$pattern]
}
return sprintf($pattern, $options);
}
Ich glaube nicht, daß ich Dir so ganz folgen kann an dieser Stelle. Ist es nicht einfacher, ich habe einen Seitenaufruf:
beispiel.php?lang=deutsch
Dann steht ganz vorne `$lang=$_GET["lang"];`{:.language-php}
dann `include("locale/$lang.php");`{:.language-php}
und im Inhalt dann schließlich:
`<p><? echo "{$loc_lang["im_warenkorb_befinden_sich_1"]} $preis {$loc_lang["im_warenkorb_befinden_sich_2"]}"; ?></p>`{:.language-php}
Wobei in "locale/$lang.php" immer das selbe Array aufgebaut wird, nur mit anderen Werten/Inhalten, verschiedene Sprachen halt.
Das ist jedenfalls der Ansatz mit dem ich angefangen habe. Simplistisch halt.
Mit Deiner Methode, so scheint mir jedenfalls, ist ein nicht ganz unerheblicher Programmieraufwand verbunden, oder versteh ich hier irgendwas falsch?
Man übergibt der function translate den gewünschten Text, Dann wird in einem Array, was wohl alle Sprachen beinhalten muß nach der Entsprechung gesucht und das ganze dann an echo geschickt. Korrigier mich, wenn ich da was vermurkse! :)
Das würde aber bedeuten, daß ich alle! Sprachen in einem Array haben muß, was bei 2 Sprachen vllt nicht so wild ist, aber bei vielen Sprachen ganz schön gigantisch werden dürfte. Und das muß ich ja bei jeder Seite neu laden. Ist da nicht der Ansatz, ein Array zu haben, wo nur die geforderte Sprache drin ist, einfacher und ressourcenschonender?
Aber danke für deinen Input!
chris
Ich glaube nicht, daß ich Dir so ganz folgen kann an dieser Stelle. Ist es nicht einfacher, ich habe einen Seitenaufruf:
beispiel.php?lang=deutsch
Dann steht ganz vorne$lang=$_GET["lang"];
danninclude("locale/$lang.php");
und im Inhalt dann schließlich:
<p><? echo "{$loc_lang["im_warenkorb_befinden_sich_1"]} $preis {$loc_lang["im_warenkorb_befinden_sich_2"]}"; ?></p>
Diese Vorgehensweise beinhaltet einige Probleme:
* Die Sätze sind zerstückelt - schlecht für den Übersetzer
* Die Reihenfolge der variablen Inhalte ist für den Übersetzer nicht änderbar
* Bei fehlender Übersetzung wird kein Text angezeigt
* Für dich wird es schwer, Code anhand der Ausgabe zu finden
* Du musst irgendwie sicherstellen, dass gleiche Keys nicht mehrfach verwendet werden bzw. nur, wenn die Bedeutung gleich ist.
* der Text wird nicht escaped - ok, das machst du evtl. an anderer Stelle…
Mit Deiner Methode, so scheint mir jedenfalls, ist ein nicht ganz unerheblicher Programmieraufwand verbunden, oder versteh ich hier irgendwas falsch?
Der Aufwand ist nicht wirklich größer. Du brauchst halt eine Übersetzungs-Funktion (die in ähnlicher Form z.B. im Zend Framework bereits enthalten ist) und rufst diese dann an allen Stellen wo Text ausgeben werden soll auf. Zusätzlich zu dem, was ich aufgeschrieben hatte, muss diese noch an das Übersetzungs-Array kommen - dieses entspricht deinem $loc_lang und ist entweder irgendwie global verfügbar oder du packst die translate-Funktion ist ein Objekt und gibst diesem dein Array mit.
$loc_lang würde dann je nach Zielsprache z.B. so aussehen:
$loc_lang = array(
'Im Warenkorb befinden sich Waren für %1$s Euronen.' =>
'The basket of goods are for %1$s Euros',
'Noch ein anderer Text' =>
'Yet another text'
);
Man übergibt der function translate den gewünschten Text, Dann wird in einem Array, was wohl alle Sprachen beinhalten muß nach der Entsprechung gesucht und das ganze dann an echo geschickt. Korrigier mich, wenn ich da was vermurkse! :)
Das würde aber bedeuten, daß ich alle! Sprachen in einem Array haben muß, was bei 2 Sprachen vllt nicht so wild ist, aber bei vielen Sprachen ganz schön gigantisch werden dürfte.
Nein. Die translate-Funktion muss nur das Array für die Sprache kennen, die du ausgeben willst.
$loc_lang würde dann je nach Zielsprache z.B. so aussehen:
$loc_lang = array(
'Im Warenkorb befinden sich Waren für %1$s Euronen.' =>
'The basket of goods are for %1$s Euros','Noch ein anderer Text' =>
'Yet another text'
);
>
> > Man übergibt der function translate den gewünschten Text, Dann wird in einem Array, was wohl alle Sprachen beinhalten muß nach der Entsprechung gesucht und das ganze dann an echo geschickt. Korrigier mich, wenn ich da was vermurkse! :)
> > Das würde aber bedeuten, daß ich alle! Sprachen in einem Array haben muß, was bei 2 Sprachen vllt nicht so wild ist, aber bei vielen Sprachen ganz schön gigantisch werden dürfte.
>
> Nein. Die translate-Funktion muss nur das Array für die Sprache kennen, die du ausgeben willst.
Ah, danke fürs klarifizieren!
Also ist das Modell, $lang.php einzubinden schon das selbe, nur daß ich anstelle von kurzen $keys den ganzen String einbringe als $key, mit Platzhaltern für irgendwelche anderen Größen. Was also auch unter anderem heißen würde, daß ich beispielsweise für deutsch ein Array habe mit identischen $keys und $values, korrekt? Wenn man mal annimmt, daß ich die deutschen Strings verbaue...
Also ist das Modell, $lang.php einzubinden schon das selbe, nur daß ich anstelle von kurzen $keys den ganzen String einbringe als $key, mit Platzhaltern für irgendwelche anderen Größen.
Vollkommen richtig :-)
Was also auch unter anderem heißen würde, daß ich beispielsweise für deutsch ein Array habe mit identischen $keys und $values, korrekt?
Könntest du so machen, ist aber unnötig - du kannst das Array auch einfach leer lassen, dann wird die Sprache ausgegeben, die im Quellcode steht (im diesem Fall deutsch).
Wenn man mal annimmt, daß ich die deutschen Strings verbaue...
Das ist in der Tat so eine Sache. Du solltest überlegen, welche Sprache deine Besucher/Übersetzer hauptsächlich sprechen (werden). Bei internationalen Projekten ist Englisch als Quellsprache immer erste Wahl. Wenn du aber hauptsächlich Besucher aus Deutschland hast kann es durchaus sinnvoll sein, deutsche Patterns zu verwenden.
Vielen Dank für Deine Ausführungen! Leuchtet absolut ein!
Schöne Grüße
chris
Ich bin immer noch nicht ganz fertig mit den Sicherheitsbedenken! :) (...bin da auch alles andere als bewandert!)
Ok, wenn ich also html-tags verbiete, bzw weiter mit htmlentities arbeite, dann müßte ich die strings nochmals zerstückeln, um die Tags hart zu kodieren (oder andersrum gesagt: die Tags aus den Strings rauszubekommen) und den sichtbaren Inhalt wieder als Variable einfügen. Dann erschiene höchstens, im Falle eines Angriffsversuchs, der Code als Text im Browser. Habe ich das richtig verstanden?
Nur mindestens zwei Dinge sind böse: 1. PHP Code Include, und 2. Userdefiniertes HTML mit beliebiger Javascript-Einbindung.
Zu 1.:
Was wäre denn eine Alternative zum include()? Jetzt in jede php den html-header reinschreiben scheint mir keine gute Lösung. Dazu ist es doch da, oder? Habe bei php.net auch schon ein paar Kommentare gesehen, daß das include() als 'deprecated' gilt, verstanden warum, habe ich es allerdings nicht so richtig.
Zu 2.:
was heißt das?
Beispiel: wenn ein User/Bot/wasauchimmer JavaScript einträgt, was würde denn damit passieren, nach der Bearbeitung mit htmlentities()? Würde der Code ausgeführt werden oder als Text dargestellt?
Danke für Eure großartige Hilfe!
chris
Om nah hoo pez nyeetz, chris_blues!
Danke für Eure großartige Hilfe!
Ich empfehle dir auch, das Tabellenlayout über Bord zu werfen. Du machst dir die Pflege der Seite wesentlich einfacher.
Matthias
Tach!
Ok, wenn ich also html-tags verbiete, bzw weiter mit htmlentities arbeite, dann müßte ich die strings nochmals zerstückeln, um die Tags hart zu kodieren (oder andersrum gesagt: die Tags aus den Strings rauszubekommen) und den sichtbaren Inhalt wieder als Variable einfügen. Dann erschiene höchstens, im Falle eines Angriffsversuchs, der Code als Text im Browser. Habe ich das richtig verstanden?
Was ist denn das eigentliche Ziel? Die Anwender sollen dir beim Übersetzen von Texten helfen und am Ende soll PHP-Code herauskommen, der ein Array mit den Übersetzungen erstellt? Die Idee mit dem Array ist nicht verkehrt, alles andere wird weniger performant werden. Was macht darin das HTML? Dinge hervorheben à la <b>fett</b>? Dann kannst du nur entweder eine Pseudosyntax (BBCode oder anderes) verwenden, die in korrektes HTML übersetzt wird, ansonsten aber unschädlich ist. Oder du nimmst alle Texte per Hand entgegen und kontrollierst sie, bevor du die fertige Datei einbindest. Dabei musst du zumindest auch alle < und & im Text beachten und HTML-gerecht notieren.
Nur mindestens zwei Dinge sind böse: 1. PHP Code Include, und 2. Userdefiniertes HTML mit beliebiger Javascript-Einbindung.
Zu 1.:
Was wäre denn eine Alternative zum include()? Jetzt in jede php den html-header reinschreiben scheint mir keine gute Lösung. Dazu ist es doch da, oder? Habe bei php.net auch schon ein paar Kommentare gesehen, daß das include() als 'deprecated' gilt, verstanden warum, habe ich es allerdings nicht so richtig.
include deprecated? Ganz sicher nicht. Vielleicht wird in bestimmten Anwendungsfällen von seiner Verwendung abgeraten, wenn für diejenigen Fälle potentiell bessere Möglichkeiten vorhanden sind. Zum Beispiel readfile(), wenn kein PHP-Code auszuführen ist oder Autoloading für OOP.
Es geht in deinem Fall nur darum, keinen PHP-Code auszuführen, den irgendwer unkontrolliert eingeben kann.
Zu 2.: was heißt das?
Beispiel: wenn ein User/Bot/wasauchimmer JavaScript einträgt, was würde denn damit passieren, nach der Bearbeitung mit htmlentities()? Würde der Code ausgeführt werden oder als Text dargestellt?
htmlspecialchars() reicht, htmlentities() verunstaltet unnötigerweise Umlaute und andere Zeichen. Nachdem <, >, & und " als <, >, & und " beim Browser ankommen, wirken diese Zeichen literal und haben keine auführende Wirkung mehr. Das heißt, der Anwender sieht das als den Text, als der er eingegeben wurden.
dedlfix.
Erstmal Danke fürs beruhigen :)
Was ist denn das eigentliche Ziel? Die Anwender sollen dir beim Übersetzen von Texten helfen und am Ende soll PHP-Code herauskommen, der ein Array mit den Übersetzungen erstellt? Die Idee mit dem Array ist nicht verkehrt, alles andere wird weniger performant werden. Was macht darin das HTML? Dinge hervorheben à la <b>fett</b>? Dann kannst du nur entweder eine Pseudosyntax (BBCode oder anderes) verwenden, die in korrektes HTML übersetzt wird, ansonsten aber unschädlich ist. Oder du nimmst alle Texte per Hand entgegen und kontrollierst sie, bevor du die fertige Datei einbindest. Dabei musst du zumindest auch alle < und & im Text beachten und HTML-gerecht notieren.
Genau, Anwender sollen sozusagen mithelfen, die ganze Anwendung zu übersetzen (es handelt sich um einen selbstgestrickten Webshop). Dazu habe ich alle Textbausteine in eine sprache.php ausgelagert, in der nur das Array steht, angeführt von <?php und abschließend ?>. Dazwischen ist eine inzwischen ganz schön lange Liste von $loc_lang["name_des_bausteins"] = "irgendein text";. Das ist alles was da drin steht. Nachdem alles übersetzt ist wirds in eine neu Datei 'neue_sprache.php' geschrieben. Wenn ich das dann von Hand in einem $conf["lang"]["n"] = "neuesprache"; eintrage, steht es auch tatsächlich zur Auswahl.
htmlspecialchars() reicht, htmlentities() verunstaltet unnötigerweise Umlaute und andere Zeichen. Nachdem <, >, & und " als <, >, & und " beim Browser ankommen, wirken diese Zeichen literal und haben keine auführende Wirkung mehr. Das heißt, der Anwender sieht das als den Text, als der er eingegeben wurden.
Gut! Das beruhigt! Aber, besonders bei fremden Sprachen brauch ich doch eine gute Sonderzeichen-Kodierung oder? Wenn ich da an russisch denke, oder französisch...
Moin!
Gut! Das beruhigt! Aber, besonders bei fremden Sprachen brauch ich doch eine gute Sonderzeichen-Kodierung oder? Wenn ich da an russisch denke, oder französisch...
Du brauchst UTF-8 als Kodierung, mehr nicht. Da drin sind alle Zeichen der Welt möglich, mit denen Computer umgehen können - das sollte reichen.
- Sven Rautenberg
Gut! Das beruhigt! Aber, besonders bei fremden Sprachen brauch ich doch eine gute Sonderzeichen-Kodierung oder? Wenn ich da an russisch denke, oder französisch...
Du brauchst UTF-8 als Kodierung, mehr nicht. Da drin sind alle Zeichen der Welt möglich, mit denen Computer umgehen können - das sollte reichen.
- Sven Rautenberg
Ok, ich glaube, langsam zu verstehen!
Also htmlspecialchars, um evtl Code zu entschärfen, und all den Rest besorgt ein konsistentes UTF-8.
Danke!
Schöne Grüße
chris
Tach!
Also htmlspecialchars, um evtl Code zu entschärfen, und all den Rest besorgt ein konsistentes UTF-8.
Im Prinzip ja. In deinem Fall - also wenn du HTML in den Texten stehen haben willst - dann müssen gleich die HTML-eigenen Zeichen, die nicht Code-Bestandteil sein sollen, entsprechend maskiert notiert sein und htmlspecialchars() entfällt.
dedlfix.
Ok! So kann man sich selbst austricksen! Es macht absolut Sinn (ich habs auch gerade mal ausprobiert), daß UTF-8 ja alle Sonderzeichen schon integriert hat, also ist auch ein ü völlig unsinnig, da ja das ü vorhanden ist. Dieses konvertieren machte mich überhaupt wahnsinnig. Was nehme ich jetzt eigentlich? htmlentities oder html_entity_decode??? Aargh!
Danke für diese überaus arbeitserleichternde Erklärungen!
Ich habe mich entschlossen, den Sicherheitsempfehlungen zu folgen und habe die html-Parts aus den Übersetzungen verbannt (htmlspecialchars). Das einzige was nervt, sind die doch öfter mal auftauchenden <br>'s! Aber wenn ich am Ende der sprache.php ein foreach => nl2br einsetze, könnte sich das ja evtl erledigen, dann bleibt nur noch ein "\n" in den Strings, und <br> wird später eingefügt, wenn es gebraucht wird.
So siehts jetzt aus:
deutsch.php (auszug)
$loc_lang["admin_notelangfile_1"] = "Beachten Sie, daß Sie eine übersetzte \"sprache.php\" im Verzeichnis shop/locale brauchen!!!\nSie können die Sprachdatei";
$loc_lang["admin_notelangfile_2"] = "hier";
$loc_lang["admin_notelangfile_3"] = "übersetzen. Weiter unten können Sie vorhandene Dateien verarbeiten!";
und edit_lang.php (der essentielle Auszug):
echo "{$loc_lang["admin_notelangfile_1"]} <a href=\"../translate.php\" target=\"_blank\">{$loc_lang["admin_notelangfile_2"]}</a> {$loc_lang["admin_notelangfile_3"]}";
Erzeugt im Browser eine Ausgabe, in etwa so:
Beachten Sie, daß Sie eine übersetzte "sprache.php" im Verzeichnis shop/locale brauchen!!!
Sie können die Sprachdatei hier übersetzen. Weiter unten können Sie vorhandene Dateien verarbeiten!
==============================================
Was CSS vs. Tabellenlayout angeht, so sehe ich zwar die Vorteile, um Elemente Website-weit zu "stylen" aber das, was ich mit Tabellen anstellen kann... wie soll ich das mit CSS machen???
Aber das führt in diesem Thread zu weit, zumal ich mich noch weiter zum Thema CSS belesen muß!
Aber vllt hat ja jemand noch ein Stichwort zum schnelleren Auffinden parat.
Ich danke Euch allen für Eure Hilfe, Links und Hinweise!
Ick geh jetzt schlafen und verdauen! :)
Jruß,
chris
...hätte ja klappen können mit dem Link... :D
Gute Nacht!
Tach!
Gibt es eine php-Funktion, die so ähnlich arbeitet wie htmlspecialchars() oder htmlentities() - nur andersrum? Also nicht html_entity_decode()! Ich brauche Umlaute codiert (ü => ü) aber html-Tags sollen unangetastet bleiben! Am Besten noch Anführungszeichen escaped.
strtr() in der zweite Version. Und get_html_translation_table() könnte dich interessieren. Die dich nciht interessierenden Zwichen kannst du über die Flags steuern und die nicht steuerbaren mit unset() entfernen.
Ich habe vor User-Input direkt in eine .php schreiben zu lassen (Übersetzung) was dann direkt über include() eingebunden wird. Allerdings kommen da immer wieder auch mal html-Tags vor!
Und warum willst du da die Umlaute nicht direkt schreiben?
Ich hätte gerne eine <font size="3">korrekte</font> Kodierung!
Die bekommst du, wenn du die Zeichenkodierung durchgängig zwischen allen beteiligten Systemem korrekt beachtest.
dedlfix.
Vielen Dank! Das muß ich jetzt erstmal kapieren, in meinem Falle wäre es wohl utf8_strtr().
Tach!
strtr()
Vielen Dank! Das muß ich jetzt erstmal kapieren, in meinem Falle wäre es wohl utf8_strtr().
Das gibt es nicht. Wenn du wirklich meinst, die Zeichen nicht direkt verwenden zu können, dann muss der Quelltext, in dem dein Übersetzungsarray steht, UTF-8-kodiert sein. Wenn du get_html_translation_table() nimmst, dann kannst du auch ein Encoding angeben.
dedlfix.
strtr()
... utf8_strtr() ...
Das gibt es nicht.
Da bin ich in den Kommentaren drüber gestolpert... Aber wie gesagt, das muß ich jetzt in Ruhe erstmal durchtesten und rumprobieren.
Om nah hoo pez nyeetz, chris_blues!
Gibt es eine php-Funktion, die so ähnlich arbeitet wie htmlspecialchars() oder htmlentities() - nur andersrum? Also nicht html_entity_decode()! Ich brauche Umlaute codiert (ü => ü) aber html-Tags sollen unangetastet bleiben! Am Besten noch Anführungszeichen escaped.
Stellt sich natürlich die Frage nach dem warum. Bei Verwendung der richtigen Zeichenkodierung von Anfang bis Ende gäbe es keinen Grund, die Umlaute zu verstümmeln.
User Input:
Ich hätte gerne eine <font size="3">korrekte</font> Kodierung!
==> per _POST ==> $Array[] ==> foreach ==> fputs(sprache.php);
font sollte nicht verwendet werden. Gestaltung gehört ins CSS.
Output in der php-Datei:
Ich hätte gerne eine <font size="3">korrekte</font> Kodierung!
aus "<" wieder "<" zu machen sollte nicht so das Problem sein.
Matthias
Ich hätte gerne eine <font size="3">korrekte</font> Kodierung!
==> per _POST ==> $Array[] ==> foreach ==> fputs(sprache.php);font sollte nicht verwendet werden. Gestaltung gehört ins CSS.
Das wäre jetzt mit CSS gefühlt doppelt soviel Tipperei. Bei meiner eher kleinen, übersichtlichen Seite wäre CSS wohl eher was Richtung overkill...
folkadelic.de
Ach so:
Stellt sich natürlich die Frage nach dem warum. Bei Verwendung der richtigen Zeichenkodierung von Anfang bis Ende gäbe es keinen Grund, die Umlaute zu verstümmeln.
Wie würdest Du denn das anstellen, damit ein ö in einer textarea -> php-file --> echo-output wieder zu einem ö wird und nicht irgendwas komisches?
Tach!
Stellt sich natürlich die Frage nach dem warum. Bei Verwendung der richtigen Zeichenkodierung von Anfang bis Ende gäbe es keinen Grund, die Umlaute zu verstümmeln.
Wie würdest Du denn das anstellen, damit ein ö in einer textarea -> php-file --> echo-output wieder zu einem ö wird und nicht irgendwas komisches?
Wenn du die Zeichenkodierung nicht dem Zufall überlässt, sondern gezielt darauf achtest, sie korrekt zu verwenden und dem jeweils nächsten System richtig mitzuteilen, dann brauchst du keine weiteren Verrenkungen mit irgendwelchen Ersatzschreibweisen anzustellen.
dedlfix.
Wenn du die Zeichenkodierung nicht dem Zufall überlässt, sondern gezielt darauf achtest, sie korrekt zu verwenden und dem jeweils nächsten System richtig mitzuteilen, dann brauchst du keine weiteren Verrenkungen mit irgendwelchen Ersatzschreibweisen anzustellen.
Bei mir läuft aus Glaubensgründen immer UTF-8! :) Besonders im Zusammenhang mit Übersetzungen ist das ja unabdingbar! Und gerade da brauche ich ja diese ganzen komischen Sonderzeichen. Ich war schon ganz von den Socken, wie sauber das geht, beim Verschicken von emails mit text/plain in UTF-8. Ich war begeistert. Etwas schockiert war ich, als ich den selben String per echo ausspucken ließ... Da dachte ich, ich komme wohl um diese Konvertiererei nicht drumrum.
Mal noch ein bißchen weiterschmökern bei deinem Link...
Muchas graçias
Om nah hoo pez nyeetz, chris_blues!
Das wäre jetzt mit CSS gefühlt doppelt soviel Tipperei. Bei meiner eher kleinen, übersichtlichen Seite wäre CSS wohl eher was Richtung overkill...
eher andersrum. Allein für dein Menü schreibst du 5 mal <font color="#E1CF91" size="5" face="Georgia"> und ein mal <font color="andere Farbe" size="5" face="Georgia">
Das bräuchtest du nur einmal schreiben. Ebenso align="center", ...
Eine Abkehr vom Tabellenlayout und auch hin zu konsequenter CSS-Nutzung ließe deine Seite deutlich besser dastehen.
Matthias
Om nah hoo pez nyeetz, chris_blues!
Nachtrag: Wenn du die Gestaltung komplett ins CSS auslagern würdest, bräuchtest du auch keine "<" in deinem übersetzten Texten zu berücksichtigen.
Matthias
Nachtrag: Wenn du die Gestaltung komplett ins CSS auslagern würdest, bräuchtest du auch keine "<" in deinem übersetzten Texten zu berücksichtigen.
Verdammte Axt! Dann muß ich mich wohl doch noch Mal in CSS einlesen. Ich hatte gehofft, ich käme drumrum...
Aber wie es aussieht würde sich das auch für mich lohnen...
Danke für die Hinweise!