Umlaute und Dateinamen
jobo
- webserver
Hallo,
wenn ich mittels PHPs glob("*.mp3") Dateinamen auslese, um sie dann dem EMFF-Player zu verfüttern
<param name="FlashVars" value="src=<?=$mp3File?>">
klappt das nicht, wenn ich im meta-Tag Charset auf UTF-8 setze.
Wieso kapier ich diesen Kodierungskrempel nicht???
Gruß
jobo
Hallo
wenn ich mittels PHPs glob("*.mp3") Dateinamen auslese, um sie dann dem EMFF-Player zu verfüttern
<param name="FlashVars" value="src=<?=$mp3File?>">
klappt das nicht, wenn ich im meta-Tag Charset auf UTF-8 setze.
1. Wie lautet der Dateiname der fraglichen mp3-Datei?
2. Was steht im Value-Attribut, wenn der Browser das in die Hand bekommt?
3. Welche Kodierung hat das Dokument tatsächlich (unabhängig davon, was im Metatag steht)?
Wieso kapier ich diesen Kodierungskrempel nicht???
Keine Ahnung.
Tschö, Auge
Hallo,
wenn ich mittels PHPs glob("*.mp3") Dateinamen auslese, um sie dann dem EMFF-Player zu verfüttern
<param name="FlashVars" value="src=<?=$mp3File?>">
klappt das nicht, wenn ich im meta-Tag Charset auf UTF-8 setze.
- Wie lautet der Dateiname der fraglichen mp3-Datei?
"Qualität hat ihren Preis.mp3"
- Was steht im Value-Attribut, wenn der Browser das in die Hand bekommt?
"Qualität hat ihren Preis.mp3", bei utf-Kodierung natürlich dann: Qualit�t ...
- Welche Kodierung hat das Dokument tatsächlich (unabhängig davon, was im Metatag steht)?
Tja, vielleicht ist das meine Wissenslücke. Ich hatte meinen Editor, als ich im Metatag noch "utf-8" stehen hatte auch umgestellt, weil sonst die per Hand editierten Umlaute ja falsch sind.
Wieso kapier ich diesen Kodierungskrempel nicht???
Keine Ahnung.
Ja, schön dass Du diese Einladung angenommen hast (;-). Ich dachte, es gäbe jemanden mit Glaskugel hier.
Gruß
jobo
Hallo,
"Qualität hat ihren Preis.mp3", bei utf-Kodierung natürlich dann: Qualit�t
Wäre dann <param name="FlashVars" value="src=<?=utf8_encode($mp3File)?>"> richtiger, also den per glob() ausgelesenen Wert erst noch utf8-encodieren?
Ich dachte, PHP kodiert standartmäßig utf8, oder richtet es sich dabei nach der (vermeintliche, ausgelesenen) Kodierung des Dokuments? Müsste ich dann header setzen? Oder woran sieht PHP, welche Kodierung das Script selbst hat bzw. die Datei "sonstewasEMFF.php".
Gruß
jobo
Hallo
"Qualität hat ihren Preis.mp3", bei utf-Kodierung natürlich dann: Qualit�t
Ahem, die Datei wird über HTTP angeboten. Das bedeutet, dass Dateinamen nur lateinische Buchstaben, Ziffern, _, - und . enthalten dürfen *oder*, wenn dann doch andere Zeichen, z.B. Umlaute oder Leerzeichen, verwandt werden, diese maskiert werden müssen. Das macht, z.B. in PHP, rawurlencode.
Damit ist aber dein Kodierungsproblem noch nicht gelöst.
Wäre dann <param name="FlashVars" value="src=<?=utf8_encode($mp3File)?>"> richtiger, also den per glob() ausgelesenen Wert erst noch utf8-encodieren?
Müsstest du dann nicht die Ausgangskodierung kennen?
Ich dachte, PHP kodiert standartmäßig utf8, oder richtet es sich dabei nach der (vermeintliche, ausgelesenen) Kodierung des Dokuments? Müsste ich dann header setzen? Oder woran sieht PHP, welche Kodierung das Script selbst hat bzw. die Datei "sonstewasEMFF.php".
Also: PHP arbeitet nicht standardmäßig mit UTF-8. Um das zu erreichen, muss das Skript im Editor mit der Kodierung UTF-8 erstellt werden, Der Server muss es mit UTF-8 ausliefern (das kann man im Zweifelsfall mit einem per PHP gesetzten Header erreichen) und es muss die Strings mit UTF-8 verarbeiten. Letzteres hat erstmal *nichts* mit der Kodierung des auszuliefernden Dokuments zu tun.
Da wir das Thema schon vor einigen Tagen hatten, lies bitte mein dortiges Posting *und* Sven Rautenbergs Korrektur meiner Ausführungen wegen der Prüfung, ob die Erweiterung überhaupt vorhanden ist.
Tschö, Auge
Hallo Auge,
Da wir das Thema schon vor einigen Tagen hatten, lies bitte mein dortiges Posting *und* Sven Rautenbergs Korrektur meiner Ausführungen wegen der Prüfung, ob die Erweiterung überhaupt vorhanden ist.
var_dump(mb_internal_encoding()); bringt iso-8859-1 auf meinem Rechner wie auch auf dem Server. Obwohl ich das Dokument im SciTE mit UTF-8-Kodierung bearbeite.
In Quelltext steht nun <param name="FlashVars" value="src=Qualit�t ...">.
Browser sucht nun also per http nach einer Resource namens "Qualit�t.mp3", die es aber nicht gibt.
<meta http-equiv="content-type" content="application/html; charset=UTF-8">
bringt den Browser zwar dazu, die Kodierung auf utf-8 zu setzen. Dann wird aber dennoch im Titel, den ich ja auch angebe,
"Qualit�t" angezeigt. Weil ja, vermutlich, vielleicht dämmerts jetzt (?), der Server das "ä" als iso-8859-1 ausspuckt. Der Browser zeigt es falsch an und frägt deshalb auch nach der falschen Resource, nämlich nach "Qualit�t.mp3", welche es ja nicht gibt. Das kann ich testen, indem ich die Kodierung per Hand umstelle. Dann findet er auch die Ressource!
Aber
header ('Content-type: text/html; charset=utf-8');
mb_internal_encoding("utf-8");
bringt mir zwar
var_dump(mb_internal_encoding());
"UTF-8",
aber der Browser zeigt mir in der UTF-8-Kodierung immer noch "Qualit�t", was ja wohl heißt, dass PHPs glob() die Dateinamen als iso-8859-1-kodiert angibt. Test dazu: utf8_encode($mp3File) eingebaut, und es wird "Qualität" angezeigt und die korrekt Ressource gefunden. Aber das ist ja hyperkandidelt.
Bleib ich bei iso-8859-1 und wundere mich, warum sich PHP nicht von der Kodierung des Texteditors, den Headern und der mb_internal_encoding() beim Auslesen mit glob() beeinflussen lässt. Oder doch ein Denkfehler bei mir?
Dank und Gruß
jobo
Hi!
var_dump(mb_internal_encoding()); bringt iso-8859-1 auf meinem Rechner wie auch auf dem Server. Obwohl ich das Dokument im SciTE mit UTF-8-Kodierung bearbeite.
Vergiss die Multibyte-String-Extension, was deren Aussagen zum Rest von PHP anbelangt. Sie ist nur ein Zusatz und alles was man mit ihr üblicherweise anstellt, hat keine direkten Beziehungen zu anderen Funktionen und Funktionalitäten von PHP, auch nicht in lesender Richtung. Eine Ausnahme bildet das Function Overloading Feature, das man aber normalerweise nicht in freier Wildbahn aktiviert findet. Und wie gesagt, PHP hat derzeit mit UTF-8 nichts weiter am Hut, als dass es ein paar wenige Funktionen liefert, die optional Zeichenkodierungen berücksichtigen (oder für explizite Konvertierungen gedacht sind). Da es keine generelle Unterstützung für UTF-8 mitbringt, stellt es sich auch nicht gemäß irgendwelcher Kodierungen um oder dergleichen. Zudem kann man aus einem Datenstrom keine Kodierung erkennen. Sie müsste dazu in Metadaten bekanntgegeben werden. Für Dateien gibt es keinen solchen Mechnismus, so dass lediglich ein Raten übrigbleibt, und das macht PHP nicht, weil ... kein UTF-8, wissenschon.
In Quelltext steht nun <param name="FlashVars" value="src=Qualit�t ...">.
Weil dir glob() und/oder das Betriebssystem einen ISO-8859-1- oder Windows-1252-kodierten Dateinamen geliefert hat.
<meta http-equiv="content-type" content="application/html; charset=UTF-8">
bringt den Browser zwar dazu, die Kodierung auf utf-8 zu setzen.
Falsch formuliert, deutet auf eine Wissenslücke hin. Richtig wäre: Das bringt den Browser dazu, das Dokument nach den Regeln von UTF-8 zu interpretieren. Und wenn da ein einzelnes Byte aus dem Bereich x80..xff zwischen ansonsten x00..x7F drin steht, wie es für ein ISO-8859-1-Umlaut der Fall ist, dann gibt das Ungültig-Zeichen �.
Weil ja, vermutlich, vielleicht dämmerts jetzt (?), der Server das "ä" als iso-8859-1 ausspuckt. Der Browser zeigt es falsch an und frägt deshalb auch nach der falschen Resource, nämlich nach "Qualit�t.mp3", welche es ja nicht gibt. Das kann ich testen, indem ich die Kodierung per Hand umstelle. Dann findet er auch die Ressource!
Exaktamente. Aber nicht der Browser findet, sondern der Webserver.
mb_internal_encoding("utf-8");
bringt mir zwar
var_dump(mb_internal_encoding());
"UTF-8",
Vergiss mb_internal_encoding() in dem Fall, das wirkt nur auf die mb_*-Funktionen.
Bleib ich bei iso-8859-1 und wundere mich, warum sich PHP nicht von der Kodierung des Texteditors, den Headern und der mb_internal_encoding() beim Auslesen mit glob() beeinflussen lässt. Oder doch ein Denkfehler bei mir?
PHP weiß nichts von der Kodierung, die dein Texteditor verwendet hat. Es benötigt nur ASCII für seine Schlüsselwörter. Der Rest von x80..xFF wird nicht ausgewertet sondern als einzelne Bytes angesehen. mb_internal_encoding() und glob() kennen sich nicht. Du kannst nichts beeinflussen, nur das beste aus der ISO-8859-1-Situation machen. (raw)urlencode() schon probiert?
Lo!
Hallo dedlfix,
Merci!
Weil dir glob() und/oder das Betriebssystem einen ISO-8859-1- oder Windows-1252-kodierten Dateinamen geliefert hat.
iso-8859-1 bei einem apache webserver, vermute ich mal.
Weil ja, vermutlich, vielleicht dämmerts jetzt (?), der Server das "ä" als iso-8859-1 ausspuckt. Der Browser zeigt es falsch an und frägt deshalb auch nach der falschen Resource, nämlich nach "Qualit�t.mp3", welche es ja nicht gibt. Das kann ich testen, indem ich die Kodierung per Hand umstelle. Dann findet er auch die Ressource!
Exaktamente. Aber nicht der Browser findet, sondern der Webserver.
Bzw. eben nicht, wen der Browser die Ressource falsch bezeichnet (bzw. der PHP-Coder nicht mit (raw)urlencode probiert hat.
PHP weiß nichts von der Kodierung, die dein Texteditor verwendet hat. Es benötigt nur ASCII für seine Schlüsselwörter. Der Rest von x80..xFF wird nicht ausgewertet sondern als einzelne Bytes angesehen. mb_internal_encoding() und glob() kennen sich nicht. Du kannst nichts beeinflussen, nur das beste aus der ISO-8859-1-Situation machen. (raw)urlencode() schon probiert?
Ich dachte irgendwie, utf-8 wäre die Musik der Zukunft und auch PHPs und Webservers Basis. Ich hab garnix gegen iso-8859-1. Mein FF schafft es dann auch ohne urlencode, aber das sollte ich wohl doch lieber verwenden, damit auch andere Browser die richtige Url (in dem Fall ein mp3-File via EMFF-Player) erwischen, oder? Wie gut das es nur ein interne Seite (also für einen kleinen Userkreis von ein paar Leuten) gedacht ist.
Dank nochmal an alle, Gruß
jobo
Hi!
Ich dachte irgendwie, utf-8 wäre die Musik der Zukunft und auch PHPs und Webservers Basis.
Erst ab PHP 6, und dann macht PHP nicht nur mit UTF-8 halbe Sachen sondern will generell Mehrbytekodierungen unterstützen, also beispielsweise auch UTF-16, und asiatische "proprietäre" Kodierungen. So zumindest mein (schon recht alter) Wissensstand.
Lo!
Hallo,
Ich dachte irgendwie, utf-8 wäre die Musik der Zukunft und auch PHPs und Webservers Basis.
Erst ab PHP 6, und dann macht PHP nicht nur mit UTF-8 halbe Sachen sondern will generell Mehrbytekodierungen unterstützen, also beispielsweise auch UTF-16, und asiatische "proprietäre" Kodierungen. So zumindest mein (schon recht alter) Wissensstand.
aber glob() wird nach wie vor vom Server Umlaute in iso-8859-1 präsentiert bekommen, oder?
Gruß
jobo
Moin!
aber glob() wird nach wie vor vom Server Umlaute in iso-8859-1 präsentiert bekommen, oder?
Nein. Die Zeichencodierung des Dateisystems ist nochmal eine ganz andere Geschichte. glob() liefert dir per Definition "irgendwas".
Und weil das so ist, will man keine Umlaute und Sonderzeichen in Dateinamen haben. Auch keine Leerzeichen. Je mehr ASCII ein Dateiname ist, desto egaler ist die Zeichencodierung des Dateisystems.
Allerdings ist abzusehen, dass diese unschöne Lücke sich auch irgendwann schließen wird.
- Sven Rautenberg
Hallo,
aber glob() wird nach wie vor vom Server Umlaute in iso-8859-1 präsentiert bekommen, oder?
Nein. Die Zeichencodierung des Dateisystems ist nochmal eine ganz andere Geschichte. glob() liefert dir per Definition "irgendwas".
(;-). encoding="irgendwas"?
Gruß
jobo
Moin!
Hallo,
aber glob() wird nach wie vor vom Server Umlaute in iso-8859-1 präsentiert bekommen, oder?
Nein. Die Zeichencodierung des Dateisystems ist nochmal eine ganz andere Geschichte. glob() liefert dir per Definition "irgendwas".
(;-). encoding="irgendwas"?
So ungefähr. Es hängt sowohl von Betriebssystem als Ganzem (Windows, Mac OS, Linux&Co.) als unter Umständen auch von dessen konkreten Einstellungen (vor allem Linux) ab, welches Encoding das Dateisystem verwendet.
Und wie dedlfix ausgeführt hat, ist auch dort UTF-8 nicht gleich UTF-8, denn für Umlaute kann man nicht nur den Umlaut als eigenständiges Zeichen, sondern auch die Kombination "Grundbuchstabe + Tüttelchen" codieren, was Mac OS offenbar tut.
Unter dem Strich: Du wirst mit einigermaßener Wahrscheinlichkeit aus dem Dateisystem das als Dateiname mit PHP herausbekommen, was du MIT PHP auch hineingetan hast - auf demselben System. Umlaute sind also nicht komplett böse und unmöglich. Aber (!!!): Bastelst du aber mit irgendwelchen anderen Mitteln an den Dateinamen herum, wird das wahrscheinlich eher scheitern als klappen.
- Sven Rautenberg
Hallo,
Unter dem Strich: Du wirst mit einigermaßener Wahrscheinlichkeit aus dem Dateisystem das als Dateiname mit PHP herausbekommen, was du MIT PHP auch hineingetan hast - auf demselben System. Umlaute sind also nicht komplett böse und unmöglich. Aber (!!!): Bastelst du aber mit irgendwelchen anderen Mitteln an den Dateinamen herum, wird das wahrscheinlich eher scheitern als klappen.
Danke. Heißt aber auch: wenn ich mit PHPs glob()-Funktion Dateinamen auslese, kann ich den String (bestenfalls urlencoded) nehmen, um dieses als Ressource (zB. src für einen EMFF-Player) zu definieren. Denn ich frage ja dann nach dem, was ich vorher las. Würd ich jetzt für Fremdkunden und größere Seiten wohl eher nicht machen, aber im Prinzip müsste es "funzen" (;-).
Gruß
jobo
Hi!
Und weil das so ist, will man keine Umlaute und Sonderzeichen in Dateinamen haben. Auch keine Leerzeichen. Je mehr ASCII ein Dateiname ist, desto egaler ist die Zeichencodierung des Dateisystems.
Allerdings ist abzusehen, dass diese unschöne Lücke sich auch irgendwann schließen wird.
Ja, dann bekommt man unter Windows "echte Umlaute" (sprich: ein einzelnes Unicode-Zeichen), und unter MacOSX - wie auch heute schon - zusammengesetzte, also lateinischer Buchstaben und kombinierende Diakritika als zwei Zeichen. Man darf sich dann als Ersatz mit Normalisierung rumärgern.
Lo!
Hi!
"Qualität hat ihren Preis.mp3", bei utf-Kodierung natürlich dann: Qualit�t
"Als UTF-8 interpretierte ISO-8859-1-Kodierung" wäre treffender.
Ich dachte, PHP kodiert standartmäßig utf8, oder richtet es sich dabei nach der (vermeintliche, ausgelesenen) Kodierung des Dokuments? Müsste ich dann header setzen? Oder woran sieht PHP, welche Kodierung das Script selbst hat bzw. die Datei "sonstewasEMFF.php".
PHP hat von UTF-8 so gut wie keine Ahnung. Es ist hier nur Durchreicher, wenn du nichts weiter machst. Ansonsten: http://wiki.selfhtml.org/wiki/Themen:Zeichencodierung/Webserver. Der Webserver muss den Namen in irgendeiner Form bekommen, die er auf das Dateisystem mappen kann. Günstig ist es, wenn du da nicht den Browser umkodieren lässt sondern gleich selbst url-kodierte Werte nimmst. Ob du zwischen glob() und urlencode() noch ein utf8_encode() benötigst, musst du probieren - vermutlich nicht.
Lo!
Hallo,
Ob du zwischen glob() und urlencode() noch ein utf8_encode() benötigst, musst du probieren - vermutlich nicht.
Aber für den Anzeigenamen der Datei. Bleib ich doch bei iso-8859-1.
Gruß
jobo
@@jobo:
nuqneH
Wäre dann <param name="FlashVars" value="src=<?=utf8_encode($mp3File)?>"> richtiger, also den per glob() ausgelesenen Wert erst noch utf8-encodieren?
Serverseitiger Code ist hier erstmal irrelevant. Wie sieht das generierte HTML aus?
Qapla'
Hallo Gunnar,
Serverseitiger Code ist hier erstmal irrelevant. Wie sieht das generierte HTML aus?
Ich konstatiere, dass PHP trotz header und mb_internal_encoding auf utf-8 mit glob() die Dateinamen in iso-8859-1 "ausliest" oder "speichert" oder "wiedergibt".
Gruß
jobo
Hi!
Ich konstatiere, dass PHP trotz header und mb_internal_encoding auf utf-8 mit glob() die Dateinamen in iso-8859-1 "ausliest" oder "speichert" oder "wiedergibt".
Mit header() erzeugst du HTTP-Reader für die Response. Was in den Headern drin steht wird von PHP nicht interpretiert (Ausnahme: Location-Header). Und zum Rest hab ich ja schon was gesagt.
Lo!