Parameter mit Umlaut liefert aus verschiedenen Seiten heraus unterschiedliche Ergebnisse
Andreas Nagel
- html
Hallo zusammen,
auf meinen nur lokalen Seiten sollen Links aus verschiedenen Punkten heraus Seiten mit einem Parameter in einem iframe öffnen, wofür auch teilweise Umlaute benötigt werden. Und dabei handelt es sich um Links die durch das Erstellen einer sqlite Datenbank heraus erstellt wurden und weitere die aus einem php Abschnitt auf einer Seite in dem iframe heraus aufgerufen werden: <a link='$Datei?".urlencode("$Parameter")."'>....</a>
Denn der Parameter wird dafür verwendet, Daten zu übergeben um damit eine Abfrage auslösen zu können. Doch enthält dieser Umlaute, liefert dieser je nach dem aus welcher Seite heraus ich diesen Parameter aufrufe unterschiedliche Ergebnisse, so dass php auf der aufzurufenden Seite entweder eine Abfrage ausführt oder eine Fehlermeldung ausgibt. Es solle also die Tabelle mit Umlaut nicht existieren und auch ein Kuddelmuddel an Zeichen liefert.
Wieso ist das so, da ja auf allen Seiten die Umlaute korrekt dargestellt werden und es egal ist welche Zeichenkodierung ich anwende? Wobei ich es wohl noch nicht hinbekommen hatte mit utf-8 kodieren zu können.
Und so würde ich für jede Hilfe bereits jetzt bei Euch bedanken und würde mich auch über jede positive Hilfe sehr freuen.
Also schonmal Vielen Dank und Gruß
Andreas
Hallo,
auf meinen nur lokalen Seiten sollen Links aus verschiedenen Punkten heraus Seiten mit einem Parameter in einem iframe öffnen, wofür auch teilweise Umlaute benötigt werden. Und dabei handelt es sich um Links die durch das Erstellen einer sqlite Datenbank heraus erstellt wurden und weitere die aus einem php Abschnitt auf einer Seite in dem iframe heraus aufgerufen werden:
<a link='$Datei?".urlencode("$Parameter")."'>....</a>
dann schau dir die generierten Links doch mal genau an. Der Umlaut muss ja, da er in URLs nicht unmaskiert vorkommen darf, in jedem Fall Prozent-codiert sein. Siehst du nur ein Prozent-codiertes Byte, verwendet die Quelle, aus der die Daten stammen, wohl eine 1-Byte Codierung (z.B. ISO-8859-x oder Windows-1252); siehst du dagegen zwei Prozent-codierte Bytes für den Umlaut, war die Quelle wohl schon in UTF-8 codiert.
Wenn du also je nach Quelle tatsächlich unterschiedliche Codierungen hast, solltest du genau da ansetzen und das vereinheitlichen.
Wieso ist das so, da ja auf allen Seiten die Umlaute korrekt dargestellt werden und es egal ist welche Zeichenkodierung ich anwende?
Was meinst du mit "es ist egal"? Es ist mit an Sicherheit grenzender Wahrscheinlichkeit nicht egal.
Wobei ich es wohl noch nicht hinbekommen hatte mit utf-8 kodieren zu können.
Wieso nicht??
So long,
Martin
Jo Hallo,
doch wie gesagt sitzt auf jeder Seite die gleiche meta Zeile um die Kodierung anzugeben, was ja auf den Seiten funktioniert. Und als Quelle soll ich dann auch die sqlite Datenbank verstehen? Und wie bekomme ich da die Kodierung heraus? Denn in dem Tool das ich mal installiert hate will ich davon nichts finden. Ich konnte mich halt mal mit jemanden auf sqlite einigen. so dass es dabei bleiben sollte. Und bei utf-8 bekam ich bisher nur Fehlermeldungen, wie zb. einer Zeile im php Code drin oder es geschah überhaupt nix.
OK also auf jeden Fall Vielen Dank und Grüße
Andreas
Hi,
doch wie gesagt sitzt auf jeder Seite die gleiche meta Zeile um die Kodierung anzugeben
ich habe nicht nach dem Aufkleber der Dose gefragt, sondern nach dem Inhalt. Die meta-Angabe ist ja nur eine Information an den Browser, in welcher Codierung denn das Dokument verfasst ist - die kann richtig sein oder auch nicht. Abgesehen davon, dass sie vermutlich gar nicht zum Tragen kommt, weil der Server im HTTP-Header schon eine Codierung angibt, und diese Angabe hat Vorrang.
Und als Quelle soll ich dann auch die sqlite Datenbank verstehen?
Zum Beispiel. Oder wo die Daten sonst so herkommen.
Und wie bekomme ich da die Kodierung heraus?
Im Zweifelsfall durch Analysieren. Eine Möglichkeit habe ich dir genannt: Wenn Umlaute als zwei Bytes codiert sind, ist es mit ziemlicher Sicherheit UTF-8, sonst nicht.
Denn in dem Tool das ich mal installiert hate will ich davon nichts finden. Ich konnte mich halt mal mit jemanden auf sqlite einigen. so dass es dabei bleiben sollte. Und bei utf-8 bekam ich bisher nur Fehlermeldungen, wie zb. einer Zeile im php Code drin oder es geschah überhaupt nix.
Das sind aber alles nur Wischiwaschi-Aussagen, die uns nicht weiterbringen. Was für ein Tool? Was für eine Fehlermeldung? Wie sah die fehlerhafte Ausgabe aus? Dass "überhaupt nix" passiert ist, kann auch nicht sein.
So long,
Martin
OK dann nochmals Hallo,
mit dem Versuch etwas mehr Auskunft geben zu können:
Denn zu Anfang jeder Seite steht:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-15">
<html>
<head>
und das Ergebnis sieht in der aufgerufenen Datei so aus:
Table 'sonstiges.geschã¤fte und einkaufen' doesn't exist
OK also dann schonal Vielen Dank im Vorraus und mit Hoffnung auf Erfolg, da ich jetzt nicht mehr wüsste Dir zeigen zu können.
Gruß Andreas
n'Abend,
Denn zu Anfang jeder Seite steht:
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-15">
sagte ich nicht, dass das völlig irrelevant ist? Wichtig ist a) welche Codierung du wirklich verwendest, und b) welche der Server im HTTP-Header angibt. Nur wenn er gar keine Angabe zur Codierung macht, ist die obige Angabe überhaupt relevant. Und wichtig ist dann: Stimmt sie mit der tatsächlich verwendeten Codierung überein?
und das Ergebnis sieht in der aufgerufenen Datei so aus:
Table 'sonstiges.geschã¤fte und einkaufen' doesn't exist
Da läuft irgendwas doppelt schief. Das sieht aus, als ob UTF-8-codierte Daten als ISO-8859-x interpretiert und dann wieder in UTF-8 konvertiert wurden.
OK also dann schonal Vielen Dank im Vorraus
Kein Grrund, willkürrlich Konsonanten zu verrdoppeln.
und mit Hoffnung auf Erfolg, da ich jetzt nicht mehr wüsste Dir zeigen zu können.
Die vorliegende Codierung der Ursprunsdaten, und die Verarbeitungskette. Klar ist aus den bisherigen Informationen nur, dass es an mehreren Stellen gleichzeitig schiefgeht.
Ciao,
Martin
@@Andreas Nagel
<!DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/html4/loose.dtd">
Die Angabe ist falsch. Der public identifier '-//W3C//DTD XHTML 1.0 Strict//EN
' sagt XHTML 1.0 Strict; der system identifier 'http://www.w3.org/TR/html4/loose.dtd
' steht für HTML 4.01 Transitional. Das passt nicht zusammen. (Bei XHTML 1.0 muss außerdem 'html
' kleingeschrieben sein.)
Die Angabe ist unsinnig. Verwende den HTML5-DOCTYPE '<!DOCTYPE html>
'.
LLAP 🖖
Table 'sonstiges.geschã¤fte und einkaufen' doesn't exist
Na sieht doch immerhin schon fast so aus wie utf8. Nur der Browser zeigt einzelne bytes. Aber: Wenn das ein ä sein soll, müssten dafür die Oktetten C3 A4 erscheinen.
Dein Browser jedoch zeigt 4 Oktetten. Die Frage ist, was erwartest Du an. og. Position? Und wie lautet der Name der real existierenden Tabelle?
@@Der Martin
Abgesehen davon, dass sie vermutlich gar nicht zum Tragen kommt, weil der Server im HTTP-Header schon eine Codierung angibt, und diese Angabe hat Vorrang.
Gegenüber der Pragma-Direktive (meta
-Angabe), ja. Was nicht heißt, dass diese Angabe unbedingt zum Tragen kommt. Wenn die Ressource mit einem BOM[1] beginnt, dann hat dieses Vorrang. [qa-html-encoding-declarations] (Nur der Vollständigkeit halber.)
LLAP 🖖
oder welchen Geschlechts das BOM bei dir auch sein mag ;-) ↩︎
Tach!
Und als Quelle soll ich dann auch die sqlite Datenbank verstehen? Und wie bekomme ich da die Kodierung heraus?
SQLite arbeitet kodierungs-agnostisch. Das heißt, es weiß gar nicht, was eine Kodierung ist. Die Daten steckst du in einer bestimmten Kodierung rein und so kommen sie auch wieder raus. Dieselbe Kodierung musst du auch bei Vergleichen (z.B. im WHERE) verwenden, sonst stimmen die Daten in den Tabellen nicht mit dem Stringliteral in der Query überein.
dedlfix.
Hallo
> <a link='$Datei?".urlencode("$Parameter")."'>....</a>
… enthält dieser Umlaute, liefert dieser je nach dem aus welcher Seite heraus ich diesen Parameter aufrufe unterschiedliche Ergebnisse, …
Wieso ist das so, da ja auf allen Seiten die Umlaute korrekt dargestellt werden und es egal ist welche Zeichenkodierung ich anwende?
Du benutzt die Funktion eventuell falsch. urlencode ist dazu da, den Querystring, der an einer URL hängen kann, zu maskieren. So weit, so gut. Wenn du aber, was wir hier nicht wissen können, in der Variable $Parameter
mehrere Parameter vereint haben solltest und dann urlencode
auf diesen String anwendest, werden auch die Trennzeichen zwischen den einzelnen Parametern kodiert. Sieh dir dazu auch die Beispiele auf der von mir verlinkten Handbuchseite zu urlencode
an. Dort siehst du, dass nur die Werte und nicht die Trennzeichen und Parameternamen maskiert werden. Lies bitte auch den auf die Beispiele Abschnitt „Anmerkungen“.
Tschö, Auge
Jo Hallo,
es ist so dass ich in den Links den Link nicht in href schreibe, sondern in den Parameter Link. Denn das Ganze wird nochmals für eine Funktion zur Verfügung gestellt, die diesen dann bei onclick auslesen wird und damit noch weitere Parameter übergeben kann. Und es ist egal ob ich nun die Variable $Parameter verwende oder direkt den ganzen Text reinschreibe um ihn zu verschlüsseln. Und die ganzen Parameter werden auch durch ein & Zeichen getrennt, was von der Empfängerseite auch so erkannt wird.
OK also dann auf jeden Fall vielen Dank und Gruß
Andreas
Lieber Andreas,
wenn Du nicht nur erzählst, was Du vor hast, sondern auch zeigst (PHP-Code-Ausschnitte), was genau(!) Du tust (was steckt in $Parameter
, was in $Datei
?), dann kann man Dir vielleicht helfen.
Liebe Grüße,
Felix Riesterer.