Steve: txt-Datei includen - Formatierung u. Sonderzeichen

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

  1. @@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'

    --
    „Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)
    1. 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?

      1. 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

      2. Hallo,

        Also rohe Zeichen sind schon "legitim"?

        Natürlich. Die Entity- bzw. Zeichenreferenzen &ouml;, &#246; und &#xF6; 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 &ouml; 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:

        • Die tatsächliche Kodierung eine Dateien (z.B. ISO-8859-1 oder UTF-8). Die Kodierung bestimmt, wie die Zeichen als Bytes gespeichert sind.
        • Eine Kodierungsangabe, die verarbeitetenden Programmen die Kodierung mitteilt (in HTML <meta charset="utf-8">; in HTTP der Content-Type-Header mit charset-Angabe; in Dateien ggf. ein UTF-8-BOM, in der Regel fehlt aber eine solche keine Kodierungsangabe)

        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

        1. 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

          --
          Arzt:    Gegen Ihr Übergewicht hilft wohl nur noch Gymnastik.
          Patient: Sie meinen, Kniebeugen und so?
          Arzt:    Nein, Kopfschütteln. Immer dann, wenn Ihnen jemand was zu essen anbietet.
          Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
          1. 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

          2. @@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'

            --
            „Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)
            1. @@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'

              --
              „Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)
        2. @@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'

          --
          „Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)
          1. Schau dir noch einmal an, was ich geschrieben habe.

            Die Entity- bzw. Zeichenreferenzen &ouml;, &#246; und &#xF6; 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 &ouml; 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

            1. @@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'

              --
              „Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)
              1. 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

              2. 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.

      3. @@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&amp;baz=quz"> stehen.

        In in " eingeschlossenen Attributwerten ist " ein Sonderzeichen; in in ' eingeschlossenen Attributwerten ist ' ein Sonderzeichen.

        Qapla'

        --
        „Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)
        1. 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.

          1. @@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'

            --
            „Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)
            1. 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)?

              1. 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.

                1. @@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'

                  --
                  „Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)
                  1. 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

                    --
                    war unregistriert "michaa"
          2. 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

  2. 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 &#246;) 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.

  3. 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 &#246;) 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:

    function mk_murks_from_iso8859_1(s) {  
      $ar_search=array('ä', 'Ä', 'ü', 'Ü', 'ö', 'Ö');  
      $ar_replace=array('&#228;', '&#196;', '&#252;', '&#220;', '&#246;', '&#214;');  
    }
    

    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

    1. Fehlerteufel:

      function mk_murks_from_iso8859_1($s) {  
        $ar_search=array('ä', 'Ä', 'ü', 'Ü', 'ö', 'Ö');  
        $ar_replace=array('&#228;', '&#196;', '&#252;', '&#220;', '&#246;', '&#214;');  
        return str_replace($ar_search, $ar_replace, $s)  
      }
      

      und zu verwenden:

      $s=mk_murks_from_iso8859_1(file_get_contents('deine_textdatei.txt');

  4. 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 &#246;) 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