Ergebnis 1 bis 9 von 9

Thema: Warum so viele MIME-Types für so wenige Dateitypen?

  1. #1

    Users Awaiting Email Confirmation

    Warum so viele MIME-Types für so wenige Dateitypen?

    Huhu, ich lebe wieder^^
    Hatte 'ne Weile Probleme mit meinem MMX Passwort, aber jetzt bin ich wieder da... Ich seh schon eure Gesichter *oje, der schon wieder* xD

    Ok, Zum Thema: Ziemlich theoretische Frage, aber mich interessiert's. Warum gibt's für viele Dateitypen unendlich viele MIME-Typen? Warum muss es z.B. für php-Dateien text/php, text/x-php, application/x-httpd-php, application/x-httpd-php-source u.s.w. geben? Wieso nicht nur einen MIME-Typ für jede Art von Datei!? Wäre das nicht viel einfacher?

    Gruß, Micha

  2. #2
    Die vier MIME Types haben unterschiedliche Bedeutungen:
    text/php steht für PHP-Quellcode
    text/x-php steht für ausführbaren PHP-Code (Dafür steht das x im Allgemeinen)
    application/x-httpd-php und application/x-httpd-php-source sind afaik Pseudotypen, die der Apache zum Beispiel intern verwendet, um die Dateien dem PHP-Interpreter zuzuweisen.

  3. #3

    Users Awaiting Email Confirmation

    Ist Php-Quellcode nicht auch ausführbarer Php Code und umgekehrt? Oder was ist da der große Unterschied? Man sieht es auch herrlich an xHtml: Eigentlich sollte es afaik den MIME-Type application/xml haben, das Interpretieren die Browser aber noch nicht (richtig), also schickt man es einfach als text/html.

    Ich finde das deshalb so doof, weil ich vorhabe, eine Anwendung zu schreiben, die auf verschiedene Dateien unterschiedlich reagiert. Nur gibt es keine einfache Methode, die Dateityp einer Datei herauszufinden!? Dateien der selben Art haben eine Fülle an möglichen MIME-Typen und eine Fülle an möglichen Dateiendungen. Toll, wieso muss man den Mist immer so kompliziert gestalten? Reicht nicht ein MIME-Typ pro Dateityp? Das wäre doch viel einfacher zu programmieren, oder nicht?

  4. #4
    Es geht darum, dass verschiedene Typen verschieden verarbeitet werden. Grad mal am Beispiel PHP, wenn die Datei per HTTP aufgerufen wird:

    • text/php wird direkt unverändert gesendet
    • application/x-httpd-php wird vom PHP Interpreter geparst und ausgeführt. Das heißt, der Benutzer kriegt nicht den Quelltext zugeschickt, sondern nur dessen Output
    • application/x-httpd-php-source wird auch vom PHP Interpreter geparst, aber nicht ausgeführt. Stattdessen wird der Sourcecode formatiert und eingefärbt ausgegeben


    Ich hoff mal, ich hab jetzt um die Uhrzeit nix durcheinander gebracht, aber eigentlich müssts so passen.

  5. #5

    Users Awaiting Email Confirmation

    Ok, dahinter steckt ein relativ sinnvolles System...

    Gibt es eigentlich trotzdem eine einfache Methode, in PHP den Dateityp herauszufinden? Ohne für jeden Dateityp zigtausend MIME-Types bzw. Dateiendungen abfragen zu müssen? Oder ist es einfach so aufwendig!?

  6. #6
    Zitat Zitat
    Eigentlich sollte es afaik den MIME-Type application/xml haben, das Interpretieren die Browser aber noch nicht (richtig), also schickt man es einfach als text/html.
    Jain. text/html ist eigentlich der MIME-Type für HTML. Da aber die Browser XHTML noch nicht richtig verarbeiten können (d.h. eigentlich nur der IE) wird XHTML 1.0 als HTML-kompatibles XHTML versendet, eben mit dem MIME-Typen text/html.
    XHTML-Dokumente können grundsätzlich auch als text/xml (nicht empfohlen) oder application/xml (teilweise emfohlen) bzw. application/xhtml+xml (der Beste) versendet werden.

    Die verscheidenen MIME-Typen haben auch hier unterschiedliche Auswirkungen:
    text/html jagt das XHTML durch den HTML Browser, d.h. Fehelr werden ignoriert und versucht zu korrigiert.
    Die X(HT)ML-Typen dagegen werden mit einem XML-Parser bearbeitet (bin mir aber dessen bei text/xml nicht sicher), d.h. bei einem Fehler sieht man nur einen Fehler, andererseits kann man dann aber auch verschiedene XML-Derivate (XHTML, MathML, SVG, etc.) miteinander kombinieren.

    Läuft PHP als Apache-Modul kannst du davon ausgehen, dass alle PHP-Datendungen als application/x-httpd-php bearbeitet wird, außer .phps (application/x-httpd-php-source).

  7. #7
    Ich möchte anmerken, daß lediglich der IE kein XHTML spricht. Wenn du Kram mit text/html schickst wird er als HTML geschickt - also hast du nicht nur alle Vorteile eines kastrierten SGML-Parsers (Unberechenbarkeit), sondern du verschickst auch noch mit hoher Wahrscheinlichkeit fehlerhaften Code (weil Kram wie <br /> kein korrektes HTML ist).


    BTW, das x- am Anfang des Content-type* weist nicht auf etwas ausführbares hin - genauso wenig wie die Kategorie application, die alles mögliche enthalten kann. Tatsächlich steht das x- für einen nonstandard-Datentyp, der nicht bei der IANA registriert ist. Ich kann also lustig meine eigenen Typen definieren, solange ich den Subtyp mit x- anfangen lasse. Ein Beispiel wäre TeX-Quelltext, der als application/x-tex läuft.

    Ein Vorteil von verschiedenen Content-types ist, daß man damit einige nette Sachen tun kann. Beispielsweise könnte man festlegen, daß alle Dateien der Ending .php in einem Ordner namens include vom Typ application/x-php-include sind und alle Dateien dieses Typs nicht direkt geöffnet werden dürfen. Wenn ich später auf irgendeinem anderen Weg eine Datei zu application/x-php-include erkläre (beispielsweise per .htaccess) wird auch diese nicht geöffnet.



    * "MIME type" ist veraltet, die Dinger heißen jetzt "internet media type". Ich nenne sie "Content-type", weil sie in den HTTP-Headern so heißen.

  8. #8
    Zitat Zitat
    Ich möchte anmerken, daß lediglich der IE kein XHTML spricht.
    Mein Lynx will application/xhtml+xml ebenfalls downloaden. Ist zufällig bekannt, wie Links oder andere Textbrowser darauf reagieren?

  9. #9
    Zitat Zitat von mitaki Beitrag anzeigen
    Mein Lynx will application/xhtml+xml ebenfalls downloaden.
    Ah, das wußte ich nicht. Interessant.

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •