Ergebnis 1 bis 16 von 16

Thema: Mal ne Frage zum HTML-Zeichensatz

  1. #1
    Janmaat
    Gast

    Frage Mal ne Frage zum HTML-Zeichensatz

    Ich hab in meiner Datenbank nachgeschaut, dort steht überall UTF-8, wenn ich im ACP bei den installierten Sprachen nachschaue, steht dort aber ISO-8859-1. Müsste das nicht eigentlich beides gleich sein, also beide entweder UTF-8 oder ISO-8859-1?
    Wobei ich keinerlei Probleme habe mit Umlauten etc.?

    Kann mir da vielleicht jemand auf die Sprünge helfen?

  2. #2
    vBulletin-Germany Team Avatar von Mystics
    Registriert seit
    01.11.2001
    Alter
    37
    Beiträge
    27.471
    Nein, das muss nicht zwangsläufig identisch sein. Wenn du den Zeichensatz nun auf UTF-8 stellst, wirst du nicht sehr viel Freude haben, da dann alle Umlaute im Forum falsch angezeigt werden

    Daher: Wenn alles funktioniert - nichts ändern.

  3. #3
    vB-Experte
    Registriert seit
    30.05.2006
    Beiträge
    643
    Blog-Einträge
    3
    Zitat Zitat von Mystics Beitrag anzeigen
    Nein, das muss nicht zwangsläufig identisch sein. Wenn du den Zeichensatz nun auf UTF-8 stellst, wirst du nicht sehr viel Freude haben, da dann alle Umlaute im Forum falsch angezeigt werden

    Daher: Wenn alles funktioniert - nichts ändern.
    das sollte man in fett schreiben

    ein paar technische anmerkungen, weil das thema wirklich wahnsinnig kompliziert aber zugleich auch kindereinfach ist:

    vbulletin ist noch nicht zu 100% unicode-kompatibel. das hat viel damit zu tun, dass es vbulletin seit 1999 gibt und dort noch nicht die gleichen maßstäbe angesetzt werden konnten, wie sie heute in webanwendungen allgemein gelten.

    heute würde man in einer modernen webanwendung von anfang an seine datenbank auf utf-8 einstellen und den html-zeichensatz ebenso. damit beide systeme (datenbank und ausgabe) auch wirklich kompatibel zueinander arbeiten, muss der html-zeichensatz der datenbank bekannt gemacht werden, damit auf dem weg zur ausgabe keine automatische konvertierung erfolgt. das gehört heute beinahe zum grundwissen eines jeden webentwicklers.

    leider ist es in vbulletin derzeit nicht möglich, einfach so nach belieben den zeichensatz sowohl der ausgabe als auch der datenbank zu ändern.

    dazu muss man folgendes wissen:

    der html-zeichensatz ist nicht allein für die ausgabe der daten zuständig, sondern teilt auch dem browser mit, dass alle eingaben in formularen in diesem zeichensatz zu kodieren sind.

    hat man beispielsweise den zeichensatz auf utf-8 gesetzt, werden beiträge in utf-8 kodiert an den server geschickt, der sie dann genauso in der datenbank speichert (naja, bis auf die änderungen, die vbulletin da unterwegs noch veranstaltet).

    ist die datenbank und die entsprechende tabelle/spalte auf latin1 eingestellt, wird bei der eingabe von 'üäöß' nicht etwa 'üäöß' gespeichert, sondern als 'üäöß'. so sehen diese zeichen aus, die ursprünglich als utf-8 losgeschickt, aber in der db zwangsläufig umgewandelt werden nach latin1.

    Janmaat, bei deiner konstruktion ist es etwas komplizierter:

    du hast vermutlich nichts weiter gemacht, als eine datenbank anzulegen und hast vbulletin installiert. beim anlegen der tabellen wird berücksichtigt, wie der zeichensatz der datenbank selber ist. also hast du utf-8 tabellen/spalten.

    der html-zeichensatz ist allerdings per default latin1.

    das vbulletin speichert ab diesem moment alle zeichen als latin1 in unicode-tabellen. das ist eigentlich völliger quatsch, lässt sich aber so nicht mehr allgemeingültig ändern - zumal auch vbulletin utf-8 nicht offiziell unterstützt.

    würdest du jetzt zu diesem zeitpunkt den html-zeichensatz ändern und den mysql-zeichensatz per vbulletin-config - hast du mit dem forum keinen spass mehr! denn alles was vorher in der db gespeichert wurde, wird dir falsch angezeigt. alles was neu ist, funktioniert genauso wie es sein soll.

    zudem kommt hinzu, dass du ganz andere probleme bekommst, denn es gibt ja auch noch den daten-cache, der dann mit umstellung plötzlich datenmüll produziert und das forum unbrauchbar macht.

    es wurde ja bereits angekündigt: irgendwann in zukunft wird das problem in vbulletin behoben. vor einigen monaten hiess es noch, dass bei der entwicklung von vbulletin 4 für die notwendigen änderungen 3 monate eingeplant seien. das thema ist mittlerweile komplett vom tisch. vermutlich wird das in vbulletin 5 oder 6 möglich sein. denn es ist nicht nur eine frage der programmierung, sondern auch: was macht man mit installationen wie deiner? hier müssen konvertierungen erfolgen. bei einem forum mit mehr als 1 million beiträge kann dies zu einem grösseren projekt werden. das ist mit einem vbulletin-update nicht zu lösen.

    bei dir wird alles korrekt ausgegeben (weil mysql das regelt) und du solltest das unbedingt so lassen wie es ist. ich bin ziemlich sicher, dass es irgendwann eine lösung geben wird. es gibt zwar auch einen konverter als add-on, aber ohne not würde ich davon keinen gebrauch machen!

    kurzum, in vbulletin ist nicht alles so, wie es idealerweise soll, aber es funktioniert. greifst du in diesen mechanismus ein, hast du ein riesen problem.

    ich weiss wovon ich rede, denn ich hab das alles schon durch. die verwendung von unicode in vbulletin macht derzeit nicht wirklich sinn, weil dann viele andere sachen nicht mehr korrekt funktionieren.

  4. #4
    Janmaat
    Gast

    Daumen hoch

    Danke, Mystics, für den Hinweis!

    Danke, AA, für die detaillierte und verständliche Information über die Hintergründe. Dies war mir alles so noch nicht bekannt. Danke!

  5. #5
    vB-Experte
    Registriert seit
    30.05.2006
    Beiträge
    643
    Blog-Einträge
    3
    beim nochmaligen überfliegen meines textes sehe ich gerade, dass ich noch ein argument gegen eine nachträgliche konvertierung vergessen habe.

    sämtliche vbulletin-installations- und sprachdateien sind offiziell nur in der latin1-kodierung erhältlich. einige betreiber haben die systeme komplett auf utf-8 umgestellt und müssen ab diesem moment vor jedem einspielen eines updates immer auch die dateien umkodieren. es gibt zwar hier im forum auch nachträglich downloadbare utf-8 sprachfiles, aber darauf muss man in der regel immer warten, wenn man es nicht selber vornehmen kann.

    ein weiteres problem sind add-ons: das gesamte add-on-installationssystem arbeitet ausschliesslich mit latin1. deshalb sind auch addons bis auf wenige ausnahmen immer in latin1 kodiert. das heisst, man müsste dann auch jedesmal add-on-dateien selber umkodieren bei einem unicode-system. zudem funktioniert das add-on-system mit utf-8-files nur über einen dreckigen trick, indem man zwar utf-codierte dateien einspielt, aber der zeichensatz dieser dateien "intern" als latin1 ausgewiesen wird. das ist eine besonderheit, die ich so noch nirgends gesehen habe. aber auch das ist der vergangenheit geschuldet.

    würde man den mechanismus in vbulletin einfach ändern (also so wie man es normalerweise erwartet), würden alle add-ons plötzlich fehlerhaft importiert werden.

    die vbulletin-verantwortlichen kennen das problem schon lange. nur dafür eine brauchbare, abwärtskompatible lösung zu schaffen ist so gut wie unmöglich. es kann also noch eine weile dauern, bis mal jemand den mut aufbringt, dort richtig aufzuräumen

  6. #6
    vB-Guru Avatar von Jaydee
    Registriert seit
    29.05.2008
    Ort
    ...tief im Westen....
    Alter
    57
    Beiträge
    13.454
    Zumal sich noch dazu die Spielregeln bei MySQL im Laufe der Zeit etwas geändert haben und derartige Dinge heute "strenger" gehandhabt werden. Bis zur Version 4.0.x wurde noch vieles toleriert, was seit 4.1 nun nicht mehr möglich ist bzw. inzwischen stark vereinfacht wurde. Und es steht wieder eine neue Version bevor.

    Also an UTF-8/16 wird zukünftig auf Dauer Niemand mehr vorbeikommen, wenn er zeitgemäß entwickeln will. Abwärtskompatibilität ist zwar einerseits wünschenswert, aber andererseits a) nicht immer sinnvoll und b) eben aus technischen Gründen manchmal halt nicht machbar.
    Irgenwann muss man den harten "Break" vollziehen und komplett umstellen. Kodierungs- und Collation-Mixe gehen selten gut.
    Das Optimum wäre tatsächlich die einheitliche Abstufung "Web-Anwendung -> Server -> Datenbank -> Tabellen -> Spalten = alles einheitlich auf UTF-8".

    Aber zur Zeit ist das wohl noch Wunschvorstellung...
    Gruß
    Jörg


    Die deutsche Rechtschreibung ist Freeware. Das heißt, Du kannst sie kostenlos nutzen.
    Allerdings ist sie nicht Open Source, d.h. Du darfst sie nicht verändern oder in veränderter Form veröffentlichen.



  7. #7
    vB-Experte
    Registriert seit
    30.05.2006
    Beiträge
    643
    Blog-Einträge
    3
    eines der hauptprobleme mit der datenbank:

    installiert man ein vbulletin neu, wird nicht etwa - wie es bei vielen anderen vergleichbaren systemen der fall ist - ein wizzard gestartet, der zugleich die datenbank anlegt falls erforderlich. und zwar mit dem für vbulletin aktuell geeigneten zeichensatz. und das ist latin1. das würde schonmal ein späteres konvertieren zu einem anderen charset zum kinderspiel machen, denn mysql bringt diese werkzeuge ja bereits mit (in aktuellen versionen mit charset-unterstützung - also schon einige jahre!)

    denn wenn ich eine datenbank mit dem charset latin1 erstelle, werden später alle neu erstellten tabellen (ohne explizite angabe eines charsets) automatisch mit gleichem charset wie die db erstellt. und da liegt eines der probleme zurzeit. aktuell (mysql 5) ist wohl bei den meisten systemen utf-8 als default voreingestellt, so dass eine neu angelegte datenbank erstmal mit dem für vbulletin "falschen" charset ins rennen geht. mit fatalen folgen, rein technisch betrachtet. das problem hat Janmaat oben ja richtig beobachtet: irgendwas scheint nicht zu stimmen, obwohl alles stimmt

    das problem hätte sich lösen lassen, wenn beim erzeugen der tabellen später immer ein charset mitgegeben würde. allerdings ist das nachträglich nicht mehr möglich, da es sonst zu fehlern kommen würde, denn wenn spalten aus verschiedenen tabellen mit jeweils unterschiedlichen charsets zusammengeführt werden bei einer datenbank-abfrage, kommt mysql ins schleudern, denn es weiss nicht, welcher der charsets denn nun ausgegeben werden soll.

    es ist also derzeit kaum möglich, mit mysql-werkzeugen vbulletin-tabellen zu konvertieren. zumal es da die unterschiedlichsten konstellationen gibt.

    es ist sogar möglich und denkbar, dass man den html-zeichensatz auf utf-8 stellt und die datenbank-tabellen ebenso. nicht aber den mysql-zeichensatz des clients anpasst. da kommt genauso ein dreck raus, obwohl die ausgabe stimmt. aber spätestens bei der suchfunktion und der suche nach umlauten oder sonstigen sonderzeichen dürfte so manch einem dämmern, dass da irgendwas nicht stimmen kann.

    das add-on zum konvertieren von vbulletin geht einen denkbaren weg, obwohl der sehr sehr gefährlich ist, wenn eine ungünstige einstellung vorgenommen wurde: die konvertierung per php-erweiterungen. allerdings kann es vorkommen, das beim ersten auftreten eines nicht umwandelbaren zeichens, der text einfach abgeschnitten wird. fängt ein beitrag mit dem wort "Überraschung" an, ist der text komplett weg. das ist mir beim ersten versuch passiert.

    ganz ganz schlimm wird es dann, wenn ein betreiber die kodierungen zwischendrinn mal ändert und nach einigen korrekturen per suche-ersetzen in der datenbank, das ganze so weiterlaufen lässt. dann nämlich sind die inhalte rein charset-technisch auch noch gemischt. das macht eine nachträgliche konvertierung mit mysql und php quasi komplett unmöglich, ohne mehrfach-kodierungen zu riskieren. zb. utf8_encode(utf8_encode('Ä'))

    ebenso schlimm finde ich, dass die entwickler es bis heute nicht verstanden haben, den mist mit dem html-charset zurückzupfeifen. stattdessen werden bedeutungsschwangere kommentare im quelltext hinterlassen. man kennt das problem, will es aber offenbar nicht lösen:

    als beispiel sei ein (beliebiges) türkisches forum genannt. der betreiber lädt sich zunächst die englische version herunter, denn türkisch gibt es so nicht als installationsversion. also ist es zunächst der charset latin1. danach importiert er sich ein türkisches sprachfile, welches dann sehr wahrscheinlich mit dem html-charset iso-8859-9 daherkommt. und weil nicht jeder türkisch spricht, schaltet der betreiber dann beide sprachen zur benutzung frei. und jetzt wird es lustig: einige funktionen in vbulletin greifen zum konvertieren auf den charset zu. auf welchen? immer den charset des aktuellen benutzers. denn es gibt keinen verbindlichen systemcharset, den man für eine verbindliche konvertierung zwischen forum und datenbank hinzuziehen könnte. denn wie ich oben schon schrieb, ist der html-zeichensatz auch für die speicherung der daten relevant und nicht nur für die anzeige!

    mit der einführung der verschiedenen html-zeichensätze in vbulletin haben die entwickler gepennt. das wäre nämlich der richtige zeitpunkt für einen schnitt gewesen.

    und diese verf**te zeichensatz-angelegenheit wird von version zu version immer weiter verschleppt. aus kaufmännischer sicht verständlich, denn derzeit funktioniert ja alles. eine umstellung des systems hätte gigantische ausmaße, die immer grösser werden, je länger man es in den skat drückt und stattdessen immer neue features einbaut (projekttools, blog, cms, interessengruppen, profilnachrichten, etc etc).

    in meinen augen ist das eine pervertierte form von kundenbindung. denn mit den verwursteten daten in der datenbank hat man nur wenig chancen, problemlos auf ein anderes und moderneres forensystem umzusteigen.

    so, genug gemotzt für heute

  8. #8
    Janmaat
    Gast

    Daumen hoch Danke für die profunde Information

    Obwohl ich keine wirkliche Ahnung davon habe, ist das doch ein spannendes und interessantes Thema und bestärkt mich darin auch künftig beim reinen vB(4) Forum zu bleiben und nicht auf die Suite zu setzen.

  9. #9
    Fortgeschrittener Benutzer
    Registriert seit
    12.06.2005
    Beiträge
    180
    Seit Neuestem tritt beim Zusammenfügen von Beiträgen ein Anzeigeproblem bei Umlauten auf. Aus "ü" wird beispielsweise "ü". Ansonsten läuft alles völlig normal. Nur eben, wenn ich Beiträge zusammenfüge in denen Umlaute vorkommen, habe ich hinterher diesen Fehler.

    vBulletin 4.2.5
    Sprachzeichensatz: ISO-8859-1

    ganz normal auf einem standardgemäßen 1&1-Server:

    PHP-Version: 7.1.21
    MySQL-Version: 5.5.60
    Server Zeichensatz: utf8_unicode_ci

    Hat jemand der anwesenden Experten eine Idee, was die Ursache/Lösung sein kann?

  10. #10
    vB-Guru Avatar von Jaydee
    Registriert seit
    29.05.2008
    Ort
    ...tief im Westen....
    Alter
    57
    Beiträge
    13.454
    Auch wenn ich keinen direkten Zusammenhang mit diesem Phänomen sehe (und es sonst offenbar nirgends auftritt), vermute ich jetzt mal, dass es genau hieran liegt:

    Zitat Zitat von Polymat Beitrag anzeigen
    MySQL-Version: 5.5.60
    Der Rest passt eigentlich, aber 4.2.5 setzt minimal MySQL 5.5.8x voraus.

    Übrigens, noch nebenbei und wie so oft schon erwähnt:

    Zitat Zitat von Polymat Beitrag anzeigen
    Server Zeichensatz: utf8_unicode_ci
    Das ist immer noch kein Zeichensatz. Sondern nach wie vor "nur" die Kollation. Der entsprechende Zeichensatz dazu wäre normalerweise UTF8.
    Das nur als Randinformation, weil es immer wieder verwechselt wird (aber schnell zu Verständnisproblemen führen kann).


    Und noch etwas: Der Zeichensatz des Sprachpakets hat nichts mit dem Problem zu tun. Das würde sich nur auf die Phrasen auswirken, nicht aber auf (die von Usern verfassten) Inhalte in Beiträgen etc.
    Gruß
    Jörg


    Die deutsche Rechtschreibung ist Freeware. Das heißt, Du kannst sie kostenlos nutzen.
    Allerdings ist sie nicht Open Source, d.h. Du darfst sie nicht verändern oder in veränderter Form veröffentlichen.



  11. #11
    Fortgeschrittener Benutzer
    Registriert seit
    12.06.2005
    Beiträge
    180
    Zitat Zitat von Jaydee Beitrag anzeigen
    Auch wenn ich keinen direkten Zusammenhang mit diesem Phänomen sehe (und es sonst offenbar nirgends auftritt), vermute ich jetzt mal, dass es genau hieran liegt:

    Der Rest passt eigentlich, aber 4.2.5 setzt minimal MySQL 5.5.8x voraus.
    Gut möglich. War mir bisher nicht aufgefallen. Danke für den Tipp!

    Kann das mal jemand unter vB 4.2.5 reproduzieren? Zwei Posts mit Umlauten zusammenfügen?

    Hier habe ich was gefunden aber werde daraus nicht schlau:
    https://www.vbulletin.com/forum/foru...-after-upgrade
    Geändert von Polymat (23.09.2018 um 20:11 Uhr)

  12. #12
    Fortgeschrittener Benutzer
    Registriert seit
    12.06.2005
    Beiträge
    180
    Moment, MySQL 5.5.60 ist größer/neuer als das geforderte Minimum 5.5.8!

    Also bleibt die Frage nach der Fehlerursache bestehen.

  13. #13
    vB-Guru Avatar von Jaydee
    Registriert seit
    29.05.2008
    Ort
    ...tief im Westen....
    Alter
    57
    Beiträge
    13.454
    Nein, das funktioniert normal tadellos.
    Probiere es mal mit deaktiviertem Plugin-System ob es dann geht, evtl. funkt da ein älteres Add-on rein.
    Gruß
    Jörg


    Die deutsche Rechtschreibung ist Freeware. Das heißt, Du kannst sie kostenlos nutzen.
    Allerdings ist sie nicht Open Source, d.h. Du darfst sie nicht verändern oder in veränderter Form veröffentlichen.



  14. #14
    Fortgeschrittener Benutzer
    Registriert seit
    12.06.2005
    Beiträge
    180
    Mit deaktivierten Addons das selbe.

    Ich habe aber nun festgestellt, dass es nur vorkommt bei Beiträgen aus Zeiten vor vB 4.2.5. Bringt dich das auf eine heiße Spur?

  15. #15
    vBGo! Team Avatar von Andreas
    Registriert seit
    14.10.2003
    Alter
    39
    Beiträge
    2.533
    Klingt äußerst dubios. Steht in der DB bei beiden Beiträge tatsächlich ein ü und nicht vielleicht bei einem (oder beiden) ein Entity?

  16. #16
    Fortgeschrittener Benutzer
    Registriert seit
    12.06.2005
    Beiträge
    180
    Also ich habe es nochmal reproduziert:

    In der Datenbank direkt ist vor dem Zusammenfügen alles i. O. und lesbar. Beim Zusammenfügen von Beiträgen in Beteiligung eines oder mehrerer älterer Beiträge (< vB 4.2.5) tritt der Fehler auf, dass aus den Umlauten merkwürdige "üßvö" Zeichen werden. So stehen sie danach auch in der Datenbank. Beim Zusammenfügen von neueren Beiträgen hingegen tritt das Problem nicht. Übrigens im Zwischenschritt des Zusammenfügens ist der Fehler noch nicht präsent. Erst nach dem Absenden.

    Das Problem ist kein Weltuntergang und wenn es "nur" das ist, könnte ich damit leben. Dennoch macht man sich freilich Sorgen, ob Ursache/Fehler noch weiterreichender sein könnte. Darum vielen Dank für jeden von euch, der sich meiner Sache annimmt.

    Da ich hier mit meiner Sache im vb 3 Bereich eigentlich falsch bin, habe ich ein neues Thema eröffnet:
    http://forum.vbulletin-germany.com/s...-seit-vB-4-2-5
    Geändert von Polymat (23.09.2018 um 23:40 Uhr)

Aktive Benutzer

Aktive Benutzer

Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)

Ähnliche Themen

  1. Frage zu vB Code HTML + PHP
    Von JankaSu im Forum vBulletin 3.7 Fragen und Probleme
    Antworten: 2
    Letzter Beitrag: 11.01.2009, 18:03
  2. Eingehender RSS fedd mit html
    Von daddel80 im Forum vBulletin 3.7 Fragen und Probleme
    Antworten: 3
    Letzter Beitrag: 02.08.2008, 02:50
  3. HTML nur für bestimmte Benutzergruppen, wie geht das?
    Von Tal_ im Forum vBulletin 3.6 Fragen und Probleme
    Antworten: 12
    Letzter Beitrag: 29.05.2007, 23:03
  4. HTML in einem Forum
    Von So-Mysterious im Forum vBulletin 3.6 Fragen und Probleme
    Antworten: 4
    Letzter Beitrag: 26.11.2006, 08:26

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •