Probleme mit Umlauten nach Abspeichern

kekskruemel

kekskruemel

Angesehenes Mitglied
Hallo,

ich habe an meinen Dateien nichts umprogrammiert.
Bisher waren Umlaute direkt als Umlaut geschrieben, auch in meinem Skript in den SPrachdateien.

Seit kurzem sind alle Umlaute einfach als Ä oder auch ä , etc. in den Dateien geändert.

Bei dem Abruf meiner Datenbankinhalte wurden ebenfalls die Umlaute falsch dargestellt. Bei einem Einblick in die Datenbank stellte ich jedoch fest, dass alle Daten weiterhin als Umlaute drin stehen.

Ich habe die Datenbank gelöscht und das Backup eingespielt und schon ging dies wieder.

Trotzdem sind meine php Dateien weiterhin einfach umgeschrieben.
Einige meiner Formulare die zuvor einwandfrei funktioniert haben, versendet es auf einmal nicht mehr. Ich finde auch keinen Fehler. Es ist ja nichts von mir in der Programmierung geändert wurden.

Ein anderes Problem besteht in einer php Datei, die alles in XML ausgeben soll. Hat diese noch vor kurzem funktioniert. Gibt diese nun Fehler aus:
Bsp: http://www.tankcheck.de/lkkkkk.php?q=01217&r=10&k=1&l=DE
Schaut man sich den QUelltext an, sieht man aber, dass alle Informationen in die XML geschrieben werden. Also auch hier eher ein Formatierungsfehler.
Aber bis vor kurzem ging die Seite noch.

Bei einer weiteren Seite versendet es das Formular nicht. Bei einem Klick auf "Senden" geschieht gar nichts. Keine Fehlermeldung durch das "or die-Error"-SQL Anhängsel, noch einen Eintrag wie vorgesehen in die Datenbank bei diesem Formular.

Es ist sehr eigenartig.
 
Hallo Kekskrümel,

ich habe eine Vermutung, kann dir aber möglicherweise nur begrenzt helfen.

Ich vermute sehr stark, dass du deine Dateien zwar nicht umgewandelt hast, aber dass du den Zeichensatz verändert hast. Hast du in letzter Zeit irgendwo utf-8 eintragen, wo vorher iso-8859-1 stand? Oder umgekehrt?

Arbeitest du möglicherweise mit Dreamweaver und hast oben bei Modifizieren / Seiteneigenschaften / Titel/Kodierung rumgespielt?

Der Fehler auf deiner XML-Datei zeigt direkt auf den Anfang. Lasse ich mir davon mit Firefox den Quelltext anzeigen und stelle dann bei Ansicht auf ISO-8859-1 um (das ist eigenltich das Format, in dem du diese XML-Datei auslieferst), dann erscheinen einige Sekunden später komische Zeichen vor deinem XML-Dokument.

Ich bin in dieser Thematik nicht ganz drin, aber ich weiß, dass durch irgendwelche Zeichenkombinationen in Textdokumenten ein Zeichensatz mitgegeben werden kann und dass das gelegentlich bei XML-Dokumenten problematisch ist. Ich kann mich erinnern, ein solches Problem auch mal gehabt zu haben.

Schaltest du dann im Firefox bei Ansicht wieder auf die Zeichenkodierung UTF-8 zurück, verschwinden diese komischen Zeichen.

Also meine Diagnose :) Du schreibst, du würdest ein ISO-8859-1 Format ausliefern, in Wirklichkeit lieferst du UTF-8 aus. Bei deinem XML könntest du das entsprechend ändern auf encoding="UTF-8". Ich vermute, dass damit dein Problem allerdings nicht erledigt sein wird.

Du hast irgendwo an den Zeichensätzen rumgespielt. Das musst du wieder rückgängig machen.
 
Ich habe eigentlich nirgends rumgespielt. Das ist das eigenartige. Oder zumindest nicht bewusst.
Als Bearbeitungsprogramm nutze ich derzeit den Editor Microsoft Expression. Aber selbst die Dateien bei denen ich nichts seit langem geändert habe und die seit Monaten liefen, gibt es auf einmal Probleme.

Bei dem Fehler mit der XML: Ich habe auf UTF-8 geändert und nichts ist anders bei dem Fehler. Bei mir kommt dieselbe Fehlermeldung wie zuvor.

Ich selber bin bei Strato mit einem VServer.

Das zweite Problem mit dem Formular ist folgendes. Es gibt ein Formular für registrierte Tankstellen unter www.tankcheck.de/premium_mitglied.php

Dieses Formular ging bisher immer und trug nach absenden einfach nur ein paar Daten in die Datenbanktabelle ein und gab eine Meldung aus. Nun geht das einfach nicht mehr. Ich habe das Gefühl er will einfach nicht. Tabellenname, Spalten, etc. stimmen - habe ich verglichen. Alles auch noch wie vor einem halben Jahr, als es auch noch lief.
Datenbankverbindung steht auch, weil es ja zuvor die Abfrage anhand der Session gibt nach dem User um eine Meldung dazu anzuzeigen und das macht er entsprechend auch.


Leider kann ich auch nicht sagen ob es ggf. an dem Neuauflegen der Datenbank liegt vor einigen Tagen um das Problem zu beheben, dass er Umlaute als kleine Fragezeichen-Bildchen anzeigt.
Das hatte ich erst versucht zu beheben indem ich im Template entsprechend die Codierung austeste. Es gab keine Veränderung. Erst nach dem Einspielen des Backup der Datenbank, welches ich aber auch gemacht habe, als das Problem schon bestand, waren die Fragezeichen weg und dieses Problem war weg.
Erst danach fielen mir die beiden anderen Probleme auf.

Die iphone_get.php lief aufjedenfall noch vor wenigen Tagen, da ich da selber das App dazu genutzt habe und da ging es.



 
Also wenn ich dein Formular und deiner URL aufrufe (das ich nicht sehe :), dann erscheint bei mir in der allerobersten Zeile folgendes:

Webmaster || Weiterempfehlung || Impressum || Kontakt

Und genau diese Zeichen sehe ich auch am Anfang deines XML-Dokuments, wenn ich auf Zeichensatz ISO-8859-1 umstelle. Stelle ich im Firefox auf UTF-8 um, scheint es richtig auszusehen. Versuch es mal.

In deiner Seite ist relativ viel Javascript. Wenn dein Formular dadurch gesteuert wird, ist es kein Wunder, dass es nicht mehr läuft.

Ändere doch diesen Meta-Tag auch mal auf UTF-8 und schau mal, ob das hilft:
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
 
Also ich bin mir jetzt wirklich sehr sicher: Du lieferst utf-8 aus und schreibst, es wäre iso-8859-1.

Wenn dein Provider umgezogen ist, vielleicht haben die irgendwas geändert. Sprich deinen Provider doch mal ganz konkret darauf an, ob sie irgendwas an der Zeichencodierung auf utf-8 geändert haben.
 
Ich habe nun auch in den Meta-Tags der Seite auf UTF-8 umgestellt. Aber es ändert nichts an dem Formular-Fehler und nichts an dem XML-Fehler.
Beide sind noch da.

Kann es denn einen Zusammenhang mit der Datenbank geben nach meine obigen Erzählung zu meiner Datenbank?
Das eigenartige ist ja nur, dass sonst fast alle Formulare funktionieren, nur das eine nicht mehr. Und es da auch gar keine Daten hergibt, währenddessen bei der XML Datei klar zu sehen ist, dass hier die Daten aus der Datenbank ankommen.
premium_mitglied.php
CODE <?php
session_start();
include('global.php');
if(isset($step))
{
if(isset($bestaetigung) AND $step=='premium' AND isset($anzahl_tank))
{
   $zeit = time()+365*24*60*60;
   $insert  = "INSERT INTO premium_anmeldungen (premium_user_id, anzahl_tank, verband_mitglied, verband_nummer, premium_ende) VALUES ('".$_SESSION['sess_user_id']."', '".$anzahl_tank."', '".$verband_mitglied."', '".$verband_nummer."', '".$zeit."')";
$sql     = mysql_query($insert) or die(mysql_error());
if($verband_mitglied==0)
 { $betrag=34.95;
 }
 else
 { $betrag=10.90;
 }
   $rechnungssumme = $anzahl_tank*$betrag;
   $content = "<b>Vielen Dank für Ihre Anmeldung als Premium Mitglied. Bitte fügen Sie alle Ihre Tankstellen als Selbstmelder Ihrem Account unter <a href='http://tankcheck.de/selbstmelder.php'>Neue Tankstelle suchen</a> hinzu.<b> <br> Ihre Rechnung wird voraussichtlich ".$rechnungssumme." Euro betragen</b>";        
}
else
{
$content = "Bitte bestätigen Sie Ihre Mitgliedschaft mit dem Hacken und überprüfen Sie ob alle Felder mit * ausgefüllt sind!";
}
}
//
// Hier folgt eigentlich der ganze Text, aus Übersichtlichkeit mal rausgenommen
//
$content .= "<br><h2>Jetzt Premium Mitglied werden</h2><br>";
$query = "SELECT COUNT(*) FROM users WHERE user_session = '".session_id()."'";
$sql   = mysql_query($query);
$erg   = mysql_result($sql,0);

