Merkwürdige Unterschiede

[treziman]

Hallo,

melde mich nochmal mit anderen Gedanken.

Es ist schon komisch, dass sämtliche Skripte, die auf dem lokalen System einwandfrei liefen, im Web anders reagieren. Angefangen von den Umlauten, die jetzt als Kästchen erscheinen, über absolut adressierte Links, die jetzt nicht mehr funktionieren, obwohl dem Web angepasst, bis zu mysql, wo jetzt ein charset nicht mehr geht und das Skript stehenbleibt. CHARSET habe ich durch SET_NAMES ersetzt und die Umlaute muss ich direkt auf dem Server neu schreiben. Rätselhaft bleibt mir nur, wieso ein absolut adressiertes include nicht klappt. Also "include ('http://www....');". Ohne HTTP gehts aber wieder, also z.B. "include ('../verzeichnis/example.php');".
Anders wieder die Links mittels A-Tag. Da gehts auf beide Arten.
Auch habe ich festgestellt, dass eine absolute Adressierung deutlich sichtbar langsamer ist. Dies passiert beim Abarbeiten kleiner Textdateien, die ich auch zunächst absolut adressiert hatte. Das Frame, in dem diese Dateien bearbeitet wurden, erschien immer 3-4 Sekunden nach den anderen Frames oder Divs. Jetzt, mittels "file = '../verzeichnis/example.txt'", erscheint alles praktisch sofort.
Okay, sind eigentlich nur "Schönheitsfehler". Im grossen und ganzen läufts jetzt. Ist mir nur mal aufgefallen.

Gruss an alle
Thorsten

[Der Martin]

Hi,

melde mich nochmal mit anderen Gedanken.

... die erkennen lassen, dass dir einige Grundlagen einfach nicht klar sind.

Angefangen von den Umlauten, die jetzt als Kästchen erscheinen, ...

Widersprüchliche Angaben zur Zeichencodierung. Wenn Kästchen, Fragezeichen oder wirre Sonderzeichen erscheinen, verwendet der Browser offenbar eine andere Zeichencodierung als die, in der das Dokument gespeichert ist. Üblicherweise richtet sich der Browser nach dem Wert, der mit dem HTTP-Header
  Content-Type: text/html; charset=***
übermittelt wird. Wenn die charset-Angabe im HTTP-Header fehlt, holt er sich die Info ersatzweise aus dem gleichnamigen meta-Element; wenn das auch nicht da ist, verwendet er den Standardwert, den der Nutzer irgendwann mal eingestellt hat.
In deinem Fall tippe ich mal darauf, dass der Server UTF-8 angibt, das Dokument aber nicht wirklich in UTF-8 codiert ist.

über absolut adressierte Links, die jetzt nicht mehr funktionieren, obwohl dem Web angepasst, bis zu mysql, wo jetzt ein charset nicht mehr geht und das Skript stehenbleibt. CHARSET habe ich durch SET_NAMES ersetzt und die Umlaute muss ich direkt auf dem Server neu schreiben. Rätselhaft bleibt mir nur, wieso ein absolut adressiertes include nicht klappt. Also "include ('http://www....');". Ohne HTTP gehts aber wieder, also z.B. "include ('../verzeichnis/example.php');".

PHP-Includes als HTTP-Ressource abzurufen, *kann* normalerweise nicht funktionieren, weil dann nicht das Script selbst includiert wird, sondern dessen Ausgabe (die evtl. leer ist).

Anders wieder die Links mittels A-Tag. Da gehts auf beide Arten.

Klar, da ergänzt der Browser automatisch, was fehlt.

Auch habe ich festgestellt, dass eine absolute Adressierung deutlich sichtbar langsamer ist.

Meinst du mit "absolut", dass du in PHP die Ressourcen über HTTP anforderst? Das ist logisch, da kommt ja immer noch ein weiterer Request/Response-Zyklus dazu. Das macht man auch nicht.

Okay, sind eigentlich nur "Schönheitsfehler".

Das sehe ich nicht so - es sind grobe Grundlagenfehler, die man nochmal konsequent durchgehen und ausbessern sollte.

Ciao,
 Martin

[treziman]

Das sehe ich nicht so - es sind grobe Grundlagenfehler, die man nochmal konsequent durchgehen und ausbessern sollte.

Bin dabei! So belassen würde ich es natürlich nicht!

Gruss
Thorsten

[O'Brien]

Hi.

In deinem Fall tippe ich mal darauf, dass der Server UTF-8 angibt, das Dokument aber nicht wirklich in UTF-8 codiert ist.

Muss mich mal als Ahnungsloser outen (da ich bisher noch nie derartige Probleme hatte):
Wie finde ich heraus, als was der Server das Dokument ausliefert?
Wie ändere ich es, falls nötig?

Schönen Sonntag noch!
O'Brien

[Der Martin]

Hallo,

In deinem Fall tippe ich mal darauf, dass der Server UTF-8 angibt, das Dokument aber nicht wirklich in UTF-8 codiert ist.
Muss mich mal als Ahnungsloser outen (da ich bisher noch nie derartige Probleme hatte):
Wie finde ich heraus, als was der Server das Dokument ausliefert?

mit Tools, die auch die HTTP-Header anzeigen - beispielsweise Firebug oder die LiveHTTP-Extension für Firefox. Andere Browser bieten inzwischen Vergleichbares, ist mir aber nicht so vertraut.
Oder "zu Fuß" mit wget - wget zeigt auch zumindest den Content-Type-Header an, auf den es ja hier ankommt.

Wie ändere ich es, falls nötig?

Entweder in der Server-Config (z.B. in einer .htaccess) mit der Direktive AddDefaultCharset, oder - wenn man sowieso eine Scriptsprache wie etwa PHP verwendet - indem man den Header explizit sendet. In PHP beispielsweise mit der Funktion header().

Ciao,
 Martin

[Gunnar Bittersmann]

@@O'Brien:

nuqneH

Wie finde ich heraus, als was der Server das Dokument ausliefert?

HTTP-Header überprüfen

Wie ändere ich es, falls nötig?

Einstellung des HTTP-charset-Parameters (in Kürze dort auch auf deutsch, hier schonmal vorab)
Einstellung der Zeichencodierungsangabe ('charset') in .htaccess

Qapla'

[Gunnar Bittersmann]

@@Gunnar Bittersmann:

nuqneH

http://localhost/International/questions/qa-htaccess-charset

Der war ja mal wieder nicht schlecht.

Aber der ist besser: Einstellung der Zeichencodierungsangabe ('charset') in .htaccess

Qapla'

[O'Brien]

Hi.

Muss mich mal als Ahnungsloser outen (da ich bisher noch nie derartige Probleme hatte):
Wie finde ich heraus, als was der Server das Dokument ausliefert?
Wie ändere ich es, falls nötig?

Danke, Martin, danke Gunnar [1]!

Schönen Sonntag noch!
O'Brien

[1] ja, der war wirklich nicht schlecht ;)