nicht angemeldet dedlfix
dedlfix
Gunnar Bittersmann
dedlfix
Gunnar Bittersmann
dedlfix
Gunnar Bittersmann
dedlfix
dedlfix
Felix Riesterer
Hallo alle Zusammen, habe folgende Frage kann mir vielleicht jemand erklären wie ich Umlaute richtig in PHP anzeigen lassen kann. Ich finde hier im WIKI und im Internet keine Lösungen welche ich verstehe. Deswegen bitte ich euch um Hilfe! Dankeschön schon mal im Voraus!
Tach!
habe folgende Frage kann mir vielleicht jemand erklären wie ich Umlaute richtig in PHP anzeigen lassen kann. Ich finde hier im WIKI und im Internet keine Lösungen welche ich verstehe.
Das ist kein einfaches Ausführen eines einzelnen Befehls oder so. Du musst die gesamte Verarbeitungskette korrekt einstellen. Da das nicht in wenigen Worten erläutert ist, gibts im Wiki die Artikel zur Zeichenkodierung. Du solltest da schon etwas konkreter nachfragen, wenn du etwas nicht verstehst.
dedlfix.
Hallo, danke schon mal für deine Hilfestellung zur Zeichenkodierung. Für mich bleibt aber immer noch das Problem das ich nicht weiß wie ich dem PhP Code sage das er eine Ä oder Ö oder ß anzeigen soll. Ich muss das irgendwie im Head definieren wenn ich das Richtig verstanden habe. Oder kann man das auch anders Lösen? Ich bin für jede Hilfe Dankbar.
Ausgegeben (STDOUT) wird immer die Bytesequenz. Also wenn Du echo 'äöüß' notierst und die Datei wo das drinsteht utf-8-kodiert ist, wird die Bytesequenz ausgegeben. Und wenn das der Brower kriegt, wäre das mit dem header Content-Type: text/html; charset=utf-8 bekanntzugeben. Letzteres machst Du jedoch nicht mit PHP sondern stellst das in der Serverkonfiguration (.htaccess) ein. GG
Tach!
Ausgegeben (STDOUT) wird immer die Bytesequenz.
PHP ist nicht Perl im CGI-Modus. STDOUT interessiert hier nicht. Vielleicht geht das darüber, vielleicht aber auch über einen anderen Weg. Es spielt jedenfalls keine Rolle. echo ... findet den Weg von selbst.
Und wenn das der Brower kriegt, wäre das mit dem header
Content-Type: text/html; charset=utf-8bekanntzugeben. Letzteres machst Du jedoch nicht mit PHP sondern stellst das in der Serverkonfiguration (.htaccess) ein.
Man kann das in der Serverkonfiguration einstellen, aber auch über PHPs header()-Funktion ausgeben. In der Serverkonfiguration hat das jedoch den Vorteil, dass es da generell angewendet wird und nicht je Ausgabe einzeln zu beachten ist.
dedlfix.
@@dedlfix
Und wenn das der Brower kriegt, wäre das mit dem header
Content-Type: text/html; charset=utf-8bekanntzugeben. Letzteres machst Du jedoch nicht mit PHP sondern stellst das in der Serverkonfiguration (.htaccess) ein.Man kann das in der Serverkonfiguration einstellen,
sollte das aber nicht tun müssen.
Wenn der Server nicht schon so vorkonfiguriert ist, sollte man vielleicht den Hoster wechseln.
LLAP 🖖
Man kann das in der Serverkonfiguration einstellen,
sollte das aber nicht tun müssen.
Schreib doch mal bitte über Deine Erfahrungen. Also warum sollte man das nicht tun müssen und wo bitte stellst Du Deine Kodierung ein?
Tach!
Man kann das in der Serverkonfiguration einstellen,
sollte das aber nicht tun müssen.
Wenn der Server nicht schon so vorkonfiguriert ist, sollte man vielleicht den Hoster wechseln.
Unsinn. Woher soll der Hoster wissen, was die Anwendungen des Kunden für Kodierungen verwenden? Das beste ist, wenn da keine Vorgaben gemacht sind. Dann kann der Kunde verwenden, was er möchte. Zudem besteht ohne eine Vorgabe für den Content-Type-HTTP-Header die Möglichkeit, eine Kodierungsangabe auch erst in den Dokumenten anzugeben (bei den Typen, bei denen es geht). Diesen Wert nicht fest vorzubelegen, erspart eine Menge Ärger und Supportanfragen. "Ich hab doch <meta charset=...> in meinem HTML-Dokuemnt stehen, wieso nimmt der Browser das nicht?"
Der Defaultwert Off für AddDefaultCharset sollte seitens des Hosters unangetastet bleiben.
dedlfix.
@@dedlfix
Unsinn. Woher soll der Hoster wissen, was die Anwendungen des Kunden für Kodierungen verwenden?
Der Hoster kann davon ausgehen, dass der Kunde UTF-8 verwenden will. Weil alles andere Unsinn ist. Wir haben 2019.
LLAP 🖖
Tach!
Unsinn. Woher soll der Hoster wissen, was die Anwendungen des Kunden für Kodierungen verwenden?
Der Hoster kann davon ausgehen, dass der Kunde UTF-8 verwenden will. Weil alles andere Unsinn ist. Wir haben 2019.
Das hat nichts damit zu tun, welche Kodierung sinnvoll ist oder nicht. Der Hoster ist jedenfalls kein Durchsetzungsorgan.
dedlfix.
@@dedlfix
Der Hoster kann davon ausgehen, dass der Kunde UTF-8 verwenden will. Weil alles andere Unsinn ist. Wir haben 2019.
Das hat nichts damit zu tun, welche Kodierung sinnvoll ist oder nicht.
Aber natürlich hat das damit zu tun. Der Hoster sollte sinnvolle Voreinstellungen wählen – für die Zeichencodierung wäre das UTF-8.
Der Hoster ist jedenfalls kein Durchsetzungsorgan.
Es geht auch nicht darum, Voreinstellungen nicht überschreibbar zu machen.
Und schon gar nicht geht es darum, Einstellungen von bestehenden Projekten zu ändern.
LLAP 🖖
Tach!
Es geht auch nicht darum, Voreinstellungen nicht überschreibbar zu machen.
Und schon gar nicht geht es darum, Einstellungen von bestehenden Projekten zu ändern.
Letzteres würdest du aber tun, wenn du eine solche Vorgabe machst, weil du damit die Vorgaben in den Dateien wirkungslos machst (beispielsweise meta charset in HTML). Es bringt keine Punkte, einen Wert voreinzustellen, von dem du nicht weißt, ob der Kunde auch diese Kodierung verwendet. Wir predigen immer, dass die Angabe und die tatsächlich verwendete Kodierung übereinstimmen muss. Das ist schließlich Voraussetzung, damit es zu keinen Fehlern beim Anzeigen kommt. Macht hier der Hoster eine Vorgabe, von der er nicht weiß, ob sie zutrifft, erzeugt er potentiell Probleme. Lässt er sie stattdessen weg, hat das am Ende auch keinen Nachteil. Schlimmstenfalls finden die Browser keinerlei Angabe und raten. Das Ergebnis dürfte immer noch besser sein, als eine falsche Angabe (zuzüglich wegfallende Fehlersuche und Supportaufwand).
dedlfix.
@@dedlfix
Und schon gar nicht geht es darum, Einstellungen von bestehenden Projekten zu ändern.
Letzteres würdest du aber tun, wenn du eine solche Vorgabe machst
Wie sollte man das tun, wenn man für neue Projekte UTF-8 als Grundeinstellung wählt?
LLAP 🖖
Tach!
Und schon gar nicht geht es darum, Einstellungen von bestehenden Projekten zu ändern.
Letzteres würdest du aber tun, wenn du eine solche Vorgabe machst
Wie sollte man das tun, wenn man für neue Projekte UTF-8 als Grundeinstellung wählt?
Woher soll der Hoster wissen, ob der Kunde das Hosting-Angebot für ein neues oder ein altes Projekt verwenden möchte? Aber ob neu oder alt ist überhaupt nicht das Kriterium, sondern ob die Vorgabe zur verwendeten Kodierung passt oder nicht. Auf das, was der Kunde verwendet hat, hat der Hoster mit einem gesetzten Default-Wert keinerlei Einfluss. Der kann aber Probleme schaffen, die durch das Weglassen nicht entstehen.
Erklär doch mal, was du für Vorteile darin siehst, eine Vorgabe zu machen, von der du nicht weißt, ob sie letztlich passt oder nicht. Und was für Nachteile siehst du, wenn der Hoster keine Voreinstellung konfiguriert?
dedlfix.
hi
Es geht auch nicht darum, Voreinstellungen nicht überschreibbar zu machen.
Wahrscheinlich hast Du noch nie mit der FileAPI gearbeitet. Denn da ist die Voreinstellung UTF-8 und das heißt z.B. daß anhängliche Dateinamen ungefragt zu UTF-8 konvertiert werden wenn sie in einer anderen Kodierung vorliegen.
Und diese Voreinstellung ist nicht veränderbar. Man muss es halt nur wissen. MFG
Tach!
Ausgegeben (STDOUT) wird immer die Bytesequenz.
PHP ist nicht Perl im CGI-Modus. STDOUT interessiert hier nicht.
Selbstverständlich interessiert das hier. PHP's echo und print geben Bytes auf STDOUT aber sowas von! Das war schon immmer so!
Vielleicht geht das darüber, vielleicht aber auch über einen anderen Weg. Es spielt jedenfalls keine Rolle.
echo ...findet den Weg von selbst.
Von selbst geht da überhaupt nichts!!!! GGA
Tach!
Ausgegeben (STDOUT) wird immer die Bytesequenz.
PHP ist nicht Perl im CGI-Modus. STDOUT interessiert hier nicht.
Selbstverständlich interessiert das hier. PHP's echo und print geben Bytes auf STDOUT aber sowas von! Das war schon immmer so!
Das ist zumindest falsch, wenn PHP als Modul im Apachen läuft. Falls man gezielt etwas in die Ausgabekanäle leiten möchte, muss man da den Wrapper php://output nehmen, weil php://stdout nicht im Outut Buffer landet, der für die Response verwendet wird, sondern zum stdout des Apachen geleitet wird, was dessen Console ist, oder verworfen wird, wenn der wie üblich im Hintergrund läuft.
Vielleicht geht das darüber, vielleicht aber auch über einen anderen Weg. Es spielt jedenfalls keine Rolle.
echo ...findet den Weg von selbst.Von selbst geht da überhaupt nichts!!!!
Natürlich nicht - rein technisch betrachtet. Aber der PHP-Verwender muss dafür nichts tun oder wissen, weil PHP das bereits situationsgerecht richtig weitergibt. Es bleibt dabei, stdout ist für den PHP-Verwender außer in wenigen Ausnahmen irrelevant (oder sogar falsch).
dedlfix.
I/O ist grundsätzlich byteorientiert! Denn die Kodierung spielt nur programmintern eine Rolle, etwa bei Stringoperationen. Wenn Texte jedoch nach draußen gehen (STDOUT, Dateien, Sockets..) ist die Kodierung immer abzuschalten.
Tach!
I/O ist grundsätzlich byteorientiert! Denn die Kodierung spielt nur programmintern eine Rolle, etwa bei Stringoperationen. Wenn Texte jedoch nach draußen gehen (STDOUT, Dateien, Sockets..) ist die Kodierung immer abzuschalten.
Wo besteht jetzt der Zusammenhang zum vorher gesagten? Außerdem ist das schon wieder Perl-spezifisch. PHP kennt kein Ausschalten der Kodierung.
Die Philosophie von PHP ist hier grundsätzlich eine andere. Es arbeitet nämlich bereits im Kern byteorientiert. Multibyte-Kodierungen werden nur partiell unterstützt. Auch dafür muss man nicht irgendwas ein- und ausschalten. Der Datentyp String bleibt weiterhin byteorientiert. Die richtige Behandlung der Kodierung ist Aufgabe der jeweiligen Funktionen. Außer dass man den Namen der Kodierung als Parameter übergibt, hat man als Anwender keinen weiteren Einfluss oder etwas explizit zu tun.
Die Byteorientierung war bereits seit Anfang an so und wird auch noch solange bleiben, bis PHP endlich Multibyteunterstützung vollständig eingebaut bekommt. Perl und die dortigen Mechanismen spielen (derzeit) jedenfalls keine Rolle für PHP.
dedlfix.
Hallo dedlfix,
bis PHP endlich Multibyteunterstützung vollständig eingebaut bekommt.
Meinst Du, das bekommen sie ohne breaking change hin? Entweder müssten sie die Standard-Stringfunktionen automatisch mb-fähig machen, oder von der internen byte-Orientierung auf UTF-16 wechseln, wie C# oder Java.
Rolf
Tach!
bis PHP endlich Multibyteunterstützung vollständig eingebaut bekommt.
Meinst Du, das bekommen sie ohne breaking change hin?
Ich habe keine Ahnung, wie sie das bewerkstelligen wollen oder werden. PHP läuft bei mir nur noch unter ferner liefen, so dass ich da keinen Einblick in die Planungen oder die Innereien nehme. Aber dass es ohne Breaking Change zu realisieren wäre, kann ich mir nicht vorstellen, sonst wär das schon längst erledigt. Geplant war das ja bereits vor langer Zeit für Version 6.
dedlfix.
Für I/O braucht man kein Multibyte-Unterstützung. Die Kodierung spielt nur programmintern eine Rolle wenn z.B. Stringoperationen anzuwenden sind. Bei Ein~ und Ausgabe jedoch ist die Kodierung grundsätzlich abzuschalten. Beim Übertragen Richtung Datenbanken übrigens auch, wenn das nicht beachtet wird, gibt es Zeichensalat.
Im Übrigen ist auch MySQL in Sachen UTf-8 noch nicht fertig. Da gibt es auch Probleme wenn Zeichen mit 4 und mehr Bytes kodiert zu Speichern sind. Aber auch diese Zeichen lassen sich problemlos speichen wenn die Kodierung ausgeschaltet wird. MFG
Tach!
Für I/O braucht man kein Multibyte-Unterstützung. Die Kodierung spielt nur programmintern eine Rolle wenn z.B. Stringoperationen anzuwenden sind. Bei Ein~ und Ausgabe jedoch ist die Kodierung grundsätzlich abzuschalten.
Thema ist PHP. Wie schaltet man da die Kodierung aus?
Beim Übertragen Richtung Datenbanken übrigens auch, wenn das nicht beachtet wird, gibt es Zeichensalat.
Unsinn. Da ist nichts auszuschalten, sondern mit dem DBMS konkret auszuhandeln, welche Kodierung zu verwenden ist. Das DBMS muss nicht nur Byte-Salat bekommen, sondern es muss die Bedeutung des Inhalts kennen, damit es Stringverarbeitung wie Vergleichen und Sortieren korrekt ausführen kann.
Im Übrigen ist auch MySQL in Sachen UTf-8 noch nicht fertig. Da gibt es auch Probleme wenn Zeichen mit 4 und mehr Bytes kodiert zu Speichern sind.
Unicode definiert Zeichen bis U+10FFFF, und das ist problemlos als UTF-8 mit 4 Byte darstellbar. MySQL kann zugegebenermaßen mit der Kodierungsangabe "utf8" nur 2-Byte-Zeichen verarbeiten, aber "utf8mb4" existiert ebenfalls für die volle Schönheit bis U+10FFFF.
Aber auch diese Zeichen lassen sich problemlos speichen wenn die Kodierung ausgeschaltet wird.
Dann sind es keine Zeichen mehr, sondern Byte-Salat. Natürlich gibt es beim einfachen Speichern keine Probleme. Nur Stringverarbeitung kann man dann nicht mehr im DBMS ausführen lassen.
dedlfix.
Die Verbindung von PHP nach MySQL ist ein Socket. Sockets verhalten sich ganz genauso wie Filehandles und das heißt auch, daß Sockets gar keine Kodierung kennen. Nur wissen das eben viele PHP Programmierer gar nicht. Genausowenig wie um die Tatsache, daß print und echo auf STDOUT ausgeben. Das ist alles I/O, Ein~ und Ausgabe und da gibt die Bytesemantic. Das war schon immer so und das wird auch immer so bleiben.
Was die Verbindung zu DB betrifft: Die Kodierung wird allenfalls mit übermittelt, ansonsten werden da einfach nur Bytes übertragen. Nimm einen Sniffer wie Wireshark und guck Dir das Payload an was in Richtung MySQL rausgeht bzw. zurückkommt. MFG
Tach!
Die Verbindung von PHP nach MySQL ist ein Socket.
Die Verbindung zwischen PHP und MySQL erfolgt über die MySQL-Client-Api, die Bestandteil von PHP ist. Welchen Weg die API-Funktionen nehmen, um letzlich mit dem Server zu kommunizieren, ist für PHP-Verwender nicht weiter relevant. Dass letztlich irgenwer irgendwelche Bytes übertragen muss, hat auch keinen Einfluss darauf, dass dem DBMS mitgeteilt werden muss, welche Kodierung diesem Bytestrom zugrundeliegt, damit es korrekt arbeiten kann.
Was die Verbindung zu DB betrifft: Die Kodierung wird allenfalls mit übermittelt, ansonsten werden da einfach nur Bytes übertragen. Nimm einen Sniffer wie Wireshark und guck Dir das Payload an was in Richtung MySQL rausgeht bzw. zurückkommt.
Richtig, aber mit der konkreten Übertragung hat der PHP-Verwender nichts am Hut. Man verwendet einfach die gegebenen mysqli-/PDO-Funktionen - und zwar mit Strings. Eine Empfehlung, in irgendeinen Byte-Modus zu wechseln, ist unangebracht, weil man sowas nicht tun muss. Es sei denn, man übernimmt selbst die Kommunikation auf Socket-Ebene und umgeht die eingebaute MySQL-Client-API. Aber wozu?
dedlfix.
Also ich hab mir das jetzt mal mit Wireshark angeschaut. Die API setzt das für die Übertragung um auf das MySQL Protocol was über den Port 3306 abgewickelt wird. Das legt fest in welchen Feldern die Kodierung zu übertragen ist, also die Kodierung welcher der Client beabsichtigt. Die Daten selbst jedoch werden unkodiert übertragen, also die Bytes, wie auch sonst.
Das ist im Prinzip auch nicht anders wie bei HTTP: Die Daten sind Bytes, die Kodierung ist im Header angegeben. Auf dem Socketlayer selbst gibt es keine Kodierung, in Dateien ja auch nicht.
Und selbstverständlich sollten sich auch PHP Programmierer mal mit solchen grundsätzlichen Dingen befassen!
Es sei denn, man übernimmt selbst die Kommunikation auf Socket-Ebene und umgeht die eingebaute MySQL-Client-API. Aber wozu?
Warum nicht!? Dabei kann man nur Lernen!!!
Tach!
Also ich hab mir das jetzt mal mit Wireshark angeschaut. Die API setzt das für die Übertragung um auf das
MySQL Protocolwas über den Port 3306 abgewickelt wird. Das legt fest in welchen Feldern die Kodierung zu übertragen ist, also die Kodierung welcher der Client beabsichtigt. Die Daten selbst jedoch werden unkodiert übertragen, also die Bytes, wie auch sonst.
Was verstehst du unter unkodiert? Zeichen liegen in der Physik immer als irgendwelche Bytes kodiert vor, gemäß ASCII, ISO-8859-1, UTF-8 … Was genau sollen unkodierte Daten sein?
dedlfix.
Lieber dedlfix,
Das DBMS muss nicht nur Byte-Salat bekommen, sondern es muss die Bedeutung des Inhalts kennen, damit es Stringverarbeitung wie Vergleichen und Sortieren korrekt ausführen kann.
also das mit dem Sortieren von Strings ist so eine Sache. Natürlich kann das DBMS anhand der Kodierung unterscheiden, welche Bytes welchen Character ergeben. Aber für das Sortieren nach Kriterien der deutschen Sprache, insbesondere was die Umlaute und ß angeht, muss man noch immer eigene Lösungen schreiben.
Liebe Grüße,
Felix Riesterer.
Tach!
Das DBMS muss nicht nur Byte-Salat bekommen, sondern es muss die Bedeutung des Inhalts kennen, damit es Stringverarbeitung wie Vergleichen und Sortieren korrekt ausführen kann.
also das mit dem Sortieren von Strings ist so eine Sache. Natürlich kann das DBMS anhand der Kodierung unterscheiden, welche Bytes welchen Character ergeben. Aber für das Sortieren nach Kriterien der deutschen Sprache, insbesondere was die Umlaute und ß angeht, muss man noch immer eigene Lösungen schreiben.
Grundvoraussetzung, damit Verarbeitung nach Zeichen stattfinden kann, ist die Kenntnis der Kodierung. Die Regeln zur Sortierung, was in welcher Reihenfolge kommt und welche Zeichen vielleicht gleichwertig sind, werden von der Collation festgelegt. Beides geht Hand in Hand, eine Collation ist immer an eine Zeichenkodierung gebunden.
Was die deutsche Sortierung angeht, die beide Varianten Wörterbuch und Telefonbuch werden unterstützt von den Collations …_unicode_ci beziehungsweise …_german2_ci.
dedlfix.
Abgeshen davon daß charset (utf8) und collation (utf8_general_ci) richtig eingestellt sein müssen, auch in PHP sollte ein SET NAMES UTF8 möglich sein damit MySQL-Stingfunktionen funktionieren.
Tach!
Abgeshen davon daß charset (utf8) und collation (utf8_general_ci) richtig eingestellt sein müssen,
Ja, und zwar bei den betroffenen Feldern. Das reicht aber schon, solange die Daten im DBMS korrekt eingetragen wurden.
auch in PHP sollte ein SET NAMES UTF8 möglich sein damit MySQL-Stingfunktionen funktionieren.
SET NAMES kann man als Statement losschicken. Aber zum einen beeinflusst das nicht die interne Arbeitsweise von MySQL, sondern dient lediglich dazu, die für den Transport von und zum Client zu verwendende Kodierung einzustellen.
Zum anderen ist es besser, die Zeichenkodierung über die vorhandene Funktion mysqli_set_charset() oder (objektorientiert mysqli::set_charset()) einzustellen. Damit weiß nun auch die Client-API, was für eine Kodierung genommen wird. Sendet man SET NAMES als Statement, wird das von der Client-API nur durchgereicht aber nicht von ihr in den Funktionen, die sie selbst ohne Serverbeteiligung ausführen kann, berücksichtigt.
Auch für PDO braucht man kein SET NAMES, da gibt man charset=... als Teil des DSN beim Erstellen des PDO-Objekts an.
dedlfix.
hi
Auch für PDO braucht man kein SET NAMES, da gibt man
charset=...als Teil des DSN beim Erstellen des PDO-Objekts an.
Hat bei mir NULL Effekt. PHPv 5.3.0
Mit Perl hingegen
Rolf B$dbh->do(q(insert into stings (sting) values(?)),{},"äöüß");
my $h = $dbh->selectrow_hashref("SELECT upper(sting) as sting FROM stings");
print $h->{sting}; # ÄÖÜß
funktioniert das einwandfrei. MFG
PS: array(PDO::MYSQL_ATTR_INIT_COMMAND => 'SET NAMES utf8')
kennt meine PHP Version noch nicht.
Tach!
Auch für PDO braucht man kein SET NAMES, da gibt man
charset=...als Teil des DSN beim Erstellen des PDO-Objekts an.Hat bei mir NULL Effekt. PHPv 5.3.0
Weil du eine 10 Jahre alte Museumsversion von PHP verwendest. Da gabs das noch nicht, wie die Dokumentation zum PDO_MYSQL DSN verrät.
dedlfix.
PS: array(PDO::MYSQL_ATTR_INIT_COMMAND => 'SET NAMES utf8')
kennt meine PHP Version noch nicht.
Was ja auch nicht weiter tragisch ist. In Perl ist die Unicodeunterstützung bis heute in Bewegung, so konnte man bis Version 5.8 auf Umlaute kein Stringfunktionen anwenden und nicht einmal dann wenn die in einer ISO-8859-1-Kodierung vorlagen. Erst mit Encode.pm wurde das möglich, was seit 5.8 auch zum Core gehört.
Trotzdem konnte man auch schon mit Perl v4 oder gar v3 seine Perl-Dateien in UTF-8-kodiert speichern und UTF-8 im Browser per print-Anweisung ausgeben. Und genau das, was man heute Bytesemantic nennt, gilt genauso auch für PHP, C und andere Programmiersprachen. MFG
Tach!
Für mich bleibt aber immer noch das Problem das ich nicht weiß wie ich dem PhP Code sage das er eine Ä oder Ö oder ß anzeigen soll.
Der PHP-Code zeigt gar nichts an. Aber wie bei allen anderen Zeichen auch, muss der Empfänger wissen, welche Bytes, die bei ihm ankommen, auf welche Weise zu interpretieren sind.
Ich muss das irgendwie im Head definieren wenn ich das Richtig verstanden habe.
Da es mehrere Arten der Kodierung gibt, musst du dem Empfänger mitteilen, welche Kodierung du verwendet hast. Und nicht nur das, du musst selbstverständlich diese Kodierung auch tatsächlich verwenden. "20€" auf einen Briefumschlag zu schreiben reicht ja auch nicht, wenn das Geld nicht drin liegt.
Du musst deinem Editor sagen, dass er die Code-Dateien als UTF-8 speichern soll. Dann kodiert der alle Zeichen, auch die Umlaute entsprechend. Wenn dein Code nun etwas ausgibt, das in ihm als Stringliteral vorliegt, und du dem Empfänger mitgeteilt hast, dass UTF-8 zu erwarten ist, dann sollte der kein Problem haben, die Bytes richtig zu interpretieren und die entsprechenden Zeichen daraus zu lesen. Möchtest du die String noch mit PHP bearbeiten, ist leider noch zu beachte, dass die einfachen Stringfunktionen nicht mit UTF-8 umgehen können. Aber die mb_*-Funktionen können das. Das macht die Sachlage auch nicht leichter.
Wenn du Texte an anderen Orten ablegen möchtest, beispielsweise Datenbank, dann musst du auch mit dieser aushandeln, dass UTF-8 auf der Verbindung zu verwenden sei. Zusätzlich muss meist noch konfiguriert sein, dass die Felder UTF-8 speichern sollen.
Und dieselbe Vorgehensweise muss man für jedes beteiligte System anwenden. Das System muss einerseits in der Lage sein, die Kodierung verarbeiten zu können, andererseits dem Kommunikationspartner mitteilen, welche Kodierung zu erwarten/verwenden sei. Das ist genauso komplex wie die Kommunikationsströme deiner Anwendung sind.
Oder kann man das auch anders Lösen?
Magie, aber die ist äußerst selten.
dedlfix.
Danke für diese Erklärung das bringt mich ein ganzes Stück weiter!
Liebe(r) bjbenderTV,
das ich nicht weiß wie ich dem PhP Code sage das er eine Ä oder Ö oder ß anzeigen soll.
echo "ÄÖß";
Wo ist das Problem?
Liebe Grüße,
Felix Riesterer.
@@Felix Riesterer
das ich nicht weiß wie ich dem PhP Code sage das er eine Ä oder Ö oder ß anzeigen soll.
echo "ÄÖß";Wo ist das Problem?
Außerhalb von PHP.
Es lässt sich aber mit PHP …
echo htmlentities("ÄÖß");
*duckundweg*
LLAP 🖖
PS: Nicht machen, Kinder. Wirklich nicht.
Und da wäre noch default_mimetype in php.ini zur gefälligen Beachtung. MFG
Tach!
Und da wäre noch default_mimetype in php.ini zur gefälligen Beachtung.
Was genau soll man da beachten? Der Default-Wert ist text/html. Falls man nicht andere Dokumenttypen durch PHP erzeugen lassen möchte, ist das doch genau der passende Wert, oder nicht?
Meintest du vielleicht die genau darunter stehende Direktive default_charset? Wenn ja, dann ist das einerm aber nicht der einzige der beachtenswerten Werte im komplexen Gebilde einer Webanwendung.
dedlfix.
Tach!
Und da wäre noch default_mimetype in php.ini zur gefälligen Beachtung.
Was genau soll man da beachten? Der Default-Wert ist
text/html.
Der Content-Type hat schon immer einen Parameter Charset. Und eben das alles zusammen stellt man in der php.ini ein. Beispiel: Content-Type: text/html; Charset=UTF-8
Bei meinem Provider z.B. kann man dies in einem dedizierten Backend einstellen. Was mich hier in diesem Thread mal wieder verwundert: Nicht einer hat auf die php.ini hingewiesen!
MFG
PS: Aber eigentlich wundert mich das nicht.
Tach!
Und da wäre noch default_mimetype in php.ini zur gefälligen Beachtung.
Was genau soll man da beachten? Der Default-Wert ist
text/html.Der Content-Type hat schon immer einen Parameter
Charset. Und eben das alles zusammen stellt man in der php.ini ein. Beispiel:Content-Type: text/html; Charset=UTF-8
Für die Charset-Angabe ist default_charset zuständig und nicht default_mimetype. Eine Charset-Angabe bei default_mimetype unterzubringen bewirkt, dass der Wert von default_charset ebenfalls angehängt wird, was zu einer fehlerhaften Headerzeile führt.
ini_set('default_mimetype', "text/html;charset=iso-8859-1");
ini_set('default_charset', "iso-8859-2");
Content-Type: text/html;charset=iso-8859-1; charset=iso-8859-2
Zudem hat, wie an der verlinkten Stelle nachzulesen ist, default_charset noch ein paar andere Auswirkungen auf die Arbeitsweise von PHP. Und diese möchte man haben, weil es nichts bringt, lediglich nach außen hin eine bestimmte Kodierung zu deklarieren, sie aber nicht auch im Inneren zu verwenden.
Was mich hier in diesem Thread mal wieder verwundert: Nicht einer hat auf die php.ini hingewiesen!
Ich habe auf die ausführliche Erörterung des Themas im Wiki hingewiesen. Da steht zwar nichts konkretes zu PHP, aber es steht zumindest geschrieben, wie das System insgesamt funktioniert. PHP einzustellen ist nur ein kleiner Teil vom ganzen.
PS: Aber eigentlich wundert mich das nicht.
Mich wundert es auch nicht, eine fachlich inkorrekte Antwort in deinem Posting zu finden.
dedlfix.
Genau! Man muss sich halt einfach mal richtig damit befassen!
; PHP's built-in default is text/html
; http://php.net/default-mimetype
default_mimetype = "text/html"
; PHP's default character set is set to empty.
; http://php.net/default-charset
default_charset = "UTF-8"
in php.ini wäre zu setzen, das gibt dann zusammen Content-Type: text/html; Charset=UTF-8 und phpinfo zeigt das auch!
@@pl
Was mich hier in diesem Thread mal wieder verwundert: Nicht einer hat auf die php.ini hingewiesen!
PS: Aber eigentlich wundert mich das nicht.
Na zum Glück haben wir ja dich und deine Fachkompetenz.
LLAP 🖖