if($erg == 0)
{
 $content .= "<div class=head>".$lang['msg_kein_zugriff_premium']."</div>";
}
else
{
$query = "SELECT COUNT(*) FROM users WHERE user_session = '".session_id()."' AND user_premium = 1";
$sql   = mysql_query($query);
$erg   = mysql_result($sql,0);
if($erg == 0)
{
 $content .= '<form method=POST action="premium_mitglied.php">';
$content .= "Verbandsmitglied des Mitteldeutschen Tankstellen und Garagenverbandes e.V.:</td><td><select name=verband_mitglied>";
   $content .= "<option value='0' selected>Nein</option>";
   $content .= "<option value='1'>Ja</option>";
   $content .= "</select><br><br>";
   $content .= "ggf. Mitgliedsnummer: <input type='text' value='' name=verband_nummer size=15 maxlength=15><br><br>";
   $content .= "Anzahl Ihrer Tankstellen: * <input type='text' value='' name=anzahl_tank size=15 maxlength=15><br><br>";    
$content .= "<input type='checkbox' name='bestaetigung' value='1'>Hiermit akzeptiere ich die 1 Jahresmitgliedschaft als Premium Mitglied bei Tankcheck.de für 34,95 Euro pro Jahr und Tankstelle. Ich werde nach Erhalt der Rechnung den nötigen Betrag an Tankcheck.de überweisen und anschließend wird mit mein Account und meine Tankstellen auf Premium umgestellt. Innerhalb von 14 Tagen kann ich die Mitgliedschaft nach Erhalt der Rechnung widerrufen. Bei einer gleichzeitigen Mitgliedschaft beim Mitteldeutschen Tankstellen und Garagenverband e.V. erhalte ich die Mitgliedschaft für 10,90 Euro pro Jahr und Tankstelle. Diesen vergünstigten Preis erhalte ich nur, wenn ich die richtigen Daten zur Zusortierung meiner Mitgliedsschaftsnummer bereitstelle. Die Laufzeit beträgt 1 Jahr und kann dann erneut beantragt werden.<br><br>";
 $content .= '<input type=hidden name=step value=premium><input type=submit name=mail class=Button value="'.$lang['senden'].'">';
 $content .= '</form>';
 }
 else
 {
 $user_query  = "SELECT * FROM premium_anmeldungen WHERE premium_user_id = '".$_SESSION['sess_user_id']."' ";
 $user_sql    = mysql_query($user_query);
 $user        = mysql_fetch_object($user_sql);
 $enddatum = date("d.m.Y h:i:s", $user->premium_ende);
 $content .= "<div class=head>Sie sind bereits Premium Mitglied. Ihre Mitgliedschaft endet am ".$enddatum."</div>";
 }
}


// Klasse hinzuladen
include("template.class.php");
// Objekt erzeugen ($error wird bereits im Konstrukt definiert und ist hier nur optional)
$template = new template("template/home.html");
// Datei einlesen
$template->readtemplate();
$template->replace("title", $lang['premium_title']);
$template->replace("meta", $lang['premium_meta']);
include('footer.php');
?>


So hatte es bisher immer funktioniert. Nun geht die Seite damit nicht mehr.

Zeichen wie € wurden irgendwie vom Server in allen Dateien in € umgewandelt. Daher habe ich diese und alle Umlaute in den Dateien dann durch Unicode oder Euro ausgeschrieben ersetzt. Dachte erst, dass dies Probleme macht. Ist es nun aber nicht.
 
Ich habe nun neue Informationen:

Ich habe das Serverbackup vom 24.04. aufgespielt gehabt. Hier funktionierte noch die XML, hat aber in den Ergebnissen bei Tankcheck.de noch Umlaute falsch dargestellt und das Formular ging da auch schon nicht.
Habe demnach dort noch getestet auch hier auf UTF-8 in den Metas umzustellen und es ergab keine Änderung.

