@forrest, forrest gump: du hast ein völlig anderes problem.
beim ursprünglichen problem nützt auch die ttflocaleconv leer lassen nix!
nur zur anmerkung. 😉
lgc
Keine Umlaute mit GIFBUILDER
Hallo zusammen,
ich denke schon, dass ich hier eine Problemlösung für den Thread habe.
Thread: Keine Umlaute mit GIFBUILDER
hebi schriebHallo, habe folgendes Problem:
Bei der Darstellung von grafischen Menüs oder grafischen Texten mit GIFBUILDER werden die deutschen Umlaute nicht richtig wiedergegeben. Wenn ich die Umlaute als HTML-Entitäten angebe, werden diese als solche ausgegeben (z.B. ü😉
In allen anderen Fällen (TMENU, usw.) ist die Anzeige aber in Ordnung.
Meine Versionen:
Typo3 4.0 auf SuSE 10.1Weiß wer eine Lösung für das Problem?
ulrich.manns
Ich habe alles auf UTF8 umgestellt.
$TYPO3_CONF_VARS['BE']['forceCharset'] = 'utf-8';
$TYPO3_CONF_VARS['GFX']['TTFLocaleConv'] = '';
Damit werden die Schriftarten per Gifbuilder mit UTF-8 angesteuert und liefern die richtigen Ergebnisse, wenn die Zeichen in der Schriftart enthalten sind, und Umlaute und "ß" sind eindeutig in den Standard-Schriftarten enthalten. Wenn du eine kyrillische Tastatur hast und steuerst verdana.ttf an, wirst du wohl kaum kyrillische Zeichen bekommen, da musst du schon eine andere Schriftart ansteuern. Oder?
Gruß Andreas
Also nochmal von vorne:
Der Fehler liegt in der gdlib/imagemagick, bzw. in der vorkompilierten version von php5 auf allen openSuSE Versionen von 10.0 bis mindestens 10.2.
Daher nützt es nichts das ttflocaleconf leerzulassen (das ist ja bei utf8 umstellung mal die grundvoraussetzung, daher gehe ich davon aus, dass dies bei allen ist). -> Das war aber offensichtlich dein ursprüngliches Problem.
Das problem wäre behebbar, wenn man die php5 neu kompiliert, was aber auf einem Produktivserver mit 15-20 Kunden eher uncool rüberkommt.
Weiters tritt das problem mit den neuesten gm versionen nicht mehr auf bei mir.
Zum Thema Schriftarten: Ob kyrillische Zeichen in der Schriftart vorhanden sind oder nicht, liegt natürlich an der schriftart selbst. Aber bei einer arial.ttf auf einem ms windows system sind sie mit sicherheit drin.
BastianBalthasarBux schriebDas problem wäre behebbar, wenn man die php5 neu kompiliert, was aber auf einem Produktivserver mit 15-20 Kunden eher uncool rüberkommt.
Und sowas schimpf sich Webhoster,.. sorry aber diese Aussage ist inkompetent und vermittelt den Eindruck das dieser Lösungsweg nicht praktikabel für Produkttiv Server sei.
Erstens kompilieren selbst affektiert einmal gar nichts auf dem server.
Erst ab dem make install wird das neue php als Modul geschrieben.
Es gibt auch keine Unterbrechnung beim Produkttivbetrieb da ein apache warm restart nichts unterbricht wohl aber die das neue PHP als Modul läd.
Das klingt eher danach als ob noch nie PHP kompiliert worden wäre (was ansich in keiner weise ein Problem darstellt egal wiviel Kunden auf dem Server sind)
Im übrigen brächte PHP kompilieren auch nichts. Wenn schon dann gd neu kompilieren.
Auch hier gäbe es keine Probleme. Ist im übrigen auch der bessere Weg
Denn wenn man tatsächlich andere Leute bezahlen lässt für sein Service sollten dinge wie CharsetSupport wohl auch stimmen.
tja, spätestens wenn beim händischen kompilieren von php ein fehler gemacht wurde (weil zb. eine kleinigkeit vergessen wurde), und das dann nach einem warmstart geladen wurde krachts halt.
aber mir is eh wurscht, soll doch jeder machen wie er mag.
nur hinterher nicht hier im forum hoilen! 😉
btw: man könnte das neu kompilierte php auch (und das wäre viel sicherer) als cgi einbinden. -> das kann man dann pro vhost einbinden. ist halt langsamer.
und wer ist hier webhoster? ich zb. hoste ausschliesslich eigenentwickelte projekte. und zwar deswegen, weil ich mit so anfängern zu tun hatte, die eben genau das gemacht haben, nämlich php neu kompiliert und niemandem was gesagt. oder auch andere änderungen am server. und irgendwann stinkt es einem halt, wenn man die fehler von anderen ausbaden darf. bei den eigenen, naja, da kann man sich dann wenigstens an der eigenen nase packen.
ps: bei mir ists eh händisch kompiliert. -> aber bitte jetzt keine fragen wie das geht, da müsst ma ja bei adam und eva anfangen ...
stimmt ich geb dir recht
da muss man bei adam und eva anfangen.
nur typo3 und standart deb pakete is nicht das ware. überhaupt sollte man bei php auf pakete verzichten. sog gut es ist durch die verbreitung treten eben sehr häufig sec. probleme auf. (über bugfixes schweigen wiruns mal aus :-)
was das vergessen betrifft so hilfts einfach die configure wurscht als file abspeichern und gleich als solches ausführbar setzen.
zusatzmodule einfach hinzufügen hilft beim vergessen 😃
i leide ja auch unter alzheimer
muss ma ja ohnehin häufig machen wenn man nur benötigte extensions aktivieren will.
also zurück zum problem
als den String leer lassen hilft wirklich nicht.
zuerst sollte man mal in die datenbank schauen ob die umlaute wirklich als umlaute dort stehen oder sonderzeichen (acuh wenns typo dann wieder richtig darstellt.
diegefahrt besteht bei komplett umgestellen mysqlsystem (meines läuft zu 100% unter utf8-) das hier auf einer utf8 connection ein latin1 übergeben wird und mysql es somit doppel codiert
es kommt dann wieder richtig zurück.
sollte das so sein reicht nicht nur das force charset aus sondern
$TYPO3_CONF_VARS['SYS']['setDBinit'] = 'SET NAMES utf8;';
SONST NICHTS (kein set charackter set connection etc)
Das aber nur nebnbei und kann ebenfalls zu dem Umlaut Problem führen
erst wenn das alles soweit in ordnung ist (im backend/frontend wie ind er datenbank utf8 mit umlauten)
kann man sich an das gifbuilder problem ranwagen
hähä, gut dass du es erwähnst. aber an und für sich sollte allen klar sein, dass für UTF8 die db auch auf utf sein sollte. und ebenfalls das DBinit auf utf8.
steht ja eh irgendwo in den tuts zu typo3 & utf8 drinnen.
eine mysqldb mit schwedisch als collation kann nicht funktionieren! 😉
--> schon gesehen nebenbei.
den ttf localeconf string sollte man jedenfalls leer lassen wenn:
be auf force utf8 steht,
und die db auch auf utf8
ansonstens es kracht!
dann auch am frontend es geht
wenn config.renderCharset = utf8 steht
(oder so ähnlich, siehe tsref)
😉
Daher sagte ich auch einen voll Umgestellten server :-)
Sprich
charater-set-server
default-character-set
collation-server
character-set-client
jeweils = utf8 (achtung nicht utf-8 :-)
Natürlich auch die DB und die Tables auf utf8 unicode
Halt stop nein die Tables sind natürlich utf8 hier liegt das problem beim setdbinit und forcecharset. da überschneidet sich was. wenn du mehr als das set names im set dbinit angibts und forcecharset aktivierst ist vorbei und mysql codiert von sich aus latin auf utf8 obwohl d anichts mehr ist was mit latin zu tun hätte:-)
es wär wirklich mal zeit den ganzen encoding müll in ein setup zu bringen
Ahja noch etwas zur recode function. Also ich kanns jetzt nur auf 64bit Systemen nachvollziehen (angeblich sollts unter 32 bit gehen so recht wie schlecht)
wird nicht zu kompilieren sein mit dem mysql support (und imap geht auch nicht)
es gibt auch extra warnings das recode als erstes geladen werden sollte weil die mysql extension wegen dem hash_insert sich gegenseitig nicht mögen (tja langsam kommen die schatten von open=nichtso standart=source auf)
also recode und 64bit und mysql geht nicht. man könnte den cponfigure umgehen recode als shared bauen und danach die mysql (bitte dann ebenfalls shared)
dann die module manuell laden als .so
natürlich hier das recode als erstes :-) theoretisch sollte das stabil laufen. wers teste will bitte gern #evil#
in einem anderen Typo3 wurde das Charset UTF8 nur in der localconf.php angegeben in der MySQL aber nicht... die ist immer noch Latin-1, kann man das Ohne Problme jetzt alles auf UTF8 bringen, oder müsste man dann alle Seiten und News, und, und, und wieder umkonvertieren...
fragt mich nicht warum das so gemacht wurde...
Umlaute werden in der DB bspw. so angegeigt:
für = für
Ich will nur nicht im Produktivem System rumbastel...
Kompilieren:
Zum Kompilieren, währe es besser nur GDlib zu Kompilieren... für Produktive Server...
Ansonsten macht man es mit fast-cgi, nicht mit CGI... cgi ist einfach zu lahm!
und Testet alles druch, und übernimmt die andere Config...
Gruß
Gunah
So kann man auf utf-8 umstellen: db dump zb. mit phpmyadmin aber auf iso eingestellt. -> anschliessend neue db anlegen mit utf8 -> dump importieren.
sollte normalerweise funktionieren.
wenn es hakt -> mit recode oder ähnlichem das sql file umkodieren -> und dann erst importieren.
in welches UTF8 muss den die DB sein?
steht alles in utf8_general_ci und es ist aber keine Veränderung da:
und das hier ist in der localconf.php
$TYPO3_CONF_VARS['SYS']['setDBinit'] = 'SET NAMES utf8;';
$TYPO3_CONF_VARS['BE']['forceCharset'] = 'utf-8';
weil alles bleibt beim alten...
Sprich die Umlaute sind in der MySQL DB immer noch komisch Codiert und werden von Typo3 wenn man es via Typo3 macht auch immer noch flasch Angelegt...
Ü in der DB = Ãœ
Edit: // habe gerade im Browser mal manuell in iso-8859-1 geändert dort wird die sachen die ich der DB Manuell geändert habe richtig angezeigt aber die anderen sachen nicht...
$TYPO3_CONF_VARS['SYS']['setDBinit'] = 'SET NAMES utf8'.chr(10).'SET CHARACTER SET utf8'.chr(10).'SET SESSION character_set_server = utf8'.chr(10).'SET character_set_connection = utf8';
$TYPO3_CONF_VARS['BE']['forceCharset'] = 'utf-8';
So läuft es bei mir erfolgreich. Wenn deine Datenbank vorher auf ISO-8859-1 stand, dann wirst du wohl erst mal einen dump machen müssen und den dump dann in eine utf8_general_ci importieren müssen. Google mal nach TYPO3 Datenbank konvertieren utf-8.
andreas
Ich habe hier ein PHP-Skript, dass die Datenbank komplett konvertiert. Es ist zwar ursprünglich für WordPress geschrieben worden, aber Schema und Inhalt der DB ist dem Skript egal. vorher unbedingt ein Backup machen und im Skript die Zuugangsdaten zur Datenbank eintragen:
http://www.fihlon.ch/fileadmin/downloads/convert-encoding.phps
Auf eigene Gefahr...
McPringle
es gibt auch eine extension für die konvertierung von iso auftritten in utf8 auftritte (im ter nach utf suchen sollte helfen).
aufpassen muss man aber wenn man zb. typoscript in dateien verwendet -> muss auch in utf8 konvertiert werden (zb mit ultraedit). besonders wenn man locallang werte dort einträgt.
genauso mit html templates.
das Script von "McPringle" ist nicht schlecht, nur empfehle ich vorher die ganzen Cache tabellen zu leeren, und dann das Script zu starten sonst dauert das zu lange...
Gruß
Gunah
EDIT://
habe jetzt alle Tabellen in utf8 (per PHPmyAdmin kontrolliert), die Extension: cr_bugfix_5078 installiert leider ist das ergebnis immer noch das gleiche...
Ohne Extension ist es so "ber Uns"
Mit Extension ist es so "Ãber Uns"
habe die DB vorher mit dem Script von McPringle konvertiert dann die Local angepasst:
$TYPO3_CONF_VARS['SYS']['setDBinit'] = 'SET NAMES utf8'.chr(10).'SET CHARACTER SET utf8'.chr(10).'SET SESSION character_set_server = utf8'.chr(10).'SET character_set_connection = utf8';
$TYPO3_CONF_VARS['BE']['forceCharset'] = 'utf-8';
$TYPO3_CONF_VARS['GFX']['TTFLocaleConv'] = '';
EDIT-2://
habe den "Fehler" gefunden...
Ich habe in der "class.ux_tslib_gifbuilder.php" folgendes geändert:
return mb_encode_numericentity($content,$convmap);
zu
return mb_encode_numericentity($content,$convmap,mb_detect_encoding($content, "auto"));
danach wurden alle Umlaute angezeigt
Edit-3:// Könnte man nicht bei der EXT. eine Option reinbauen, welchen Mode man benutzen will?
wie bei tt_news usw...
Edit-4: habe jetzt die funktion auf class.ux_tslib_gifbuilder.php gelöscht und die andere angefügt...
Gruß
Mathis
wer das letzt Beschriebene Problem hat. und alles auf UTF-8 Umgestellt hat und Trotzdem keine Umlaute angezeigt bekommt, kann erstmal mit dieser Extension lösen.
http://serviceconnect.de/dev/mk_bugfix_5078_add.t3x
liegt jetzt auch im TER
Ich hoffe das die Änderungen, die in dieser Extension sind auch bald in die "Orginale" Extension kommt...
eine E-Mail habe ich dazu schon verschickt... naja mal gucken...
Beim Testen bei mir funktioniert alles wie es soll 🙂
Nutzung auf eigene Gefahr...
Sollte Typo3 mit einer ISO Kodierung betrieben werden, funktioniert meine Extension hier nicht...
Hallo,
ich rolle dass hier einfach nochmal auf:
Ich würde gerne mit dem GIFBUILDER auch kyrillische Zeichen und andere internationale Zeichen (z.B. Chinesisch) verwenden. Umlaute funktionieren mit der hier im Thread Lösung ausgezeichnet.
Muss ich theoretisch nur die conversionmap (in der EXT mk_bugfix_5078-) ändern ? Oder sollte das mit dem richtigen Font auch funktionieren ?
Gruß,
Christoph
Uargh ... Sechs Stunden Arbeit, bis meine Umlaute in grafischen Überschriften funktioniert haben. Ich fasse die Schritte aus diesem Thread, die bei mir dann letztendlich funktioniert haben, mal zu einer Checkliste zusammen, um anderen den Weg zu erleichtern:
1. Typo3 umstellen auf utf-8
1.1. Im Server-Adminpanel einstellen, dass die Typo3-Datenbank UTF8 verwendet.
1.2. In der localconf einfügen
$TYPO3_CONF_VARS['GFX']['TTFLocaleConv'] = '';
$TYPO3_CONF_VARS['SYS']['setDBinit'] = 'SET NAMES utf8;';
$TYPO3_CONF_VARS['BE']['forceCharset'] = 'utf-8';
1.3. Im Setupbereich des Haupttemplates einfügen:
page.config.metaCharset = utf-8
page.config.additionalHeaders = Content-Type:text/html;charset=utf-8
page.config.renderCharset = utf8
1.4. Die Extension convert2utf8 installieren und damit den kompletten Seitenbaum wandeln lassen
1.5. Wenn die Sonderzeichen in den Content Elementen danach kaputt, von Hand mit den richtigen Zeichen überschreiben
2. utf-8-Font bereitstellen
2.1. Mit FontForge (ist kostenlos downloadbar) prüfen, ob die gewählte Schrift in utf-8 bzw. Unicode kodiert ist. Wenn nicht: Encoding - Reencode - ISO 10646-1, dann File - Generate Font.
2.2. Font auf den Server laden
2.3. Im Setup-Template für die grafischen Überschriften den korrigierte Font einstellen, wenn er unter anderem Namen gespeichert ist als der Ursprungsfont
3. GIFBUILDER-Fehler korrigieren
3.1 Extension cr_bugfix_5078 installieren
3.2 Wenn die Umlaute noch nicht funktionieren: In Datei class.ux_tslib_gifbuilder.php (Pfad: typo3conf/ext/cr_bugfix_5078-) Zeile 43 auskommentieren und bei Zeile 44 die Auskommentierung entfernen, so dass da steht
//return mb_encode_numericentity($content,$convmap);
return mb_encode_numericentity($content,$convmap,mb_detect_encoding($content, "auto"));
Damit war das Problem bei mir ausgestanden. Falls es noch nicht behoben ist, kann man wohl noch die Extension mk_bugfix_5078_add zusätzlich installieren, das war bei mir aber nicht nötig.
Insbesondere die Sache mit der falschen Font-Codierung ist nervig, vier Stunden hat es mich gekostet, diesen Fehler zu bemerken ... Aber nun, http://www.alligatorfarm.de läuft, die Leute können wieder Perry Rhodan-Comics kaufen, und alle sind glücklich. Nur ich bin müde.
Beste Grüße
Kai[/url]
Puh, was ne Mühe. Wollte nur noch korrigiert haben, dass du folgende 3 Zeilen ersatzlos streichen kannst.
1. page.config.metaCharset = utf-8
2. page.config.additionalHeaders = Content-Type:text/html;charset=utf-8
3. page.config.renderCharset = utf8
Erklärung:
weil du
$TYPO3_CONF_VARS['BE']['forceCharset'] = 'utf-8';
gesetzt hast, wird dieser Wert default für metaCharset und renderCharset genommen. utf8 wäre übrigens falsch, utf-8 richtig. Der Header wird auch default gesendet, siehe Erklärung zu disableCharsetHeader in der TSRef. Alle Infos aus der TSRef.
Gruß Andreas