nicht angemeldet dedlfix
dedlfix
dedlfix
dedlfix
dedlfix
dedlfix
Der Martin
Gumo!
Ich habe schon seit fast einem Jahr ein php-Script auf meiner HP laufen, welches mir nach Absenden von korrekt eingegebenen Formulardaten eine email mit deren Inhalt zustellt.
Seit nunmehr 14 Tagen enthält die Betreffszeile keine Umlaute mehr, so dass u.a. das Wort für so dargestellt wird: f�
Innhalb des Nachrichtentextes selbst, wird alles korrekt dargestellt.
Jetzt teilte mir mein Provider nach schriftlicher Kontaktaufnahme mit, dass der Fehler bei mir liegen müsse und ich die Kodierung überprüfen solle.
Das macht mich stutzig, weil das html/php-Dokument im korrekten iso... -Format eingerichtet ist und das Ganze halt vor 14 Tagen noch einwandfrei funktionierte...ich habe nämlich schon seit Monaten gar keine Änderungen an dem Script durchgeführt und bin mir deshalb auch keiner Schuld bewußt.
Der Server, auf dem meine Daten liegen bzw. von dem aus mir die mails zugestellt werden ist eine apache und ich verwende ein simples mail-Kommando.
Kann hier jemand auf die Sprünge helfen?
Jetzt teilte mir mein Provider nach schriftlicher Kontaktaufnahme mit, dass der Fehler bei mir liegen müsse und ich die Kodierung überprüfen solle.
Schneller Schuß ins blaue.. er hat die Apache Standardcodierung auf UTF8 umgestellt und du hast keinen Doctype eingestellt.
lg
Hallo!
So sieht mein html/php-Kopf aus:
<!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">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
Ist daran etwas falsch (...dann müßte der Nachrichteninhalt aber doch auch ohne Umlaute erscheinen, oder?) oder liegt es an der Apache Standardcodierung auf UTF8?
Hallo!
So sieht mein html/php-Kopf aus:
<!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">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />Ist daran etwas falsch (...dann müßte der Nachrichteninhalt aber doch auch ohne Umlaute erscheinen, oder?) oder liegt es an der Apache Standardcodierung auf UTF8?
Probier es auf folgende Art und Weiße
mail ("EMAIL",
"SUBJECT",
"MESSAGE",
"Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable" );
lg
Hallo nochmal!
Ich hatte meinem Script bereits vor Monaten die folgenden Anweisungen mitgegeben:
$Empfaenger = "meinemail@mail.de";
$Betreff = "Anfrage für...";
$Nachricht = "Neuer Eintrag im...";
$Header = "MIME-Version: 1.0\n";
$Header .= "Content-type: text/html; charset=iso-8859-1\n";
$Header .= "From: meinemail@mail.de <info@meinemail@mail.de>\n";
mail($Empfaenger, $Betreff, $Nachricht, $Header);
Daran habe ich wie gesagt seit Monaten nichts geändert und plötzlich die Umlautprobleme im Betreff.
Kann ich also davon ausgehen, dass der Fehler beim Anbieter liegt?
Mir kommt es so vor, als wolle dieser aus Bequemlichkeit nämlich gar nicht nachschauen, sondern mir einfach eine Standard-Antwort-email schicken, in der ich nach dem Fehler auf meiner Seite suchen soll....
Hi!
Könnte man aber nicht eigentlich, bei all den technischen Erklärungen, die ihr mir da um die Ohren gehauen habt, und die ich zur Hälfte leider nicht verstehe, davon ausgehen, dass die Kodierung im Dokument, bei den Meta-Tags usw. von mir eigentlich richtig war WEIL das Ganze doch bis vor kurzem OHNE Änderungen am Script meinerseits korrekt lief?
Ein Bekannter meinte, der Provider hätte vielleicht irgendein Update am apache-Server gemacht...
Ich weiß leider immer noch nicht, falls ich etwas umstellen müßte, was das wäre.
Die Internetseite wird mit allen Umlauten korrekt dargestellt, die über das Formular gemachten Einträge werden mit allen Umlauten korrekt in die Datenbank geschrieben, die email-Textinhalte enthalten ebenfalls alle Umlaute in korrekter Darstellung- nur die Betreffszeile halt seit kurzem nicht mehr...
Hi!
Könnte man aber nicht eigentlich, bei all den technischen Erklärungen, die ihr mir da um die Ohren gehauen habt, und die ich zur Hälfte leider nicht verstehe, davon ausgehen, dass die Kodierung im Dokument, bei den Meta-Tags usw. von mir eigentlich richtig war WEIL das Ganze doch bis vor kurzem OHNE Änderungen am Script meinerseits korrekt lief?
Email hat überhaupt nichts mit dem Apachen zu tun. Dass es bisher ging war Glück. Sorge dafür, dass du eindeutige Angaben zur Kodierung machst, keine vergisst und diese Angaben mit der tatsächlich verwendeten Kodierung übereinstimmen.
Ich weiß leider immer noch nicht, falls ich etwas umstellen müßte, was das wäre.
Das Subject benötigt eine spezielle Art der Kodierung. Dazu gibt es eine fertige Funktion (mb_encode_mimeheader()), die du verwenden kannst, wenn sie in deiner PHP-Version zur Verfügung steht.
Die Internetseite wird mit allen Umlauten korrekt dargestellt, die über das Formular gemachten Einträge werden mit allen Umlauten korrekt in die Datenbank geschrieben, die email-Textinhalte enthalten ebenfalls alle Umlaute in korrekter Darstellung- nur die Betreffszeile halt seit kurzem nicht mehr...
"Korrekt" ist nicht, wenn es zufällig wie gewünscht funktioniert. Verwende - wie gesagt - stets explizite Angaben zur Kodierung, wenn du etwas an ein anderes System/Medium übergibst. Erst dann ist es nicht nur zufällig korrekt sondern auch eindeutig. (Dass dann immer noch einige Clients was falsch machen, ist nicht zu verhindern.)
Lo!
Hello,
Email hat überhaupt nichts mit dem Apachen zu tun.
Das kannst Du aber so absolut nicht wirklich meinen:
Ich zitiere den OP:
Ich habe schon seit fast einem Jahr ein php-Script auf meiner HP laufen,
welches mir nach Absenden von korrekt eingegebenen Formulardaten eine
email mit deren Inhalt zustellt.
Wenn in seinem Fall für die Beantwortung der Requests ein Apache benutzt wird, hat der schon ein Wörtchen mitzureden, zumindest, was die Header des Dokumentes betrifft.
Das Problem tritt ja immer wieder auf, wenn die Provider einfach den Apachen (und PHP) upgraden und dabei (vielleicht sogar, ohne es zu wissen), das Default Character Set von ISO-8859-1 auf UTF-8 umstellen.
Die Dokumente werden dadurch nicht umgestellt und die PHP-Scripte auch nicht :-))
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
So, ich bin jetzt mal telefonisch beim meinem Provider durchgekommen, habe den ganzen Sachverhalt nochmals geschildert und- siehe da: Die Umstellung an deren Apache war dafür verantwortlich.
Ohne auch nur ein bit an meiner ja vorher funktionierenden Routine ändern zu müssen klappen die Umlaute jetzt wieder!
Hallo,
Die Umstellung an deren Apache war dafür verantwortlich.
was genau?
Ohne auch nur ein bit an meiner ja vorher funktionierenden Routine ändern zu müssen klappen die Umlaute jetzt wieder!
Das ist zwar im Moment schön für dich. Ich würde aber an deiner Stelle trotzdem wissen wollen, was der Provider umgestellt hat, denn offenbar verlässt sich dein Script auf bestimmte äußere Bedingungen. Da würde ich ansetzen wollen und das Script entsprechend "robuster" machen - besser gesagt: Alle nötigen Angaben eindeutig machen, so dass ich eben *nicht* mehr von den providerseitigen Voreinstellungen abhängig bin.
Denn jetzt hast du eine Schwachstelle gefunden und mit einem Heftpflaster abkleben lassen. Das hilft "solange wie's dauert". Ordentlich reparieren wäre auf lange Sicht günstiger.
So long,
Martin
Ich habe meine email routine mal durch folgendes ergänzt:
mb_language('iso-8859-1');
mb_send_mail($Empfaenger, $Betreff, $Nachricht);
Das Kommando wird erkannt und die Umlaute sind in der Testmail ebenfalls vorhanden.
Ich hoffe, ich habe dadurch vorgesorgt, so daß von meiner Seite nichts mehr vorliegen sollte.
Hi!
Email hat überhaupt nichts mit dem Apachen zu tun.
Das kannst Du aber so absolut nicht wirklich meinen:
Doch, schon.
Ich zitiere den OP:
Ich habe schon seit fast einem Jahr ein php-Script auf meiner HP laufen,
welches mir nach Absenden von korrekt eingegebenen Formulardaten eine
email mit deren Inhalt zustellt.
Ja, und? Die Email sendet nicht der Apache. Wenn die Daten schon schlecht ankommen, hat er eben zwei Baustellen. Eine, um die Daten in der gewünschten Kodierung zu bekommen und eine zweite, die Email mit korrekten Headern zu versehen.
Wenn in seinem Fall für die Beantwortung der Requests ein Apache benutzt wird, hat der schon ein Wörtchen mitzureden, zumindest, was die Header des Dokumentes betrifft.
Aber nur eins von zweien.
Das Problem tritt ja immer wieder auf, wenn die Provider einfach den Apachen (und PHP) upgraden und dabei (vielleicht sogar, ohne es zu wissen), das Default Character Set von ISO-8859-1 auf UTF-8 umstellen.
Vielleicht hat sein Provider was umgestellt. Seine Schuld ist es aber, nicht von vornherein für korrekte Angaben gesorgt zu haben beziehungsweise sich nicht allgemein mit dem Thema Kodierung auseinandergesetzt zu haben. Dem Provider die gesamte Schuld in die Schuhe zu schieben funktioniert in dem Fall nicht.
Lo!
Vielleicht hat sein Provider was umgestellt. Seine Schuld ist es aber, nicht von vornherein für korrekte Angaben gesorgt zu haben beziehungsweise sich nicht allgemein mit dem Thema Kodierung auseinandergesetzt zu haben. Dem Provider die gesamte Schuld in die Schuhe zu schieben funktioniert in dem Fall nicht.
Schlammpig programmiert hin oder her. Das ist nicht ganz richtig. Aus rechtlicher sicht schaut das anders aus. Der Provider stellt ein System zu Verfügung auf welchem Produktiv gearbeitet wird. Dahingehen muß man sich als Kunde verlassen können das diese Konfiguation des Provider auf jeden fall Gültig bleibt. Jede Änderung des Providers welche eine Änderung der Grundkonfiguartion hervoruft und sich dadurch auf die des Kunden auswirken kann, "muß" mit dem Kunden abgesprochen werden bzw ihm früh genug explizit mitgeteilt werden. Allein zu sagen wir machen ein update, bzw gar nichts sagen geht da schon mal überhaupt nicht. Für einen dahingehenden Ausfalls des Systems, bei Nichtmitteilung, egal aus welchen Gründen haftet der Provider für folge Kosten welchem dem Kunden durch seine Änderungen entstehen. Pups egal ob er dies in den AGB ausschließen will oder sonst was.
lg
Danke für die interessante Info!
Hi!
Aus rechtlicher sicht schaut das anders aus. Der Provider stellt ein System zu Verfügung auf welchem Produktiv gearbeitet wird. Dahingehen muß man sich als Kunde verlassen können das diese Konfiguation des Provider auf jeden fall Gültig bleibt. Jede Änderung des Providers welche eine Änderung der Grundkonfiguartion hervoruft und sich dadurch auf die des Kunden auswirken kann, "muß" mit dem Kunden abgesprochen werden bzw ihm früh genug explizit mitgeteilt werden. Allein zu sagen wir machen ein update, bzw gar nichts sagen geht da schon mal überhaupt nicht. Für einen dahingehenden Ausfalls des Systems, bei Nichtmitteilung, egal aus welchen Gründen haftet der Provider für folge Kosten welchem dem Kunden durch seine Änderungen entstehen. Pups egal ob er dies in den AGB ausschließen will oder sonst was.
Auf welcher rechtlichen Grundlage basiert dies?
Lo!
Hi!
Aus rechtlicher sicht schaut das anders aus. Der Provider stellt ein System zu Verfügung auf welchem Produktiv gearbeitet wird. Dahingehen muß man sich als Kunde verlassen können das diese Konfiguation des Provider auf jeden fall Gültig bleibt. Jede Änderung des Providers welche eine Änderung der Grundkonfiguartion hervoruft und sich dadurch auf die des Kunden auswirken kann, "muß" mit dem Kunden abgesprochen werden bzw ihm früh genug explizit mitgeteilt werden. Allein zu sagen wir machen ein update, bzw gar nichts sagen geht da schon mal überhaupt nicht. Für einen dahingehenden Ausfalls des Systems, bei Nichtmitteilung, egal aus welchen Gründen haftet der Provider für folge Kosten welchem dem Kunden durch seine Änderungen entstehen. Pups egal ob er dies in den AGB ausschließen will oder sonst was.
Auf welcher rechtlichen Grundlage basiert dies?
Mußt jetzt google, aber gibt es schon einen richterlichen entscheid in diese Richtung, das der Kunde nicht durch eine Willkühr entscheidung des Providers bei einem bestehenden laufenden Vetrag kosten einer Umstellung des zuvor funktionierenden Produkts aufgezwungen werden kann. Gegangen ist des damals glaub ich konkret das der Provider einfach von PHP 4 auf 5 umgestellt hat. Da war die Aufregnung natürlich riesen große bei vielen. ;)
lg
Hi!
Mußt jetzt google, aber gibt es schon einen richterlichen entscheid in diese Richtung, das der Kunde nicht durch eine Willkühr entscheidung des Providers bei einem bestehenden laufenden Vetrag kosten einer Umstellung des zuvor funktionierenden Produkts aufgezwungen werden kann.
OK, es war also eine Gerichtsentscheidung. Einer solchen liegt in der Regel ein ganz konkreter Fall zugrunde. Das Ergebnis kann nicht immer verallgemeinert werden kann. Deshalb bitte Vorsicht bei solchen "Es-ist-so"-Aussagen. Formulier doch das lieber so, dass du das Gerichtsurteil erwähnst, bei dem es um $fall mit dem Ergebnis $urteil gegangen ist. Ob dann $fall mit $mein_fall vergleichbar ist, muss $ich dann entscheiden.
Gegangen ist des damals glaub ich konkret das der Provider einfach von PHP 4 auf 5 umgestellt hat. Da war die Aufregnung natürlich riesen große bei vielen. ;)
Das war - ohne die rechtliche Problematik in dem Fall zu betrachten - zweifellos ein kapitaler Fehler des Providers. Es sollte allgemein bekannt sein, dass viele PHP-4-Script sicherheitstechnisch sehr lasch programmiert sind und sich einige Features auch Jahre nach dem Ankündigen, sie auf die Deprecated-Liste zu setzen, immer noch hoher Beliebtheit erfreuten und (gefühlt leider immer noch) erfreuen. Dazu trug auch bei, dass die bereits seit PHP 4.2 geänderte Default-Konfiguration von den Providern nicht übernommen wurde. Dies taten sie sicherlich, um sich jede Menge nicht funktionierende Scripte und die damit verbundenen Supportanfragen zu ersparen. Wer damals schon nicht die Kunden über bevorstehende Änderungen aufgeklärt hat, handelt also nur konsequent, wenn er diese nun einfach durchzieht - ebenfalls ohne die Kunden zu informieren :-)
Lo!
Hi!
Mußt jetzt google, aber gibt es schon einen richterlichen entscheid in diese Richtung, das der Kunde nicht durch eine Willkühr entscheidung des Providers bei einem bestehenden laufenden Vetrag kosten einer Umstellung des zuvor funktionierenden Produkts aufgezwungen werden kann.
OK, es war also eine Gerichtsentscheidung. Einer solchen liegt in der Regel ein ganz konkreter Fall zugrunde. Das Ergebnis kann nicht immer verallgemeinert werden kann. Deshalb bitte Vorsicht bei solchen "Es-ist-so"-Aussagen. Formulier doch das lieber so, dass du das Gerichtsurteil erwähnst, bei dem es um $fall mit dem Ergebnis $urteil gegangen ist. Ob dann $fall mit $mein_fall vergleichbar ist, muss $ich dann entscheiden.
So ganz einfach ist das nicht. Denn das Ganze hat schon Musterprozesscharakter, denn im Endeffekt kommt dabei raus das eine technische Änderungen wie ein Versionsupdate nur dann gemacht werden kann wenn dadruch gewährleistet wird das die vorhandene Systeme von Kunden nicht beeinträchtigt werden sofern diese keine Vertöße aufweisen. Wenn jemand schlammpig programmiert ist das keine Begründung zu sagen das geht jetzt nicht mehr.
Ganz einfaches blödes Fall Beispiel: Der Kunde gibt an ein Drittunternehmen den Auftrag für diesen Host, der register Globals auf on hat, unter diesen Bedingungen ein System zu schreiben und zahlt dafür viel geld. Das RG heute verpöhnt ist sei mal dahin gestellt und jetzt unwichtig. Fakt ist aber der Provider untestütz dies. Jetzt läuft dieses System prächtig und Fehlerfrei. So der Provider macht ein Apache Update im zugedessen stellt er in PHP RG off .. oder noch fieser Safe Mode auf on ... Wie kommt der Kunde dazu einen weiteren natürlich kostenpflichtigen Änderungsauftrag für das System zu bezahlen nur weil der Provider beschließ wir machen mal schnell ein heimliches Update und unterstützen dies und das nicht mehr. Hier findet der Kunde geänderte Rahmenbdingungen wofür er aber nichts kann. Und genau da wird der Provider aber in die Pflicht genommen.
lg
Hello,
[...]
das wäre vergleichbar damit, wenn Ein Netzbetreiber für ISDN plötzlich ein Leistungsmerkmal ersatzlos strichen würde und dafür zwei neue (vielleicht durchaus wünschenswerte) einführen würde, die aber das weggenommene nicht ersetzen und dies auch noch ohne eine angemessene Übergangsfrist, in der beide Versionen funktionieren.
Es hat schon einen Grund, warum die kleinen Provider, die nicht wirklich Ahnung haben, nach und nach vom Markt verschwinden. Man kann nicht jedes Update / Upgrade ungeprüft und ohne Rücksprache und Anleitung für die nachfolgenden Instanzen (Kunden) einfach mitmachen.
Ich habe bei meinen Kandidaten diese Probleme allzu oft. Deshalb bestehen die auf kurzfristiger Reversibilität bei Upgrades und lieben das Aptitude-System. Was ich da neulich für Maleschen hatte, kann man hier im Forum ja nachlesen. Es ließ sich zum Glück lösen, hat mir aber meinen Arsch auf Grundeis gehen lassen. Ich hätte mich mit den Betroffenen nicht einmal mehr streiten müssen hinterher, denn die hätten es nicth überlebt...
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Hello,
[...]
das wäre vergleichbar damit, wenn Ein Netzbetreiber für ISDN plötzlich ein Leistungsmerkmal ersatzlos strichen würde und dafür zwei neue (vielleicht durchaus wünschenswerte) einführen würde, die aber das weggenommene nicht ersetzen und dies auch noch ohne eine angemessene Übergangsfrist, in der beide Versionen funktionieren.
Es hat schon einen Grund, warum die kleinen Provider, die nicht wirklich Ahnung haben, nach und nach vom Markt verschwinden. Man kann nicht jedes Update / Upgrade ungeprüft und ohne Rücksprache und Anleitung für die nachfolgenden Instanzen (Kunden) einfach mitmachen.
Absolut vollkommen richtig. Wiederspiegelt genau meine Meinung dazu.
lg Peter
Hello,
Auf welcher rechtlichen Grundlage basiert dies?
Verträge sind zu halten?
Und es kommt ja auf jeden Fall eine Vertrag durch Einigkeit zustande.
Da würden nachträgliche einseitige (gravierende Änderungen) auf jeden Fall überraschend sein, auch wenn sie global in den AGB benannt wären.
Daher könnte ich diese Rechtsauffassung schon teilen.
Es wäre also schon sehr interessant, wenn man vielleicht noch das eine oder andere Urteil finden könnte, das dies ebenfalls tut.
Die (kostenlose) Erweiterung auf eine Obermenge des bisher gehabten wäre insofern kein Vertragsbruch für den Kunden, wenn dieser seine Untermenge ungestört weiter nutzen könnte. Da die Upgrades aber in der regel gundlegende Änderungen (hier z.B. u.a. das Character-Set) vornehmen, die für die Untermenge eine Störung bedeuten (bisher musste das Character-Set nicht explizit berücksichtigt werden, weil grundsätzlich ISO-8859-1 benutzt wurde, das mal als These des Anwaltes... )
Also, nicht dass das jetzt wieder verkehrt verstanden wird. Es ist nicht meine unumstößliche Meinung, aber ich kann es mir gut vorstellen. Und deshalb würde ich diesen Thread gerne von einigen Insidern fortgesetzt sehen :-)
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Hi!
Verträge sind zu halten?
Und es kommt ja auf jeden Fall eine Vertrag durch Einigkeit zustande.
Da würden nachträgliche einseitige (gravierende Änderungen) auf jeden Fall überraschend sein, auch wenn sie global in den AGB benannt wären.
Ja, vermutlich würden solche "Wir dürfen auch ohne Ankündigung ändern"-Klauseln in den AGBs als überraschend bewertet werden und damit als nichtig erklärt.
Andererseits will man als Provider sicher nicht ewig auf alter unsicherer Technik sitzenbleiben. Es muss also auch Wege geben, wie der Provider davon wegkommt. Denn ihm ist auch nicht ständig Mehrarbeit wegen der (systemimmanenten) Sicherheitsmängel zuzumuten. Notfalls muss er fristgerecht kündigen. Und das muss auf alle Fälle gehen, auch wenn das dem Gekündigten Kosten verursacht für eine neue Providersuche oder ein Umarbeiten des Systems, weil sich kein Provider mit alter Technik mehr findet.
Lo!
Hallo,
Andererseits will man als Provider sicher nicht ewig auf alter unsicherer Technik sitzenbleiben. Es muss also auch Wege geben, wie der Provider davon wegkommt.
natürlich - aber wäre es dem Provider dann nicht zuzumuten, ein Rundschreiben an seine Kunden abzusetzen, in dem er die Maßnahme ankündigt, den Sinn und die Vorteile aufzeigt und darauf hinweist, dass bei bestimmten Konfigurationen dann Probleme auftreten können? Eventuell noch mit Verweis auf eine Informationsseite, die die typischen Stolperfallen beim Umstieg erwähnt und Abhilfemöglichkeiten beschreibt? Das Ganze bitte ausreichend lange vor der eigentlichen Umstellung (4..6 Wochen sollten IMHO genügen), damit die Kunden auch Zeit haben, ihre Scripte zu überprüfen und ggf. anzupassen.
Das würde ich jedenfalls als "Königsweg" sehen.
So long,
Martin
Andererseits will man als Provider sicher nicht ewig auf alter unsicherer Technik sitzenbleiben. Es muss also auch Wege geben, wie der Provider davon wegkommt.
natürlich - aber wäre es dem Provider dann nicht zuzumuten, ein Rundschreiben an seine Kunden abzusetzen, in dem er die Maßnahme ankündigt, den Sinn und die Vorteile aufzeigt und darauf hinweist, dass bei bestimmten Konfigurationen dann Probleme auftreten können? Eventuell noch mit Verweis auf eine Informationsseite, die die typischen Stolperfallen beim Umstieg erwähnt und Abhilfemöglichkeiten beschreibt? Das Ganze bitte ausreichend lange vor der eigentlichen Umstellung (4..6 Wochen sollten IMHO genügen), damit die Kunden auch Zeit haben, ihre Scripte zu überprüfen und ggf. anzupassen.
Das würde ich jedenfalls als "Königsweg" sehen.
Richtig. Allerdings ist das nicht der Königsweg, sondern der Weg welche jeder vernüftige und "gute" Provider geht. Jene, und das sind viel, die das nicht so machen sind low Class Provider, das kann man dann getrost vergessen, und ist für ernsthaftes Hosting sowies nicht zu empfehlen.
lg
hi Peter,
Schlammpig programmiert hin oder her. Das ist nicht ganz richtig. Aus rechtlicher sicht schaut das anders aus. Der Provider stellt ein System zu Verfügung auf welchem Produktiv gearbeitet wird.[..]
Das ist ein außerordentlich interessanter Aspekt, full Ack!
Es ist nur halt so, dass "Recht haben" und "Recht bekommen" zwei verschiedene Dinge sind. Ich hatte mal einen Provider, der behauptete eines Tages, dass meine CGI-Scripts, die jahrelang zuverlässig funktionierten, seinen Server runterziehen würden. Ein andermal hat er behauptet, dass jedesmal, wenn ich einen FTP auf den Server ausgeführt habe, dieser in die Knie geht. Rotzfrech hat der dann 1. meinen FTP-Account gesperrt und 2. das Ausführen meiner CGI-Scripts unterbunden.
Und das war ein Provider, der mich kurz vorher noch privat abends um zehn angerufen hatte, wegen irgendwelcher Perl-Probleme!
Wie auch immer, ich habe versucht, dem zu erklären, dass ein CGI-Script ein bissl mehr CPU braucht, als ein Webserverprozess, der ebend mal ne HTML-Datei von der Platte liest, aber er hat das nicht verstanden. Und so blieb mir nur der Wechsel zu einem anderen Provider (KK).
Hotti
hi Peter,
Schlammpig programmiert hin oder her. Das ist nicht ganz richtig. Aus rechtlicher sicht schaut das anders aus. Der Provider stellt ein System zu Verfügung auf welchem Produktiv gearbeitet wird.[..]
Das ist ein außerordentlich interessanter Aspekt, full Ack!
Es ist nur halt so, dass "Recht haben" und "Recht bekommen" zwei verschiedene Dinge sind. Ich hatte mal einen Provider, der behauptete eines Tages, dass meine CGI-Scripts, die jahrelang zuverlässig funktionierten, seinen Server runterziehen würden. Ein andermal hat er behauptet, dass jedesmal, wenn ich einen FTP auf den Server ausgeführt habe, dieser in die Knie geht. Rotzfrech hat der dann 1. meinen FTP-Account gesperrt und 2. das Ausführen meiner CGI-Scripts unterbunden.
Naja das ist schwierig. Bin ja jetzt seit ein paar Jahren auch mein eigener Provider (nur für Projekte von Kunden) ;). Habe aber einige Hosts von Kunden bei anderen Providern. Das Problem mit dem Ressourcenfressenden Script ist so seine Sache. Mir ist das auch einmal passiert das ich in einem Bildergallerietool versehentlich alles auf echtzeitgenerierung eingestellt habe. Das sorgte dann für Aufmerksamkeit beim Provider. Auch logisch.
Ist aber ein guter Provider und er hat mich darauf hingewiesen, das er die Ausführung unterbinden muß wenn ich es nicht ändere, da es möderisch viele Ressourcen benötigt. Ich habe es angesehen und dann natürlich korrigiert und die Sache war erledigt. War ja auch ein dummer Fehler.
Ob dein CGI 2 Jaher schon funktioniert oder nicht hat nichts damit zu tun wieviel Speicher und CPU Ressourcen es benötigt. Wenn dahingehenden noch hinzu kommt dass die Benutzeranzahl auf deinem Host kontenuierlich ansteigt dann ist es gut möglich das etwas was zuvor nicht auffällt, weil es verschmerzbar ist, dann zum Problem werden kann und der provider muss einschreiten.
lg
Hi!
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
Das ist eine Ersatzangabe für den Fall, dass der Server keine HTTP-Headerzeile gleichen Namens, beziehungsweise eine ohne charset-Angabe sendet. Das wird vor allem auch dann benötigt, wenn das Dokument lokal gespeichert werden soll. Überprüfen kann man die HTTP-Header zum Beispiel mit der livehttpheaders-Extension oder Firebug für den Firefox und mit diversen Online-Diensten.
Ist daran etwas falsch (...dann müßte der Nachrichteninhalt aber doch auch ohne Umlaute erscheinen, oder?) oder liegt es an der Apache Standardcodierung auf UTF8?
Eine E-Mail hat nichts mit irgendwelchen Webseiten zu tun, das ist eine andere Baustelle.
mail ("EMAIL",
"SUBJECT",
"MESSAGE",
"Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable" );
Zeilenumbrüche zwischen den Headern nicht vergessen! Außerdem gilt Content-Type - wie der Name sagt - für den Inhalt. Die E-Mail-Headerzeilen sind nicht davon beeinflusst. Die benötigen ein eigenes Kodierverfahren. Siehe unter anderem im Abschnitt E-Mail meines Kontextwechsel-Artikels.
Lo!
Eine E-Mail hat nichts mit irgendwelchen Webseiten zu tun, das ist eine andere Baustelle.
??? Na logisch hat es damit zu tun. Den die Webseite/Webserver bestimmt mehr weniger über das übergeben Charset welches dann in die Mailfunktion gestopft wird. Sofern man es nicht casted bzw explizit deklariert beeinflußt dies sehr wohl das verhalten. Da liegt auch der Hunde begraben.
lg
moin,
Kann hier jemand auf die Sprünge helfen?
Es sind immer zwei Dinge, die übereinstimmen müssen:
Prüfen kannst Du das, indem Du mal selbst in den HTTP-Header einer Response schaust. Ändern kannst Du das mit einer Zeile in der Serverkonfiguration (.htaccess).
AddDefaultCharset ISO-8859-1 # example
Hotti
Hallo,
Es sind immer zwei Dinge, die übereinstimmen müssen:
- die charsetAngabe im HTTP-Header (Webserver)
- die charsetAngabe im HTML-Dokument
und sie sollten natürlich zur tatsächlichen Codierung des Dokuments passen!
Prüfen kannst Du das, indem Du mal selbst in den HTTP-Header einer Response schaust. Ändern kannst Du das mit einer Zeile in der Serverkonfiguration (.htaccess).
Und ausprobieren kannst du das, indem du nach dem Laden des fraglichen Dokuments mal verschiedene Codierungen im Browser von Hand einstellst. Wenn du eine gefunden hast, die alle Zeichen im Dokument korrekt anzeigt, ist die Wahrscheinlichkeit groß, dass du die richtige gefunden hast.
Ciao,
Martin
Hallo,
Es sind immer zwei Dinge, die übereinstimmen müssen:
- die charsetAngabe im HTTP-Header (Webserver)
- die charsetAngabe im HTML-Dokument
und sie sollten natürlich zur tatsächlichen Codierung des Dokuments passen!
Genau das ist die charset-Angabe im meta-Tag. Und die muss mit dem HTTP-Header übereinstimmen.
Natürlich müssen die im Dokument verwendeten Zeichen auch der deklarierten Kodierung entsprechen.
Hotti
Moin,
- die charsetAngabe im HTTP-Header (Webserver)
- die charsetAngabe im HTML-Dokument
und sie sollten natürlich zur tatsächlichen Codierung des Dokuments passen!
Genau das ist die charset-Angabe im meta-Tag.
nein, eben nicht. Die ist -ebenso wie die Angabe im HTTP-Header- nur ein Etikett, das angibt, was *angeblich* drin ist.
Wenn mir der Inhaber des Eisenwarenladens ein Päckchen Schrauben reicht und sagt, "Hier haben Sie 100 Stück M4x25" (HTTP-Header), und wenn auf dem Päckchen sogar draufsteht "M4x25 - 100 Stück" (meta-Element), dann heißt das immer noch nicht zwangsläufig, dass auch M4-Schrauben drin sind.
Natürlich müssen die im Dokument verwendeten Zeichen auch der deklarierten Kodierung entsprechen.
Genau das sagte ich ja schon - und das ist der wichtigste Schritt, der vor allem von Einsteigern gern übersehen wird. Die ändern die Codierungsangaben im meta-Element, vielleicht sogar im HTTP-Header, und wundern sich, warum immer noch Hieroglyphen angezeigt werden, weil die Schachtel eben keine M4-Schrauben enthält, sondern 3.5er Spax.
So long,
Martin
Moin,
- die charsetAngabe im HTTP-Header (Webserver)
- die charsetAngabe im HTML-Dokument
und sie sollten natürlich zur tatsächlichen Codierung des Dokuments passen!
Genau das ist die charset-Angabe im meta-Tag.nein, eben nicht. Die ist -ebenso wie die Angabe im HTTP-Header- nur ein Etikett, das angibt, was *angeblich* drin ist.
Tja, es gibt Webdesigner, die wissen eben nicht, was sie da eingetütet haben. Da kann ich in diesem Fall auch nur raten.
Hotti
Hello Hotti,
Kann hier jemand auf die Sprünge helfen?
Es sind immer zwei Dinge, die übereinstimmen müssen:
- die charsetAngabe im HTTP-Header (Webserver)
- die charsetAngabe im HTML-Dokument
Das reicht nicht.
- die charsetAngabe im HTTP-Header (Einstellung des Webservers)
(- die charsetAngabe im HTML-Dokument, ersatzweise)
- das verwendete Characterset im Dokument
-- abhängig von der Einstellung des Editors
-- abhängig von verwendeten Datenquellen
-- abhängig von verwendeten Umwandlungsfunktionen
- die Codierung der Übertragung und ihr möglicher Zeichenumfang
Wahrscheinlich habe ich auch noch 'was vergessen.
Aber oft wird vergessen, dass Dokumente bereits in ISO-8859-x vorliegen und diese nicht einfach durch Umstellung des Headers zu Domumenten in UTF-8 werden, sondern gezielt umgewandelt werden müssen.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
hi,
Aber oft wird vergessen, dass Dokumente bereits in ISO-8859-x vorliegen und diese nicht einfach durch Umstellung des Headers zu Domumenten in UTF-8 werden, sondern gezielt umgewandelt werden müssen.
Das kannste auch getrost vergessen. Da wird ein der im Dokument verwendeten Kodierung entsprechend passender Header gesendet und gut isses. Bei Umwandlungen der Kodierung ist mit Datenverlust zu rechnen! Eine Umwandlung der Kodierung mag zwar für die paar Umlaute funktionieren, aber ansonsten empfehle ich das nicht.
Hotti