Also habe ich wieder auf das heutige System zurückgespielt. Also wo ich inzwischen die Datenbank neu eingespielt hatte und es dadurch wieder die Umlaute richtig dargestellt hatte. das Formular und die XML aber nicht funktionieren.
Habe daher aus dem alten Backup auch die dort korrekt funktionierende Datei für die XML kopiert und in das aktuellere System eingespielt. Aber hier geht es wieder nicht mehr.
Es kann also nicht an der Programmierung und dem Code liegen.

 
Meta-Tags sind relativ unzuverlässig dabei, am Besten die Informationen direkt über den HTTP-Header übertragen:

CODE header('Content-Type: text/html; charset=UTF-8');


Meta-Tags sind dabei meistens nur prophylaktisch, falls der HTTP-Header mal fehlen sollte.
 
Das ändert leider auch nichts an meinem Problem. Ich vermute es liegt u.a. an der Datenbank.

Konnte jemand von euch einen Fehler im Code oben finden? Ich sehe da keinen und vorher hatte es dachte ich mal funktioniert.
 
Folgende neue Erkenntnisse:

1) Ich habe erneut das Backup vom 24.05. eingespielt:
- iphone_get.php (XML-Ausgabe) ging
- Umlaute werden als Fragezeichen angezeigt auf Tankcheck.de
- Aussehen und Schriftgrößen stimmen

2) Ich habe eine Änderung gemacht: die header-Definition per php eingefügt, wie von Sascha erwähnt
- iphone_get.php geht nicht mehr

3) Die Zeile wieder rausgelöscht
- aber es bleibt bei dem vorherigen Ergebnis, ass iphone_get nicht mehr geht
- Schriftarten werden auf Tankcheck auf einmal größer angezeigt (deutet ja auchauf einen Fehler hin)
- Fragezeichen anstatt Umlaute bleiben

- Dateien sind als UTF-8 gespeichert
- Datenbank Kollation der Tabellen: latin1_swedish_ci
- Datenbank Kollation: utf8_general_ci
- Datenbank Verbindung laut MySQL: utf8_general_ci
- Speichere ich die index.php als iso-8859-1 ab, werden die dort angezeigten Umlaute im Text richtig angezeigt
- Beim Speichern der iphone_get.php als iso-8859-1 bleibt alles beim alten
- Ändern der meta Tags zu ISO oder UTF-8 verändern nichts in der Darstellung
- Formular bleibt in jeder Sache immer kaputt



 
Hallo Leute,

ich habe noch immer Probleme bei Tankcheck.de. Ich habe bereits alte aufjedenfall funktionstüchtige Seiten hochgeladen um die nicht mehr funktionierenden zu überschreiben. Doch die Probleme bleiben bestehen. Ich gehe daher davon aus, dass es nicht an den Dateien liegt.

1) tankcheck.de/register.php - im letzten Schritt folgt eine Bestätigung der Registrierung durch das Versenden einer E-Mail. Die Seite wird nicht geladen (Serverfehler 500). Den Datenbankeintrag nimmt es aber in dem Moment vor und jeder Nutzer dann bei der Fehlerseite dann die Seite neuladen will, wird in dem Moment doppel und soweiter eingetragen.

2) tankcheck.de/premium_mitglied.php - Das versenden als eingeloggter Selbstmelder der Anmeldung als Premium Tankstelle funktioniert nicht mehr. Es versendet einfach nicht mehr das Formular. EIn Datenbankeintrag findet nicht statt. Eine Fehlermeldung erscheint auch nicht. Er lädt einfach die selbe Seite noch einmal.

3) Darstellung - Schriften die eigentlich klein dargestellt werden (z.B: alle Ergebnistabellen oder die Beschriftung vor den Suchfeldern auf der Startseite) werden größer dargestellt und die blauen Layer werden nicht wie in der CSS beschrieben dargesellt. (was zuvor aber klappte) Die Mindesthöhe des Haupt-Layers ist immer mindestens so groß wie der Layer der linken Navigation laut CSS, was seit den Fehlern nicht mehr ist.
Die Darstellung ist im Firefox korrekt, im IE ist Sie wie beschrieben falsch

4) Es gab Probleme mit den Umlauten. Daraufhin habe ich erst einmal alle Header charseits entfernt und die Datenbank neu eingespielt, dabei dort alle in der SQL total unterschiedlichen Tabellen CHarset Festlegungen entfernt. Jetzt ist alles in der Datenbanktabelle UTF-8. Nun zeigt es wenigstens auf der Seite die Umlaute und Sonderlaute wie ß korrekt an.
Die Fehler 1 bis 3 bleiben aber erhalten.

