Bottle : static_file : keine Umlaute

schms · Sonntag 29. Dezember 2013, 22:50

Hallo

Bottle 0.13-dev
Firefox 26.0

Ich habe eine statische HTML Seite via bottle/static_file und via Firefox/<File>/<Open File> anzeigen lassen.
Die Umlaute der HTML Seite wurde bei der Anzeige via Firefox/<File>/<Open File> im Firefox korrekt angezeigt.
Die Umlaute der HTML Seite wurden bei der Anzeige via bottle/static_file im gleichen Firefox nicht angezeigt.
Die Lösung für die Variante bottle/static_file war das Einfügen von < mimetype='content type' > im Kommando
<return static_file(.....)> :

Diese Version zeigt die Umlaute der statischen HTML Seite /home/stefan/Ubuntu One/Programming/css/<filename>
korrekt an:

Code: Alles auswählen

@route('/<filename:path>')
def send_static(filename):
    return static_file(filename, root='/home/stefan/Ubuntu One/Programming/css', mimetype='content type')

Diese Version zeigt die Umlaute der statischen HTML Seite /home/stefan/Ubuntu One/Programming/css/<filename>
nicht korrekt an, da <mimetype='content type'> fehlt:

Code: Alles auswählen

@route('/<filename:path>')
def send_static(filename):
    return static_file(filename, root='/home/stefan/Ubuntu One/Programming/css')

Kann jemand erklären, wieso die korrekte Darstellung der statischen HTML Seite nur mit <mimetype='content type'>
in bottle/static_file erfolgt ? Ist das ein Bug von bottle/static_file oder ein Bug der statischen HTML Seite oder von beiden ?

Anhang:

Das bottle Skript:

Code: Alles auswählen

#!/usr/bin/python
# -*- coding: utf-8 -*-

from bottle import route, run, template, debug, static_file, response

@route('/<filename:path>')
def send_static(filename):
    return static_file(filename, root='/home/stefan/Ubuntu One/Programming/css', mimetype='content type')

# debuging - do not use it in production environments
#
debug(True)

# reloader=True - automatically detect changes to the script
#                 and reload new version once it is called again
#                 Do not use it in production environments

run(host='localhost', port=8080, reloader=True)

Teile der statischen HTML Seite mit Umlauten (siehe <title>):
(..)
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="de" lang="de">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<title>Meine erste Überschrift</title>
</head>
<body id="startseite">
<div id="wrapper">

<div id="kopfzeile">
<img src="logo.png" alt="Logo" width="80" height="80" />
</div>
...
(..)

BlackJack · Montag 30. Dezember 2013, 00:03

@schms: Ich würde sagen das ist ein Bug in Deinem Programm denn 'content type' ist kein gültiger 'Content-Type' würde ich mal sagen. Da hättest Du auch 'schwubbeldieduuuh' schreiben können. In so einem Fall muss der Browser dann halt raten was es ist und er rät bei Deinem Dokument anscheinend richtig.

Wenn man selber keinen `mimetype` angibt, dann wird geraten, und zwar mit Hilfe des `mimetypes`-Moduls aus der Standardbibliothek. Und das rät in Deinem Fall die Kodierung falsch, vermute ich mal.

Die Frage ist ob `bottle` die Kodierung zwingend mitsenden sollte wenn HTML übertragen wird, weil an der Stelle die RFCs ziemlich doof sind: Wenn der Server eine Kodierung in den Headern schickt wird *die* vom Browser genommen, auch wenn die Kodierung auch im HTML angegeben wird. Als wenn der Server-Admin besser wüsste wie *alle* HTML-Seiten kodiert sind als der jeweilige Autor der das HTML geschrieben hat. Also könnte man den Fehler vielleicht auch im HTTP-Standard sehen.

Ich würde wahrscheinlich einen Bugreport bei Bottle aufmachen und sehen was Marcel dazu als Lösung einfällt.

Edit: Wie heisst die Datei denn? Bei mir auf dem System wird keine Kodierung für die üblichen Endungen für HTML-Dateien geraten (das zweite Element im Tupel):

Code: Alles auswählen

In [55]: mimetypes.guess_type('test.html')
Out[55]: ('text/html', None)

In [56]: mimetypes.guess_type('test.xhtml')
Out[56]: ('application/xhtml+xml', None)

In [57]: mimetypes.guess_type('test.htm')
Out[57]: ('text/html', None)

schms · Montag 30. Dezember 2013, 12:32

Hallo BlackJack

Danke für das Feedback.

a)

Die Datei heisst to-do7.html. Ein mimetypes.guess zeigt keine
Auffälligkeiten:

Code: Alles auswählen

$ python 
Python 2.7.5+ (default, Sep 19 2013, 13:48:49) 
[GCC 4.8.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import mimetypes
>>> mimetypes.guess_type('to-do7.html')
('text/html', None)
>>>

Ein Check von to-do7.html gegen http://validator.w3.org/check ergibt keine Fehler:
(..)
This document was successfully checked as XHTML 1.0 Transitional!
(..)

Kann es sein, dass bottle nicht mit XHTML umgehen kann ?

b)

Falls ich die Funktion static_file richtig interpretiere, führt die (falsche) mimetype - Angabe in Funktionsaufruf < static_file( ... mimetype='content type' ... ) >
dazu, dass bottle/static_file KEIN mimetypes.guess_tmpe(filename) ausführt, da 'mimetype='auto' im Funktionsaufruf überschrieben wird. Da die Umlaute von to-do7.html im Firefox aber nur korrekt angezeigt werden, wenn <mimetype='content type' > gesetzt ist, vermute ich im Moment einen Fehler in bottle im Bereich des mimetype - Handling. Im source code
von bottle/static_file kann ich aber nichts finden.

Code: Alles auswählen

def static_file(filename, root, mimetype='auto', download=False)
(..)
if mimetype == 'auto':
    mimetype, encoding = mimetypes.guess_type(filename)
    if mimetype: headers['Content-Type'] = mimetype
    if encoding: headers['Content-Encoding'] = encoding
elif mimetype:
    headers['Content-Type'] = mimetype
(..)

BlackJack · Montag 30. Dezember 2013, 13:09

@schms: So langsam vermute ich das Problem im (X)HTML, denn wenn die Kodierung im <meta>-Tag auch tatsächlich für den Inhalt verwendet wird, dann dürfte das nicht als XHTML validieren weil es dann kein gültiges XML ist. Die Datei ist also auf die eine oder andere Weise kaputt weil sich die implizite Kodierungsangabe UTF-8 von XML und das <meta>-Tag widersprechen.

Edit: Nächster Schritt wäre also heraus zu finden wie der Text *tatsächlich* kodiert ist und dann die Datei(en) entsprechend reparieren. Und wenn man XHTML mit dem passenden ``Content-Type`` ausliefern will, muss die Datei auch die Endung '.xhtml' haben.