CONTENIDO Forum

ganz einfach...

sagen wir mal du hast mehrere CMS_HTML elemente
beim speichern oder wechseln in den HTML editor werden alle die CMS_HTML elemente in ein form field kopiert -> seperator = |
siehe -> $contentform in includes.con_editcontent.php
kommt nun innerhalb des textes das zeichen | vor funktioniert das mit dem seperator natürlich nicht mehr...

deshalb wurde das so eingebaut...

der javascript fehler rührt daher das zeichen § den ascii wert 167 hat...
der hit daran -> in jedem encoding entspricht der wert dann einem anderen zeichen...

$ entspricht ascii 36 -> egal welches encoding verwendet wird -> das zeichen $ bleibt unverändert...

tja und da nun mal javascript vom encoding abhängig ist, kommt es zu dem fehler...

für mich stellt sich da die Frage, ob $ im Zusammenhang mit PHP ein Problem darstellen kann? Bzw was passiert, wenn der Benutzer ein | eingibt?

timo hat geschrieben:für mich stellt sich da die Frage, ob $ im Zusammenhang mit PHP ein Problem darstellen kann? Bzw was passiert, wenn der Benutzer ein | eingibt?

ähm das mit dem $ zeichen hab ich getestet, verursacht an sich kein problem da es nur dann als variable interpretiert wird, wenn es in etwa so aussieht
$var -> wird interpretiert
$_var -> wird interpretiert
$__var -> wird interpretiert
$1 -> wird nicht interpretiert
$% -> wird nicht interpretiert
$" -> wird nicht interpretiert

man könnte ja ganz sicher gehen und den seperator string so aufbauen mit auskommentierung dieser einen zeile -> und man hat im text ein | drinnen, gibts netterweise ne endlosschleife im explorer beim versuch zu speichern...

hmm okay, soweit verstanden, allerdings wo wird $%%$ wieder zurückgewandelt? Irgendwie finde ich das nicht...

EDIT: Habs schon

in der selben datei -> includes.con_editcontent.php

ganz zu beginn

du musst nur in der datei nach dem orginal string suchen sollte zweimal vorhanden sein...

übrigens, ich habe eben gefunden, wozu das use_encoding verwendet wird:

bei der Modulbearbeitung wird der Flag auf false gesetzt, sodaß nicht bei einem XML Im- bzw Export das Encoding als Header gesendet wird - technisch gesehen ist das ja eine Contenido-Seite, die aber XML zurückliefert...und die sollte nicht encodiert sein, da das passende Encoding beim XML export geliefert wird

thx für die info...

hab mich heute den ganzen tag mit utf-8 und multibyte strings beschäftigt...

ähm ganz klar ist es mir nicht wie es die db schafft die entsprechenden strings korrekt zu sichern...

php an sich 8859-1
mysql an sich 8859-1

page encoding utf-8
beim posten wird logischerweise ein utf-8 string übermittelt...

und der string wird dann ohne nachbehandlung in die db geschrieben und als 8859-1(??) gespeichert
beim dump steht dann logischerweise nur müll dort...
hmm...

wenn man sich zu lange damit beschäftigt kriegt man richtig kopfweh von der der materie...

von der der materie...

Man merkts ...

Gruß
HerrB

naja eigentlich ist es ganz einfach: der Datenbank ist es wurscht, welches Encoding das ist. Beim Dump genauso. Schau dir spasseshalber einfach mal den Dump in einem Editor an, wo man das encoding setzen kann - dann ändern sich die Zeichen auf wundersame Weise

Die Kopfschmerzen hatte ich übrigens auch schon, dabei ist alles so einfach. Wenn ein User ein "Ä" eingibt, ist das ja das ASCII-Zeichen 196 - aber NUR bei ISO-8859-1! Also wird das ASCII-Zeichen 196 in der DB gespeichert. Wenn man z.b. in der DB das Zeichen 196 in ISO-8859-7 ansieht, wird ein komisches Dreieck draus. Die Encodings sind daher immer nur verschiedene Sichtweisen auf ein und dasselbe ASCII-Zeichen.

Bei UTF ists ähnlich, aber selbst wenn die DB auf ISO-8859-1 eingestellt ist, wird es funktionieren (mit Ausnahme von Statements, die dann mit LIKE usw arbeiten).

uhm der thread hat sich ja nett verlaengert - auch wenn ich die letzten sachen nicht wirklich verstehe

hier nochmals eine sache die mir im moment im hinblick auf japanisch kopfzerbrechen bereitet. hab die screenshots unten mal gepostet.

also ich oeffne artikel, geh in den editor, schreib meine japanischen characters, klick auf den gruenen haken zum speichern. vorschau wird geladen - alles gut. druecke ich nun aber zum beispiel in der vorschau nochmal auf "save" oder aender ich die headline zerhauts mir den text...

sieht so aus als wuerden manche japanischen character sich nicht toll verhalten und den code brechen, da z.b. der "text html" button innerhalb des zu editierenden textfelds ist und auch im editor nachher erscheint...

ne idee? :/

vorher:



nachher:

ist ja wirklich ein alter thread... ein großteil des oben angemerkten eigenheiten wurden im code nachbessert.
d.h welche contenido version setzt du ein ?
teste das verhalten doch bitte mal mit einer 4.6.15 version...

hey. hab grad auf die 15er geupdated. immer noch gleiches problem beim speichern... kann es sein, dass bestimmte japanische characters sowas wie "Escape characters" sind, also den php code brechen?

ich glaub da eher das die javascript routine zum speichern des contents irgendeinen fehler baut...

müsste jemand austesten...

die url mit dem content:
http://bonditsunami.com.au/web/cms/fron ... angelang=2
codierung: SHIFT_JIS

wie teste ich das denn?

ich sags mal so
testen kann das nur einer, der ahnung von SHIFT_JIS codierung und javascript hat...
eine kurz anleitung wie du das testen kannst zu liefern, geht beim besten willen nicht -> das ist richtige arbeit... und dafür hab ich momentan echt keine zeit...