5) iphone_get.php - http://www.tankcheck.de/lkkkkklkkkkk.php?q...7&r=10&k=1&l=DE - Schaut man sich jedoch den Quelltext nach dem Abruf an, sieht man, dass er alle Daten richtig aus der Datenbank zieht. Die Darstellung ist jedoch falsch. Früher ging das immer. Alle Kombinationen an UTF-8 und ISO-8859-1 habe ich bereits ausprobiert in dem charset und encoding der XML. KEines bringt eine Lösung.

Ich denke aber das die Fehler 1 bis 3 alle etwas mit der Codierung und Datenbank zu tun haben. Weil die Dateien an sich sind die, die mal funktioniert hatten.


Weitere Informationen:
Speicherung der Dateien als UTF-8
MySQL-Zeichensatz: UTF-8 Unicode (utf8)
Zeichensatz / Kollation der MySQL-Verbindung: utf8_general_ci
Kollation der Tabellen: utf8_general_ci
Kollation in den Tabellenspalten: utf8_general_ci
 
QUOTE (kekskruemel @ Mi 26.05.2010, 08:05)[...]
1) tankcheck.de/register.php - im letzten Schritt folgt eine Bestätigung der Registrierung durch das Versenden einer E-Mail. Die Seite wird nicht geladen (Serverfehler 500). Den Datenbankeintrag nimmt es aber in dem Moment vor und jeder Nutzer dann bei der Fehlerseite dann die Seite neuladen will, wird in dem Moment doppel und soweiter eingetragen.
[...]

  1. Designfehler: Doppelte Einträge müssten abgefangen werden, wenn das nicht mittel Unique in der Datenbank unterstützt wird, ist das Datenbankschema falsch. Fängt es die Programmierung nicht ab, ist diese auch Fehlerhaft.
  2. Serverfehler mit den Code 500 treten in der Regel auf, wenn der Server falsch konfiguriert ist, z.B. durch HTACCESS-Anweisungen oder dergleichen.
Zu beiden Fehlern fehlen hier mehr Informationen (Htacces-Datei / Datenbankschema / Programmcode)






QUOTE (kekskruemel @ Mi 26.05.2010, 08:05)[...]
2) tankcheck.de/premium_mitglied.php - Das versenden als eingeloggter Selbstmelder der Anmeldung als Premium Tankstelle funktioniert nicht mehr. Es versendet einfach nicht mehr das Formular. EIn Datenbankeintrag findet nicht statt. Eine Fehlermeldung erscheint auch nicht. Er lädt einfach die selbe Seite noch einmal.
[...]

Hier fehlen mehr Informationen. Hier wäre ein Blick auf den relevanten Programmcode wieder erforderlich.






QUOTE (kekskruemel @ Mi 26.05.2010, 08:05)[...]
3) Darstellung - Schriften die eigentlich klein dargestellt werden (z.B: alle Ergebnistabellen oder die Beschriftung vor den Suchfeldern auf der Startseite) werden größer dargestellt und die blauen Layer werden nicht wie in der CSS beschrieben dargesellt. (was zuvor aber klappte) Die Mindesthöhe des Haupt-Layers ist immer mindestens so groß wie der Layer der linken Navigation laut CSS, was seit den Fehlern nicht mehr ist.
Die Darstellung ist im Firefox korrekt, im IE ist Sie wie beschrieben falsch
[...]

Erster Schritt: HTML und CSS valdieren! Du scheinst schon am Anfang des Dokuments ein kodiertes Zeichen stehen zu haben. Danach wäre es hilfreich, zu wissen, in welchen Browser dieser Fehler auftaucht.






QUOTE (kekskruemel @ Mi 26.05.2010, 08:05)[...]
5) iphone_get.php - http://www.tankcheck.de/iphone_get.php?q=01217&r=10&k=1&l=DE - Schaut man sich jedoch den Quelltext nach dem Abruf an, sieht man, dass er alle Daten richtig aus der Datenbank zieht. Die Darstellung ist jedoch falsch. Früher ging das immer. Alle Kombinationen an UTF-8 und ISO-8859-1 habe ich bereits ausprobiert in dem charset und encoding der XML. KEines bringt eine Lösung.
[...]

Was ist das Problem? Du sagst nur, dass der Quelltext ist ok... Also wieso ist das Relevant?






QUOTE (kekskruemel @ Mi 26.05.2010, 08:05)[...] Ich denke aber das die Fehler 1 bis 3 alle etwas mit der Codierung und Datenbank zu tun haben. Weil die Dateien an sich sind die, die mal funktioniert hatten. [...]

