Du hast wahrscheinlich 1x Speicherung, dann 1x Abfrage in anderem Encoding und wieder 1x Anzeige in einem anderen…deswegen wird das schwer sein zu bestimmen, wo genau eine Korrektur zu erfolgen hat
Kannst Du uns mal zB. eine Seite nennen, die die Webapp anzeigt (falls vorhanden), oder sonst wie Zugang zu den Inhalten geben? Was für ein Encoding wird für die Datenbank benutzt bzw. für die Tabellen?
Wir verwenden standardmäßig immer UTF-8, überall. Von daher wird wohl von den Scripten oder bei der Erstellung irgendwo UTF-8 überschrieben worden sein.
…das mag sein, jedoch beherrschen ja alle genannten “Umlaute”, die Frage die sich hier stellt ist nach welchem Standard sie gespeichert/angezeigt werden.
Moin ! Ich speichere bestimmte texte ganz normal mit dem Input Befehl in der Daten Bank und wenn da Umlaute im Text waren, war es bis her kein Problem. Rufe ich nun die Datenbank ab, werden die Umlaute nur noch als “?” dargestellt. Auch in der App selbst, war es bisher kein Problem, Button mit Umlauten zu schreiben wie zb:
Die Button wurde bisher immer mit den Umlauten richtig dargestellt. Jetzt muß ich die Umlaute konventieren ( ü ).
Ich habe aber her raus gefunden, wenn ich beim Abruf der Datenbank folgenden Befehl hin zu gebe :
mysql_query(“SET NAMES ‘utf8’”);
mysql_query(“SET CHARACTER SET ‘utf8’”);
Dann werden auch wieder die Umlaute dargestellt. Ist ja Super ! Aber das bedeutet nun für mich, das ich den ganzen Mist in sämtlichen Programm Dateien nun ändern darf. Das Bedeutet viel Zeit und Arbeit,
… gibt es noch eine andere ( einfache ) Lösungen mit den Umlauten ? ehrlich gesagt, kotzt es mich grad richtig an mit diesen update auf 5.6 . Hat doch vorher alles super gelaufen. Meine ganzen Datenbanken kommen durch einander.
Es kann doch nicht sein, das mich es nur alleine ärgert. Was für eine arbeit, die ganzen Programme um zu ändern
Dir ist klar, dass Du es “von Anfang an” nicht richtig gemacht hast und nun deswegen so etwas passiert…?
Von 5.5 auf 5.6 ist hier ein vergleichsweise kleiner Schritt, wir führen demnächst auch PHP 7 ein, da wird noch mehr veraltetes abgeschafft.
Schaue bitte ob Du einfach beim Anzeigen, also bei der App, auf zB. ISO-8859-1 umstellen kannst, falls Du da kein UTF8 benutzt hast. Sonst reicht es bei den Verbindungseinstellungen zu zB. MySQL eben wie bereits getan auf UTF8 umzustellen, das reicht da einmalig beim Verbindungsaufau.
Allerdings nutzt Du offensichtlich noch immer mysql_query, was auch bei 5.5 schon als veraltet markiert war und vor dessen Einsatz ausdrücklich gewarnt wird - es wird sogar in 7 abgeschafft. Benutze bitte mysqli oder am allerbesten: PDO - siehe zB. hier: https://www.w3schools.com/php/php_mysql_connect.asp
Wie ich schon sagte, ich bin absoluter Neuling, was programmieren an geht und wenn meine Webapp bisher funktioniert hat, woher soll ich wissen das ich es falsch gemacht habe ? Was ist den nun wieder mysqli bzw PDO. Das würde ja bedeuten, ich müsste alles umschreiben, bzw. fange wieder bei 0 an. Dann müsste ja, jeder der eine Webapp mit PHP 5.5 geschrieben hat Probleme haben bzw. alles neu schreiben. Und wenn ich PHP 5.5 habe, wieso funktionieren dann die Befehle einer neueren Vision ( PHP 7.0 ) in einer älteren Vision. Viele, viele Fragen kommen auf einmal auf. In welchem Zeitraum, soll den die Umstellung auf PHP 7 erfolgen. Bisher scheint es mit den Beide Befehlen :
mysql_query(“SET NAMES ‘utf8’”);
mysql_query(“SET CHARACTER SET ‘utf8’”);
bei mir zu funktionieren.
Aber wie würden den zB. die Befehle bei mysqli oder PDO aus sehnen.
Bisher sieht meine Programmierung so aus :
$verbindung = mysql_connect("$horst","$user3","$passwort") or die (“Fehler im System”);
mysql_select_db("$user3") or die (“nicht verbunden”);
$abfrage = (“SELECT * From benutzer WHERE ID = ‘1’”);
$ergebnis = mysql_query($abfrage);
while($row = mysql_fetch_object($ergebnis)) …
{
$schicht = $row->Schicht;
$strecke = $row->Strecke;
}
oder als beispiel so :
mysql_query(“UPDATE benutzer SET Status = ‘$status’ WHERE Nachname = ‘$user2’”);
Na, keine Sorge. Die meisten Funktionen der mysqli API heißen analog gleich, mysql_query wird etwa zu mysqli_query (http://php.net/manual/de/mysqli.query.php). Wenn du minimalen Arbeitsaufwand willst, kannst du mysqli auch prozedural verwenden, dann solltest du nicht viel ändern müssen. Der einzige Unterschied ist, dass du bei vielen Funktionen als zusätzlichen Parameter die Ressource übergeben musst (das was mysqli_connect zurückgibt).
Ich würde dir stattdessen aber wirklich empfehlen, dich mal zwei, drei Stunden hinzusetzen und mit einem Tutorial deines Vertrauens das Ganze mit PDO durchzumachen. Ich weiß, das nervt, aber Neuerungen gehören leider dazu. Wenn du z.B. http://php.net/manual/de/function.mysql-query.php anschaust, da steht ja bereits “wurde entfernt”. PHP7 gibt es ja schon, es ist nur eine Frage der Zeit bis es flächendeckend kommt. Doof stellen hilft bei Programmiersprachen erfahrungsgemäß leider eher weniger ;D
Das ist übrigens einer der Gründe, warum die meisten Softwareentwicklungsansätze Datenbanklogik von Programmlogik trennen. Dann muss man in so einem Fall nur fix die Datenbankfunktionen austauschen, und nicht “die ganzen Programme umändern”.
Eigentlich ist da eher der Grund dafuer das niemand plain/legacy php nimmt und direkt OOP lernt…dann hat man die probleme mit dem ganzen legacy rotz auch nicht.
Na das halte ich eher für ein Gerücht. Es geht bei Design Patterns doch nicht nur um veralteten Code. Ich betreibe mehrere Seiten mit prozeduralem PHP-Code. Keine davon hat veralteten Code.
Ich halte das eher weniger fuer ein Geruecht. Ich selbst betreibe 2 grosse Projekte und verwende entsprechende Frameworks. Auch wenn wir diese Diskussion woanders fortfuehren sollten (befinden uns hier schliesslich im Support), moechte ich dennoch die Frage an dich richten was du unter prozeduralem PHP-Code verstehst, bzw was deines erachtens nach der Vorteil gegenueber OOP ist.
Design patterns haben nichts mit veraltetem code zutun, design patterns existieren um maintainability, testing und usability zu garantieren/vereinfachen.
Meine persoenliche Meinung zu der Thematik ist, dass OOP immer einer procedural solution vorzuziehen ist. Der Hauptgrund dafuer ist ganz klar maintainability. Bei einem Top-Down design zieht sich die ganze Struktur bis unten durch, musst du das main procedure aendern, ziehen sich die Aenderungen nicht von alleine bis unten durch und du verbringst mehr Zeit damit eine regression zu fixen als neue Probleme zu loesen.
Zum Abschluss, ich bin immer fuer Diskussionen bzgl derartiger Thematiken zu haben, also falls deinerseits ebenfalls interesse besteht, koennen wir gerne irgendwo einen Offtopic thread aufmachen
