nicht angemeldet
Gunnar Bittersmann
molily
Gunnar Bittersmann
Gunnar Bittersmann
dedlfix
molily
dedlfix
Hallo Leute,
hätte gerne mal eure Hilfe.
Wie wird eine txt-Datei so includet, dass die Formatierung (Umbrüche und Tabs und so) erhalten bleibt und Sonderzeichen, die roh vorliegen, als dezimal (etwa ö als ö) ausgegeben werden?
Besten Dank im Voraus!
Steve
@@Steve:
nuqneH
Wie wird eine txt-Datei so includet, dass die Formatierung (Umbrüche und Tabs und so) erhalten bleibt
Was hast du vor?
und Sonderzeichen, die roh vorliegen, als dezimal (etwa ö als ö) ausgegeben werden?
Das sollte man möglichst vermeiden. Stattdessen immer und überall UTF-8 als Zeichencodierung verwenden und die richtigen Zeichen, keine Escapes im Quelltext schreiben.
Und wenn man schon numerische Zeichenreferenzen verwendet, dann besser hexadezimale. Das erspart lästige Umrechnerei, denn Unicode-Codepoints werden hexadezimal angegeben.
BTW, ö ist _kein_ Sonderzeichen.
Qapla'
Was hast du vor?
Es gibt eine txt-Datei, die öfter mal geändert wird. Diese soll dann includet werden, also automatisch/dynamisch, in HTML.
Das sollte man möglichst vermeiden.
Oh, OK
Stattdessen immer und überall UTF-8 als Zeichencodierung verwenden und die richtigen Zeichen, keine Escapes im Quelltext schreiben.
Also rohe Zeichen sind schon "legitim"? Firefox gibt jedenfalls ö usw. als das komische Karo aus. Ich arbeite bisher nur clientseitig - hab UTF-8 bisher nur im HTML mit <meta charset="UTF-8" /> gesetzt ... Also wenn UTF-8 auch serverseitig gesetzt ist (ist es dann clientseitig übrehaupt noch nötig?), sollten rohe Zeichen - in welchen Dateien auch immer - kein Problem sein?
Also rohe Zeichen sind schon "legitim"? Firefox gibt jedenfalls ö usw. als das komische Karo aus.
Vermutlich(!) schreibst Du (oder wer auch immer) in Deine Textdatei in der antiken Kodierung ISO-8859-15 oder der ebenfalls antiken Microsoft-Verirrung Windows-1252 (die sich weitgehend entsprechen). Dann bekommt der Browser natürlich diese Daten auch in dieser Kodierung.
Da er aber die Information "ist UTF-8" hat zeigt er eben die Zeichen, die in UTF-8 z.B. an der Stelle Deines vermeintlichen 'ü' sind. Lösungen sind, wie ich oben schrieb, iconv oder mb_convert_encoding (das vor allem für den Rückweg: da UTF-8 Zeichen kennt, die in ISO-8859-15 unter Umständen gar nicht vorhanden sein können).
Jörg Reinholz
Hallo,
Also rohe Zeichen sind schon "legitim"?
Natürlich. Die Entity- bzw. Zeichenreferenzen ö, ö und ö wurden ja nur erfunden, um Unicode-Zeichen in einer Kodierung darzustellen, die dieses Zeichen nicht direkt kodieren kann. Zum Beispiel enthält US-ASCII kein ö. Es gibt aber dutzende andere praktisch verwendbare Kodierungen, die diese Zeichen kodieren können, z.B. ISO-8859-1 oder UTF-8. Wenn man diese verwendet, braucht man ö und Co. nicht.
Firefox gibt jedenfalls ö usw. als das komische Karo aus. Ich arbeite bisher nur clientseitig - hab UTF-8 bisher nur im HTML mit
<meta charset="UTF-8" />gesetzt ... Also wenn UTF-8 auch serverseitig gesetzt ist (ist es dann clientseitig übrehaupt noch nötig?), sollten rohe Zeichen - in welchen Dateien auch immer - kein Problem sein?
Du musst zwei Sachen unterscheiden:
Eine Datei hat immer eine bestimmte Kodierung. Bei einer Textdatei ist i.d.R. der Texteditor beim Speichern dafür verantwortlich; prüfe also einmal dessen Einstellungen.
Ein verarbeitendes Programm wie der Browser muss die korrekte Kodierung kennen. Wenn du alle beteiligten Dateien als UTF-8 speicherst, kannst du sie einfach zusammenmantschen und z.B. mit PHP ein HTML-Dokument daraus generieren. Du musst dann aber immer noch im HTML die Kodierung mit <meta charset="utf-8"> angeben, damit der Browser sie korrekt erkennt.
Beim Einlesen und Verarbeiten könnten dir folgende Funktionen weiterhelfen:
http://de3.php.net/file_get_contents – Liest den Dateiinhalt in einen String ein
http://de3.php.net/htmlspecialchars – Macht Zeichen unschädlich, die in HTML eine Bedeutung haben
http://de3.php.net/nl2br – Fügt br-Elemente bei Zeilenumbrüchen ein. Besser wären p-Elemente, dazu muss man Reguläre Ausdrücke kennen. Dasselbe gilt Zeilen mit Tabulator-Einrückungen.
Mathias
Hi,
[...] und z.B. mit PHP ein HTML-Dokument daraus generieren. Du musst dann aber immer noch im HTML die Kodierung mit <meta charset="utf-8"> angeben, damit der Browser sie korrekt erkennt.
nein, muss er nicht. Wenn sichergestellt ist, dass bereits der Server (oder das PHP-Script) die richtige Zeichencodierung im HTTP-Header übermittelt, ist eine zusätzliche Angabe im Dokument selbst unnötig und wird ignoriert, wenn sie vorhanden ist.
Die kommt nur dann zum Tragen, wenn eben keine Information im HTTP-Header übertragen wird - etwa weil das Dokument mit einem anderen Protokoll übertragen wird oder als Datei gespeichert ist. Das ist aber unwahrscheinlich, sobald PHP im Spiel ist.
So long,
Martin
Ein Posting ist ein Redebeitrag und zitieren außerhalb des Kontextes verdreht Aussagen.
Hier habe ich auf die Steves Frage geantwortet, ob es nötig ist, die Kodierung clientseitig zu setzen.
Praktische Antwort: Ja. Kein HTML-Dokument ohne <meta charset="utf-8">. Am besten genau so und genau diese Kodierung.
Spitzfindige Antwort: Nicht zwingend, wenn die Kodierung durch das darüberliegende Protokoll übermittelt wurde. Allerdings: Da das darüberliegende Protokoll sich ändern kann und ggf. nicht unter Kontrolle des Dokumentautors steht, ist eine Kodierungsangabe in HTML immer ratsam. Quintessenz: siehe praktische Antwort.
Mathias
@@Der Martin:
nuqneH
ist eine zusätzliche Angabe im Dokument selbst unnötig
Ist sie nicht.
Die kommt nur dann zum Tragen, wenn eben keine Information im HTTP-Header übertragen wird - etwa weil das Dokument mit einem anderen Protokoll übertragen wird oder als Datei gespeichert ist.
Eben.
Das ist aber unwahrscheinlich, sobald PHP im Spiel ist.
Warum sollte ein Nutzer nicht eine ursprünglich mit PHP generierte HTML-Seite lokal speichern? Dass da irgendwann mal PHP im Spiel gewesen war, ist längst unter einer dicken Staubschicht vergraben.
Qapla'
@@Gunnar Bittersmann:
nuqneH
ist eine zusätzliche Angabe im Dokument selbst unnötig
Ist sie nicht.
Und selbst wenn sie es wäre: „Bei Verwendung von UTF-8 braucht man eigentlich keine explizite Angabe, es ist aber dennoch besser, eine zu machen, denn dann kann man die Zeichencodierung im Quelltext visuell erkennen.“ [qa-html-encoding-declarations]
Qapla'
@@molily:
nuqneH
Es gibt aber dutzende andere praktisch verwendbare Kodierungen, die diese Zeichen kodieren können, z.B. ISO-8859-1 oder UTF-8.
ISO 8859-x heutzutage noch „praktisch verwendbar“ zu nennen, halte ich für mehr als gewagt.
Die Codierungen dieser Familie sind den Anforderungen nicht gewachsen und sollten nicht mehr verwendet werden.
Wann immer der Zeichensatz Unicode ist (was bei HTML-Dokumenten immer der Fall ist), sollte eine Unicode-Codierung verwendet werden. Aus gewissen Gründen also keine andere Codierung als UTF-8.
Qapla'
Schau dir noch einmal an, was ich geschrieben habe.
Die Entity- bzw. Zeichenreferenzen ö, ö und ö wurden ja nur erfunden, um Unicode-Zeichen in einer Kodierung darzustellen, die dieses Zeichen nicht direkt kodieren kann. Zum Beispiel enthält US-ASCII kein ö. Es gibt aber dutzende andere praktisch verwendbare Kodierungen, die diese Zeichen kodieren können, z.B. ISO-8859-1 oder UTF-8. Wenn man diese verwendet, braucht man ö und Co. nicht.
ISO-8859-1 und UTF-8 sind *Beispiele* für *praktisch verwendbare* Kodierungen, um ö direkt zu kodieren.
»Praktisch verwendbar« bedeutet hier, dass die relevanten Protokolle und die relevante Software diese Kodierungen unterstützen. Beispielsweise kann man im Editor diese Kodierung verwenden, man kann sie in PHP verarbeiten, man kann sie den Browsern schicken.
Ich sehe nicht, was an dieser Aussage gewagt ist.
Es ist korrekt, dass ISO-8859-1 äußerst beschränkt ist und ich stimme der Empfehlung zu, UTF-8 zu verwenden. Ich habe in meinem Beitrag nichts Gegenteiliges gesagt.
Ich habe die Kodierungen genannt, weil es zum Verständnis der Thematik wichtig ist, den Unterschied zwischen US-ASCII, ISO-8859-Kodierungen und UTF-8 zu kennen.
Mathias
@@molily:
nuqneH
ISO-8859-1 und UTF-8 sind *Beispiele* für *praktisch verwendbare* Kodierungen, um ö direkt zu kodieren.
Ein ö macht noch keinen Text. In Texten kommen üblicherweise Zeichen vor, die sich mit ISO 8859-1 nicht codieren lassen: Anführungzeichen („“), Apostrophe (’), Gedankenstriche (–), Eurozeichen (€), … (da war noch so eins). Das schränkt die praktische Verwendbarkeit von ISO 8859-1 doch arg ein.
Qapla'
Ich verstehe deine Definition von »praktische Verwendbarkeit«, und in diesem Sinne halte ich ISO-8859-1 ebenfalls nicht für praktisch verwendbar.
Ich habe in meiner Ursprungsaussage lediglich eine andere Definition verwendet, weil ich es im Hinblick auf die Gesamtaussage für angemessen halte.
Mathias
Tach!
Ein ö macht noch keinen Text. In Texten kommen üblicherweise Zeichen vor, die sich mit ISO 8859-1 nicht codieren lassen: Anführungzeichen („“), Apostrophe (’), Gedankenstriche (–), Eurozeichen (€), … (da war noch so eins). Das schränkt die praktische Verwendbarkeit von ISO 8859-1 doch arg ein.
Dann nimm doch Windows-1252, da hast du alle genannten drin … ;-)
dedlfix.
@@Steve:
nuqneH
Also rohe Zeichen sind schon "legitim"?
Ja.
Firefox gibt jedenfalls ö usw. als das komische Karo aus.
Dann stimmt die angegebene Zeichencodierung mit der tatsächlich beim Abspeichern verwendeten nicht überein. Du musst dein HTML- bzw. PHP-Dokument in UTF-8 speichern, möglichst ohne BOM. Das musst du beim Speichern (bzw. vorher in den Einstellungen) in deinem Editor angeben.
Also wenn UTF-8 auch serverseitig gesetzt ist (ist es dann clientseitig übrehaupt noch nötig?)
Besser ist, wenn die Datei mal lokal übers Dateisystem und nicht über einen Webserver aufgerufen wird.
sollten rohe Zeichen - in welchen Dateien auch immer - kein Problem sein?
Nein.
Sonderzeichen müssen natürlich escapet werden. Was ein Sonderzeichen ist, hängt vom Kontext ab. In HTML sind < und & Sonderzeichen (erstes leitet ein Tag ein, zweites eine Zeichenreferenz). Besonders das Escapen von & in URIs wie http://example.net/?foo=bar&baz=quz wird oft vergessen; in HTML muss aber bspw. <a href="http://example.net/?foo=bar&baz=quz"> stehen.
In in " eingeschlossenen Attributwerten ist " ein Sonderzeichen; in in ' eingeschlossenen Attributwerten ist ' ein Sonderzeichen.
Qapla'
Du musst dein HTML- bzw. PHP-Dokument in UTF-8 speichern, möglichst ohne BOM. Das musst du beim Speichern (bzw. vorher in den Einstellungen) in deinem Editor angeben.
Hmmm
Hatte immer mal Probleme mit solchen (in UTF-8 gespeicherten) Dateien. Speichere lieber "normal"/"universalkompatibel" in ANSI. Tendiere eigentlich zu Jörgs On-the-Fly-Lösung. Ist doch auch eine "saubere" Lösung, oder?
Sonderzeichen müssen natürlich escapet werden.
Es ist auch HTML-Code in der txt-Datei, also der soll auch so übernommen werden.
@@Steve:
nuqneH
Hatte immer mal Probleme mit solchen (in UTF-8 gespeicherten) Dateien. Speichere lieber "normal"/"universalkompatibel" in ANSI.
UTF-8 ist normal/universalkompatibel (ohne Anführungszeichen).
Wenn du mal in den Kalender schaust … Wir haben 2014. Nicht 1994.
Qapla'
UTF-8 ist normal/universalkompatibel (ohne Anführungszeichen).
OK ...
Angenommen, ich speicher in UTF-8 (setzt der Editor ein BOM?):
Der Server hat sicherlich keine Probleme ...
Was aber passiert, wenn die Seite gespeichert wird? Wird die Original-Datei in ihrer Codierung immer so übernommen? Meine nicht (berichtigt mich, wenn doch) und ein Laie weiß gar nicht, was UTF-8 ist, wird also nicht manuell switchen (was für das Speichern unter htm ja eh nicht geht)?
Tach!
UTF-8 ist normal/universalkompatibel (ohne Anführungszeichen).
OK ...
Angenommen, ich speicher in UTF-8 (setzt der Editor ein BOM?):
Das musst du deinen Editor befragen. Manche setzen eine, wie der MS-Notepad, manchne bieten ein Speichern mit und ohne an.
Der Server hat sicherlich keine Probleme ...
Es kann Probleme geben. Die BOM ist ein Zeichen (zumindest aber 3 Bytes bei UTF-8), die vor einem öffnenden <?php stehen und damit die Ausgabe starten. Auch beim Einfügen in andere Dokumente ist dieses Zeichen zu berücksichtigen, denn dann muss es raus, weil es irgendwo in der Mitte keinen Sinn mehr ergibt.
Was aber passiert, wenn die Seite gespeichert wird? Wird die Original-Datei in ihrer Codierung immer so übernommen?
Es gibt kein "Original". Jeglicher Text muss in irgendeiner Form der Kodierung auf Bytes abgebildet werden. Man kann zwischen den Kodierungen beliebig hin und her konvertieren (solange sie alle die im Text enthaltenen Zeichen kodieren können) und der Text bleibt so "original" wie er ist.
Meine nicht (berichtigt mich, wenn doch) und ein Laie weiß gar nicht, was UTF-8 ist, wird also nicht manuell switchen (was für das Speichern unter htm ja eh nicht geht)?
Ob der Laie oder der Fachmann beim Speichern Mist macht, spielt keine Rolle. Es gibt keinen "Mach-dass-es-richtig-wird"-Algorithmus. Es gibt leider auch kein Kennzeichen für Dateien, dass den verarbeitenden Programmen sagen könnte, diese oder jene Kodierung solle doch beim Speichern genommen werden. Bei Textdateien gibt es auch keine Kennzeichnung, welche Kodierung vorliegt. Es gibt nur diverse Indizien, aus denen man die Kodierung erraten kann. Eine BOM wäre ein Indiz (was aber wie oben erwähnt auch problematisch sein kann). Dass UTF-8-Sequenzen drin vorkommen, wäre ein weiteres Indiz. Allerdings sind diese Sequenzen nicht eineindeutig. Die Bytes können rein theoretisch auch in anderen Kodierungen in derselben Reihenfolge auftreten und dort eine andere Bedeutung haben. Bei 1-Byte-Kodierungen der ISO-8859-Familie ist es ohne Kenntnis der Sprache des Textes und einer statistischen Wahrscheinlichkeit oder der menschlichen Intelligenz nicht wirklich möglich, die verwendete Kodierung zu erraten. Einige Texteditoren können anhand der Indizien die Zeichenkodierung nur mehr oder weniger gut erraten. Sind gültige UTF-8-Sequenzen drin, wird es wohl UTF-8 sein. Wenn nicht, wird es wohl eine ISO-8859-x oder eine Windows-xxxx sein, die das Betriebssystem als Voreinstellung hat. Irrtümer nicht ausgeschlossen.
Es gibt jedenfalls für Textdateien derzeit (und in Zukunft wohl auch nicht) keine andere sichere Lösung, als sich um die korrekte Kodierung beim Lesen und Speichern selbst zu kümmern.
dedlfix.
@@dedlfix:
nuqneH
Das musst du deinen Editor befragen. Manche setzen eine, wie der MS-Notepad
Verdient der die Bezeichnung „Editor“? SCNR.
Es gibt jedenfalls für Textdateien derzeit (und in Zukunft wohl auch nicht) keine andere sichere Lösung, als sich um die korrekte Kodierung beim Lesen und Speichern selbst zu kümmern.
In Zukunft wird vielleicht das Wissen darüber verlorengehen, dass es jemals eine andere Zeichencodierung als UTF-8 gegeben hat.
Qapla'
In Zukunft wird vielleicht das Wissen darüber verlorengehen, dass es jemals eine andere Zeichencodierung als UTF-8 gegeben hat.
Lieber Gott, bitte lass' *diese* Zukunft sofort beginnen!
SCNR
bye
MH
Hallo!
Hatte immer mal Probleme mit solchen (in UTF-8 gespeicherten) Dateien. Speichere lieber "normal"/"universalkompatibel" in ANSI.
Technisch gesehen ist es egal, welche Kodierung du wählst, solange am Ende alle Daten in derselben Kodierung (oder kompatiblen Kodierungen) zusammenkommen.
Praktisch gesehen ist es ratsam, *überall* UTF-8 zu verwenden, weil du damit alle üblichen Zeichen kodieren kannst, ohne HTML-Zeichenreferenzen benutzen zu müssen, und weil du Daten dann ohne Transkodierung (Umwandlung) zusammenführen kannst. Wie Gunnar auch sagt: UTF-8 ist universalkompatibel und mittlerweile die »normale« Kodierung.
Tendiere eigentlich zu Jörgs On-the-Fly-Lösung. Ist doch auch eine "saubere" Lösung, oder?
Jörgs Beispiel wandelt die Kodierung ISO-8859-15 in UTF-8 um. Falls deine Textdatei anders kodiert ist als der HTML-Code, den dein PHP-Script ausgibt, ist das ein möglicher Weg. Du müsstest hier natürlich die passenden Kodierungen angeben.
Ein besserer Weg wäre, die beteiligten Dateien *einmalig* im Editor in der gewünschten Kodierung zu speichern, sodass alle dieselbe Kodierung verwenden. Dann kannst du dir das ständige Umwandeln der Kodierung in PHP sparen.
Mathias
Tach!
Wie wird eine txt-Datei so includet,
In welche Umgebung? Was soll das Resultat sein?
dass die Formatierung (Umbrüche und Tabs und so) erhalten bleibt und Sonderzeichen, die roh vorliegen, als dezimal (etwa ö als ö) ausgegeben werden?
"Roh" ist kein Name einer mir bekannten Zeichenkodierung. Welche Zeichenkodierung liegt denn vor, und warum willst du daraus NCRs machen und sie nicht in die Kodierung des Zieldokuments bringen? Das Resultat soll also anscheinend HTML sein, und nicht PHP. Das gibt es ein Element für präformatierten Code (pre) und auch mit CSS lassen sich Whitespaces beeinflussen (white-space).
dedlfix.
Wie wird eine txt-Datei so includet, dass die Formatierung (Umbrüche und Tabs und so) erhalten bleibt und Sonderzeichen, die roh vorliegen, als dezimal (etwa ö als ö) ausgegeben werden?
Besten Dank im Voraus!
Steve
Dedlfix und Gunnar haben Dir erklärt, warum sowas nicht gut ist. Besser ist, Du änderst die Kodierung. On the fly geht das wie mit iconv folgt:
$s=[link:http://de3.php.net/manual/de/function.iconv.php@title=iconv]("ISO-8859-15", "UTF-8", file_get_contents('deine_textdatei.txt'));
Alternativ:
$s=[link:http://de3.php.net/manual/de/function.mb-convert-encoding.php@title=mb_convert_encoding](file_get_contents('deine_textdatei.txt'), "UTF-8", "ISO-8859-15");
Beachte, die umgedrehte Reihenfolge der Argumente.
Natürlich ist es Dir unbelassen, unter Verwendung einer Liste für GANZ SPEZIELLE ZWECKE mit str_replace selbst einen kodierer zu schreiben:
Der Martinfunction mk_murks_from_iso8859_1(s) {
$ar_search=array('ä', 'Ä', 'ü', 'Ü', 'ö', 'Ö');
$ar_replace=array('ä', 'Ä', 'ü', 'Ü', 'ö', 'Ö');
}
und zu verwenden:
$s=mk_murks_from_iso8859_1(file_get_contents('deine_textdatei.txt');
für andere Funktionen ist nämlich nicht klar, wie Du z.B. mit <,>,', oder " umgehen willst.
Jörg Reinholz
Fehlerteufel:
function mk_murks_from_iso8859_1($s) {
$ar_search=array('ä', 'Ä', 'ü', 'Ü', 'ö', 'Ö');
$ar_replace=array('ä', 'Ä', 'ü', 'Ü', 'ö', 'Ö');
return str_replace($ar_search, $ar_replace, $s)
}
und zu verwenden:
$s=mk_murks_from_iso8859_1(file_get_contents('deine_textdatei.txt');
hi,
Wie wird eine txt-Datei so includet, dass die Formatierung (Umbrüche und Tabs und so) erhalten bleibt und Sonderzeichen, die roh vorliegen, als dezimal (etwa ö als ö) ausgegeben werden?
Was in einer Datei steht, sind Bytes und das ist genau dasselbe, was auf STDOUT errwartet wird: Bytes. Datei einlesen, heißt Bytes einlesen. Datei ausgeben heißt: Bytes ausgeben.
Zeichen in einer Datei sind auch nur Bytes. Zeilenumbrüche sind Bytes, Tabs sind Bytes. Include die Datei und Du kriegst das alles: Deine Bytes.
Wenn Deine Bytes einen lesbaren Text darstellen sollen, kommt die Zeichenkodierung ins Spiel. Möglicherweise ergeben Deine Bytes einen utf-8-kodierten Text. Dann musst Du dem Ausgabegerät mitteilen, dass das utf-8-kodierter Text ist. Das Ausgabegerät (Browser, Terminal, Editor...) macht dann aus den Bytes wieder sichtbare Zeichen.
Ein utf-8-kodiertes 'ö' wird mit den Bytes C3 B6 in einer Datei abgebildet. Schicke diese Bytes zum Browser, sende zum Content-Type den Parameter ;charset=utf-8 und siehe da, Du siehst ein 'ö' ohne dass Du irgendwelche Umwandlungen machen musst. Da musst du nicht einmal die Codepoints der Zeichen kennen, die in der Datei drin sind. Es müssen nur die richtigen Bytes sein.
Horst