Denke ich eher nicht. Ich habe nie 500er Fehler bei Kodierungsfehlern erhalten, noch sprechen die Phänomäne dafür.
 
QUOTE (Sascha Ahlers @ Mi 26.05.2010, 10:09)
QUOTE (kekskruemel @ Mi 26.05.2010, 08:05)[...]
1) tankcheck.de/register.php - im letzten Schritt folgt eine Bestätigung der Registrierung durch das Versenden einer E-Mail. Die Seite wird nicht geladen (Serverfehler 500). Den Datenbankeintrag nimmt es aber in dem Moment vor und jeder Nutzer dann bei der Fehlerseite dann die Seite neuladen will, wird in dem Moment doppel und soweiter eingetragen.
[...]

  1. Designfehler: Doppelte Einträge müssten abgefangen werden, wenn das nicht mittel Unique in der Datenbank unterstützt wird, ist das Datenbankschema falsch. Fängt es die Programmierung nicht ab, ist diese auch Fehlerhaft.


  2. Serverfehler mit den Code 500 treten in der Regel auf, wenn der Server falsch konfiguriert ist, z.B. durch HTACCESS-Anweisungen oder dergleichen.

Zu beiden Fehlern fehlen hier mehr Informationen (Htacces-Datei / Datenbankschema / Programmcode)






QUOTE (kekskruemel @ Mi 26.05.2010, 08:05)[...]
2) tankcheck.de/premium_mitglied.php - Das versenden als eingeloggter Selbstmelder der Anmeldung als Premium Tankstelle funktioniert nicht mehr. Es versendet einfach nicht mehr das Formular. EIn Datenbankeintrag findet nicht statt. Eine Fehlermeldung erscheint auch nicht. Er lädt einfach die selbe Seite noch einmal.
[...]

Hier fehlen mehr Informationen. Hier wäre ein Blick auf den relevanten Programmcode wieder erforderlich.






QUOTE (kekskruemel @ Mi 26.05.2010, 08:05)[...]
3) Darstellung - Schriften die eigentlich klein dargestellt werden (z.B: alle Ergebnistabellen oder die Beschriftung vor den Suchfeldern auf der Startseite) werden größer dargestellt und die blauen Layer werden nicht wie in der CSS beschrieben dargesellt. (was zuvor aber klappte) Die Mindesthöhe des Haupt-Layers ist immer mindestens so groß wie der Layer der linken Navigation laut CSS, was seit den Fehlern nicht mehr ist.
Die Darstellung ist im Firefox korrekt, im IE ist Sie wie beschrieben falsch
[...]

Erster Schritt: HTML und CSS valdieren! Du scheinst schon am Anfang des Dokuments ein kodiertes Zeichen stehen zu haben. Danach wäre es hilfreich, zu wissen, in welchen Browser dieser Fehler auftaucht.






QUOTE (kekskruemel @ Mi 26.05.2010, 08:05)[...]
5) iphone_get.php - http://www.tankcheck.de/iphone_get.php?q=01217&r=10&k=1&l=DE - Schaut man sich jedoch den Quelltext nach dem Abruf an, sieht man, dass er alle Daten richtig aus der Datenbank zieht. Die Darstellung ist jedoch falsch. Früher ging das immer. Alle Kombinationen an UTF-8 und ISO-8859-1 habe ich bereits ausprobiert in dem charset und encoding der XML. KEines bringt eine Lösung.
[...]

Was ist das Problem? Du sagst nur, dass der Quelltext ist ok... Also wieso ist das Relevant?






QUOTE (kekskruemel @ Mi 26.05.2010, 08:05)[...] Ich denke aber das die Fehler 1 bis 3 alle etwas mit der Codierung und Datenbank zu tun haben. Weil die Dateien an sich sind die, die mal funktioniert hatten. [...]

Denke ich eher nicht. Ich habe nie 500er Fehler bei Kodierungsfehlern erhalten, noch sprechen die Phänomäne dafür.

1) und 2)
Register.php:
Ich habe in der Datenbank ein Unique über den Usernamen eben gelegt. Stimmt, da war keines.

