Forum
|
Öffentliche Foren |
| FORUM: Support / Features / Feedback THEMA: Features; Unicodezeichenfilter | |||||
| AUTOR | BEITRAG | ||||
|
h¥pertex
RANG Deckschrubber |
#61 - 19.12 16:45 [x]dafür |
||||
|
vengeance | ⁒⁒⁒⁒
RANG Master of Skill |
#62 - 22.01 18:39 jetzt ist das ganze zu einem forum verschoben, gemacht wird aber dennoch nichts, oder? |
||||
|
▪dσвєηiciσus▪
RANG Ultimate 0wn3r |
#63 - 22.01 22:26 gut erkannt
|
||||
|
Zombine
RANG Godlike |
#64 - 22.01 22:55 business as usual ^^ |
||||
|
cbw.lava
RANG Hardcore Ruler |
#65 - 25.01 16:06 Ganz so einfach wie manche denken ist es nicht ^^, dennoch wäre voller Unicode-Support nützlich und wünschenswert.Ich erleuchte euch mal  Erstmal muss unterschieden werden zwischen: - dem korrekten Auflösen von HTML-Entities wie & #8364; (was bei CI eh ne Sache für sich ist, denn wenn man z.B. im Forum einen neuen Post mit HTML-Entities erstellt, so werden diese erstmal scheinbar einfach durchgereicht, genauso wie Umlaute und Sonderzeichen auch, was beides so absolut richtig ist. Wenn ich aber den Post editiere, läuft wohl vorher html_entity_decode() drüber, was schlecht ist weil inkonsistent. Das sollte ganz weggelassen werden.) - dem Zeichensatz, in dem die Seiten ausgeliefert werden - und dem Zeichensatz, in dem die Daten letztendlich in CIs Datenbanken liegen (wobei ich mal der Einfachheit halber annehme, das die beiden letztgenannten identisch sind) All das hängt natürlich zusammen. CI liefert standardmäßig (Stand 25.1.2008) alle Seiten "Windows-1252" codiert (zumindest zeigt Firefox das als automatisch erkannten Zeichensatz, wenn man den Content-Type Header im CI unter Farbeinstellungen aus dem Header rauseditiert hat. Sollte man eh tun, denn der Content-Type und auch der benutzte Zeichensatz wird normalerweise per HTTP-Header vorgegeben, und den kann man als CI-Nutzer nicht editieren - wäre auch nicht sinnvoll). In diesem Zeichensatz liegen automatisch auch alle Zeichen vor, die man als Nutzer postet, denn der Browser benutzt zum Senden von Daten den Zeichensatz, den auch die Seite hat (logisch). Der Support vom Euro-Zeichen und anderen Windows-1252-Zeichen war für CI aus dem Grund einfach, weil die in Windows-1252 zusätzlichen Zeichen in ISO-8859-1 (ich nehme jetzt einfach mal an, dass dies der vorherige von CI benutzte Zeichensatz war) gar nicht vorhanden sind, und die restlichen Zeichen haben den selben Zeichencode. CI konnte also sagen (stark vereinfacht programmiertechnisch gesprochen): "Alles bestehende in der Datenbank ist Windows-1252" (was keine Probleme gibt, aus eben genanntem Grund) und "Alles, was rein kommt ist auch Windows-1252" (was evtl. dann Probleme gibt, wenn der Browser die gesendeten Daten nicht als Windows-1252 zurückgibt, weil der Nutzer an den Browser-Einstellungen rumgepfuscht hat, oder im HTML-Tag meta http-equiv="Content-Type" unter charset was anderes als Windows-1252 steht und der Browser dann dies benutzt, oder der Nutzer Unicode-HTML-Entities benutzt und der Browser nicht so fehlertolerant ist, dass er versucht, für diese Entities eine Entsprechung im Seiten-Zeichensatz zu finden). Bei Unicode haben aber manche Zeichen wie Umlaute und Sonderzeichen einen ganz anderen Zeichencode als in Windows-1252 (z.B. hat das Euro-Zeichen in Windows-1252 den dezimalen Code 128, welcher in Unicode als Control Character Code reserviert ist - das Euro Zeichen hat in Unicode den dezimalen Code 8364. BTW wenn Unicode-HTML-Entities wie & #8364; in Windows-1252 Seiten funktionieren, ist dies allein der recht fehlertoleranten Programmierung des Browsers zu verdanken ).Die Folge ist, wenn eine Datenbank, die (angenommen) bisher Daten Windows-1252-codiert enthält, in Zukunft auch Unicode-Daten aufnehmen soll: - müssen erstmal ALLE bestehenden Daten in Unicode (z.B. UTF-8) konvertiert werden. Selbst wenn das natürlich automatisiert ablaufen kann sinds bestimmt einige Stunden wenn nicht Tage Downtime von CI nur für die Konvertierung aller Forumposts, Userinfos, Polls, ... etc. Alternativ könnte man die DB im laufenden Betrieb spiegeln und direkt bei der Spiegelung konvertieren, so spart man einen Großteil der Downtime.- aller CI-Code muss für die Verwendung für Unicode geprüft bzw. angepasst werden. - dann müssen die Seiten zukünftig mit dem korrekten Zeichensatz im HTTP Content-Type Header ausgeliefert werden (dieser Part ist wiederum easy). Man könnte die sehr zeitaufwändige Konvertierung aller Daten evtl. umgehen, in dem man nur die Daten konvertiert, bei denen keine Zeitangabe vorhanden ist (vielleicht die Userinfos, evtl. gibts aber auch da ne interne Zeitangabe der letzten Änderung o.ä.) und dann sagt (wieder stark vereinfacht programmiertechnisch gesprochen): "Alle Daten vor Zeitpunkt x (= Zeitpunkt der Umstellung auf Unicode) bleiben Windows-1252, werden aber beim Zugriff nach Unicode konvertiert bevor sie an den Browser geliefert werden" und "alle Daten ab Zeitpunkt x sind bereits Unicode, nicht konvertieren sondern durchreichen". Ich kann euch also versichern eine Umstellung nach Unicode ist ein gutes Stück Arbeit und keineswegs mal eben schnell erledigt, zumindest wenn das von mir gezeichnete Szenario so stimmt Umgehen hätte man das ganze natürlich können, in dem man die Daten von vornherein als Unicode in den Datenbanken ablegt (den Unicode-Standard gibts ja schon ewig...) *edit* paar kleinere Sachen hinzugefügt. |
||||
|
Dr. Udo Brömme
RANG Lord of Skill |
#66 - 25.01 16:12 doch, ist es. du übersiehst nämlich eine kleinigkeit: wenn unicode mit &# kodiert wird, ist es völlig belanglos, mit welchem charset die seiten ausgeliefert bzw. die inhalte in der db gespeichert sind. man sieht ja an den usernamen, in denen unicode schon immer funktioniert, dass es prinzipiell kein problem ist. |
||||
|
cbw.l▲v▲
RANG Hardcore Ruler |
#67 - 25.01 18:06 Also Unicode in Usernamen scheint auch nicht immer zu funktionieren, siehe mein Name links wo ein schwarzes nach oben zeigendes Dreieck anstelle & #9650; sein sollte.Und ich stelle grad fest, dass Unicode-Zeichen in unserem internen Forum funktionieren, aber hier nicht. *edit* Ich denke, ich weiß jetzt, warum es im internen und bei den Usernamen funktioniert, und es hat IMHO nix mit CI zu tun. PHP versucht bei gesendeten Daten, die nicht im Seiten-Charset vorliegen, mit einer internen Logik das Charset zu bestimmen und konvertiert dann in HTML-Entities (hier auch getestet mit einer eigenen Seite und PHP 5.2), deren korrekte Darstellung wiederum beim Browser liegt (was wohl anstandslos funktioniert). In den öffentlichen Foren funktionierts nicht, weil hier kein HTML-Code erlaubt ist. Die von PHP aus den gesendeten nicht-Windows-1252-Zeichen erzeugten Entities werden also nochmal durch htmlspecialchars() gejagt. Das bringt uns aber dank dieser internen PHP-Funktionalität (von der ich bisher auch nix wusste  ) jetzt auch zu einer tatsächlich einfachen und schnell umzusetzenden Lösung @allanon: Falls meine Annahme richtig ist, mach doch wenn kein HTML erlaubt ist statt htmlspecialchars() was in folgender Art:
So bleiben Entities erhalten, HTML bleibt aus, und alle sind glücklich
|
||||
|
Dr. Udo Brömme
RANG Lord of Skill |
#68 - 25.01 18:08 boah, editier nicht immer, wenn ich schon was geschrieben habe*edit* ja, das ist ja letztendlich genau das, was ich schon die ganze zeit vorgeschlagen hatte
|
||||
|
cbw.l▲v▲
RANG Hardcore Ruler |
#69 - 25.01 18:22
naja. Dein Vorschlag war lang nicht so spezifisch wie meiner und ne echte Lösung enthielt er auch nicht.Achja oben zu meinem Post noch ein Nachtrag (verdammt wegen dir kann ich nimmer editieren ): Statt mit nem leeren String sollten die eckigen Klammern dann natürlich durch < und > ersetzt werden.
|
||||
|
Dr. Udo Brömme
RANG Lord of Skill |
#70 - 25.01 18:26 was ist an "unicode aus html-filter nehmen" keine lösung?
|
||||
|
cbw.l▲v▲
RANG Hardcore Ruler |
#71 - 25.01 18:29 Bitte? Das ist keine Lösung weil du dann erstmal schaun musst WIE du das machst. Und das WIE hab ich beantwortet und auch WARUM es dann überhaupt funktioniert. |
||||
|
Dr. Udo Brömme
RANG Lord of Skill |
#72 - 25.01 18:50 kennst du den ci-code? weißt du, wie der html-filter derzeit aussieht? was bringen dann hypothetische vorschläge?
|
||||
|
cbw.l▲v▲
RANG Hardcore Ruler |
#73 - 25.01 19:10
Schaun mer mal. Das WIE ist weniger interessant, darauf wäre vor mir bestimmt schon jemand gekommen. Das Interessante ist doch das WARUM, sprich, was PHP von sich aus mit POST-Daten macht, die vom verwendeten Charset abweichen. Ich hätte jetzt gedacht, er reicht sie einfach durch und man müsste als Programmierer selbst schaun, wie man damit umgeht (früher war das bei PHP IMHO auch mal der Fall).
|
||||
|
vaest´ark // patrick *circle of confusion*
RANG Master of Clanintern |
#74 - 25.01 20:07 oha.der str_replace-ansatz ist nicht brauchbar. denke an die " und ', die üs, äs, und ßs dieser welt. http://php.net/htmlentities mit entsprechendem charset wäre eher die lösung. alternativ die & vor den # mit darauffolgenden 3 oder 4 ziffern und ; zurückersetzen. |
||||
|
cbw.l▲v▲
RANG Hardcore Ruler |
#75 - 25.01 21:49
Gibts alles im Windows-1252 Zeichensatz, keine Entities notwendig. Wo soll da ein Problem sein? Nur für Atrribute von HTML-Tags gebe ich dir teilweise recht, hier muss man die " in Entities umwandeln. Spielt aber bei Forumposts keine Rolle solang HTML eh nicht erlaubt ist.
Geht auch, eine derartige Lösung wäre aber aufwendiger. *edit* Es ist nicht PHP (wie ich ursprünglich annahm), das für eine automatische HTML-Entity-Konvertierung von nicht Charset-konformen Zeichen sorgt, sondern der Browser, der den Request sendet. Grade mal mit nem Netzwerksniffer geschaut was da passiert, und es ist definitiv so das bereits der ausgehende Request die Entities enthält. Interessant. |
||||
|
▪мιlтøшη▪
RANG Godlike |
#76 - 07.02 14:56 *bump*welche währung ist das wohl -> €
|
||||
|
▪dσвєηiciσus▪
RANG Ultimate 0wn3r |
#77 - 08.02 02:24 yen?
|
||||
|
▪мιlтøшη▪
RANG Godlike |
#78 - 08.02 09:10 ne yen geht so -> ¥edit: ja hauptsache yen geht aber € nicht 
|
||||
|
▪dσвєηiciσus▪
RANG Ultimate 0wn3r |
#79 - 10.02 00:05 www.clanintern.de - made in japan
|
||||
|
horst
RANG Prophet of Clanintern |
#80 - 10.02 11:53 Wie hätte denn ¥en sonst seinen Nickname schreiben können... Wenn sich wer von euch €uro nennt, dann abeitet Alla evtl. dran ;-) |
||||
|
▪мιlтøшη▪
RANG Godlike |
#81 - 10.02 12:19 doben kann meinen nick auch mit sonderzeichen schreiben; ich selbst nicht*bump* |
||||
|
▪dσвєηiciσus▪
RANG Ultimate 0wn3r |
#82 - 10.02 17:19 jo, du horst
|
||||
|
▪мadDσg▪L´éclat, c´est moi!אּ
RANG Master of Clanintern |
#83 - 13.02 21:53
ich auch, ich auch 
|
||||
|
200µg フオ~!!
RANG Master of Clanintern |
#84 - 14.02 07:14 ▪мιlтøшη▪フオ~!! sauerei. 
|
||||
|
▪dσвєηiciσus▪
RANG Ultimate 0wn3r |
#85 - 14.02 11:30 nuhuuuub
|
||||
|
▪мιlтøшη▪
RANG Godlike |
#86 - 14.02 11:36 btw... der thread ist bald zwei jahre als *bump* |
||||
|
horst
RANG Prophet of Clanintern |
#87 - 14.02 12:03 
|
||||
|
200µg フオ~!!
RANG Master of Clanintern |
#88 - 14.02 12:51 #85, neeeeheeeeeerd.
|
||||
|
Dr. Udo Brömme
RANG Lord of Skill |
#89 - 14.02 18:51 der vorschlag ist schon sechs jahre alt oder so, aber der alte thread ist irgendwann gelöscht worden
|
||||
|
▪мadDσg▪L´éclat, c´est moi!אּ
RANG Master of Clanintern |
#90 - 18.02 13:05 Vllt. sollten wir mal 'ne Wette aufmachen:Was tritt zuerst ein: a) Wir können "Sonderzeichen" posten. b) Der Fred verschwindet in den unendlichen Weiten der Löschroutinen. c) Der Fred stößt an sein Postmaximum. d) Der Himmel fällt uns auf den Kopf.
|
||||