CODE CREATE TABLE `users` (
 `user_id` int(10) NOT NULL auto_increment,
 `user_login` varchar(20) NOT NULL default '',
 `user_pass` varchar(50) NOT NULL default '',
 `user_name` varchar(30) NOT NULL default '',
 `user_vorname` varchar(30) NOT NULL default '',
 `user_str` varchar(35) NOT NULL default '',
 `user_ort` varchar(35) NOT NULL default '',
 `user_plz` varchar(7) NOT NULL default '',
 `user_land` varchar(4) NOT NULL default 'DE',
 `user_lang` char(2) NOT NULL default 'DE',
 `user_email` varchar(50) NOT NULL default '',
 `user_email_show` smallint(1) NOT NULL default '0',
 `user_pic` varchar(25) NOT NULL default '',
 `user_register` int(15) NOT NULL default '0',
 `user_update` int(15) NOT NULL default '0',
 `user_aktivcode` varchar(20) NOT NULL default '',
 `user_session` varchar(32) default NULL,
 `user_status` int(1) NOT NULL default '0',
 `user_level` int(1) NOT NULL default '0',
 `user_watch` varchar(120) NOT NULL default '',
 `user_blitzer` int(5) NOT NULL default '0',
 `user_tank` int(5) NOT NULL default '0',
 `user_tankstelle` int(5) NOT NULL default '0',
 `user_werben` char(3) NOT NULL default '0',
 `user_werben_by` varchar(20) NOT NULL default '',
 `user_news` int(2) NOT NULL default '0',
 `user_pm` int(4) NOT NULL default '100',
 `user_pm_ignore` varchar(120) NOT NULL default '',
 `user_last_pm` int(15) NOT NULL default '0',
 `user_pm_get` int(2) NOT NULL default '1',
 `user_pm_mail` int(2) NOT NULL default '1',
 `user_premium` int(1) NOT NULL default '0',
 PRIMARY KEY  (`user_id`),
 UNIQUE KEY `user_login` (`user_login`)
) ENGINE=MyISAM AUTO_INCREMENT=544 DEFAULT CHARSET=utf8 PACK_KEYS=0 AUTO_INCREMENT=544;



Eine htaccess existiert bei mir nicht.
HTTP 500 Internet Serverfehler kommt immer noch.
Der php-Code der Seite ist recht lang. Alle relevanten Dateien stelle ich als Zip zur Verfügung:
www.tankcheck.de/error.zip

3)
Beim Validieren zeigt er mir den Fehler:
Line 1, Column 1: character "" not allowed in prolog
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"

Wie bereits geschrieben ist die Darstellung im Firefox richtig, im IE ist sie falsch (zu große Schrift, mittlerer Layer zu kurz bzw. immer entsprechend des Inhalts, ist aber mit einer Mindesthöhe versehen, die nicht eingehalten wird im IE)
Alles wurde aber mal richtig angezeigt, als ich bei den Fehlerbehebeversuchen vor 2 Wochen die DB neu aufgesetzt hatte. Habe ich dann eine Datei zum Bearbeiten geöffnet, nichts dran gemacht und abgespeichert, war im IE immer alles wieder mit dieser falschen Darstellung.


5) Ich meinte, dass die Datei noch vor dem Neuaufspielen der Datenbank funktioniert hatte. Seit dem habe ich an dem Quelltext aber nichts geändert. Er sollte also funktionieren. Zudem zieht er die Daten richtig aus der Datenbank (wenn man sich im IE oder Firefox den Quellcode anschaut, sieht man, dass er die Tankstellen rausgezogen hat) - aber die Codierung scheint falsch zu sein.
XML-Meldung:

Ungültig auf der obersten Ebene im Dokument. Fehler beim Bearbeiten der Ressource 'http://www.tankcheck.de/iphone_get.php?q...

<?xml version="1.0" encoding="UTF-8"?><result xmlns="http://tankcheck.de/iphone_get.php" xmlns:xsi="http://www....

Ich brauche die Ausgabe für ein IPhone App- bzw. dazu wurde das seit einigen Monaten genutzt. Nun ist dieser Fehler da und daher kann der XML Parser im iPhone das nicht intepretieren

Generell ist es so, dass alle dieser Seiten zuvor einmal funktioniert hatten. Inzwischen aber nicht mehr, obwohl nichts am Quelltext verändert wurde.
 
QUOTE (kekskruemel @ Mi 26.05.2010, 10:42) [...]
3)
Beim Validieren zeigt er mir den Fehler:
Line 1, Column 1: character "" not allowed in prolog
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"

Wie bereits geschrieben ist die Darstellung im Firefox richtig, im IE ist sie falsch (zu große Schrift, mittlerer Layer zu kurz bzw. immer entsprechend des Inhalts, ist aber mit einer Mindesthöhe versehen, die nicht eingehalten wird im IE)
Alles wurde aber mal richtig angezeigt, als ich bei den Fehlerbehebeversuchen vor 2 Wochen die DB neu aufgesetzt hatte. Habe ich dann eine Datei zum Bearbeiten geöffnet, nichts dran gemacht und abgespeichert, war im IE immer alles wieder mit dieser falschen Darstellung.
[...]

Ich würde da mal auf den Quirks Mode tippen beim MSIE, stell den doch mal aus, indem Du den Doctype entsprechend abänderst. Und versuch nach Möglichkeit auch das Steuerzeichen vor dem DOCTYPE verzubekommen, den der Validator meldet, irgendwas muss da noch ausgegeben werden, was da so wohl nicht hingehört.


CODE <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
 
Das hat keine Änderung gebracht.

Ich habe u.a. eben mal ein Backup von August 2009 in Tankcheck.de/tankcheck/ eingespielt.

Unterschied:
Die eine Version wird in ISO angezeigt, die andere in UTF-8, durch die letzten Tipps.
Aber:
Selbst unter Nutzung der August Version, die damals rundum funktionstüchtig war, funktionieren die sachen nicht mehr.

Der Fehler des W3C Validator ist z.B. auch in der alten Version nicht vorhanden, kopiere ich aber selbige Datei in die andere Version: ist der Fehler wieder da.

Funktioniert in der einen Version die iphone_get.php - funktioniert sie aber nur so lange wie ich nicht eine der Dateien, die teilweise mit dieser gar nichts zu tun haben, öffne und unverändert oder verändert wieder abspeichere. DAnn geht sie wieder nicht mehr.
 
Das Problem erinnert mich an ein Problem, das ich mal mit Drupal hatte, als ich - eigentlich eher nebenbei - für einen Kunden eine Drupal-Einbindung gebaut hatte:

Da hat sich schließlich rausgestellt, daß das Modul ein UTF-8 - BOM (Byte-Order-Mark) hatte.

Wenn solche Dateien von irgendeiner Rahmenarchitektur (in dem Fall Drupal) eingelesen werden, dann kann das BOM dazu führen, daß es eine Fehlermeldung gibt (sinngemäß: Ungültiges Zeichen im PHP-Code), diese Fehlermeldung wird aber unterdrückt - und es kann bsp. einen 500 zum Zeitpunkt des Einlesens dieser Datei geben.

Konkret erschien da immer nach einer Änderung bei den Modulen eine weiße, leere Seite.


Andere Variante: Die Ausgabe enthält nicht als erste Zeichen den DOCTYPE - also ist das Dokument nicht valide, also wechselt der IE in den Quirks. Ein gültiges Xml-Dokument ist das damit auch nicht, also crasht das gesamte Xml-Handling.

Es könnte sein, daß entweder der Provider Headerinformationen geändert hat oder daß eine neuere PHP-Version ein solches Handling beim Include von Dateien anders handelt - und es deshalb Probleme gibt.

Oder es gibt in einer einzigen Datei ein BOM :)

PS: Oben steht das doch:

QUOTE (tompop @ Di 4.05.2010, 17:22)Also wenn ich dein Formular und deiner URL aufrufe (das ich nicht sehe :), dann erscheint bei mir in der allerobersten Zeile folgendes:

Webmaster || Weiterempfehlung || Impressum || Kontakt


Da steht nicht ein BOM drin, sondern gleich eine ganze Kleinlasterladung davon :)
 
QUOTE (kekskruemel @ Mi 26.05.2010, 10:42) [...]

Eine htaccess existiert bei mir nicht.
HTTP 500 Internet Serverfehler kommt immer noch.
Der php-Code der Seite ist recht lang. Alle relevanten Dateien stelle ich als Zip zur Verfügung:
www.tankcheck.de/error.zip

[...]

Problem behoben?


QUOTE Objekt nicht gefunden!

Der angeforderte URL konnte auf dem Server nicht gefunden werden. Sofern Sie den URL manuell eingegeben haben, überprüfen Sie bitte die Schreibweise und versuchen Sie es erneut.

Sofern Sie dies für eine Fehlfunktion des Servers halten, informieren Sie bitte den Webmaster hierüber.
Error 404
www.tankcheck.de
Sat May 29 08:26:35 2010
Apache/2.2.10 (Linux/SUSE)
 
Sie müssen sich einloggen oder registrieren, um hier antworten zu können.
Zurück
Oben