japanische contenido seiten

emergence
Beiträge: 10641
Registriert: Mo 28. Jul 2003, 12:49
Wohnort: Austria
Kontaktdaten:

Beitrag von emergence » Mi 25. Mai 2005, 09:36

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...
*** make your own tools (wishlist :: thx)

timo
Beiträge: 6284
Registriert: Do 15. Mai 2003, 18:32
Wohnort: Da findet ihr mich nie!
Kontaktdaten:

Beitrag von timo » Mi 25. Mai 2005, 09:48

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?

emergence
Beiträge: 10641
Registriert: Mo 28. Jul 2003, 12:49
Wohnort: Austria
Kontaktdaten:

Beitrag von emergence » Mi 25. Mai 2005, 09:57

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

Code: Alles auswählen

%$%SPERATOR%$%
mit auskommentierung dieser einen zeile -> und man hat im text ein | drinnen, gibts netterweise ne endlosschleife im explorer beim versuch zu speichern...
*** make your own tools (wishlist :: thx)

timo
Beiträge: 6284
Registriert: Do 15. Mai 2003, 18:32
Wohnort: Da findet ihr mich nie!
Kontaktdaten:

Beitrag von timo » Mi 25. Mai 2005, 10:14

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

EDIT: Habs schon ;)

emergence
Beiträge: 10641
Registriert: Mo 28. Jul 2003, 12:49
Wohnort: Austria
Kontaktdaten:

Beitrag von emergence » Mi 25. Mai 2005, 10:16

in der selben datei -> includes.con_editcontent.php

ganz zu beginn

du musst nur in der datei nach dem orginal string suchen

Code: Alles auswählen

§%%§
sollte zweimal vorhanden sein...
*** make your own tools (wishlist :: thx)

timo
Beiträge: 6284
Registriert: Do 15. Mai 2003, 18:32
Wohnort: Da findet ihr mich nie!
Kontaktdaten:

Beitrag von timo » Mi 25. Mai 2005, 10:17

ü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

emergence
Beiträge: 10641
Registriert: Mo 28. Jul 2003, 12:49
Wohnort: Austria
Kontaktdaten:

Beitrag von emergence » Do 26. Mai 2005, 22:00

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...
*** make your own tools (wishlist :: thx)

HerrB
Beiträge: 6935
Registriert: Do 22. Mai 2003, 12:44
Wohnort: Berlin
Kontaktdaten:

Beitrag von HerrB » Do 26. Mai 2005, 22:58

von der der materie...
Man merkts ... :wink:

Gruß
HerrB
Bitte keine unaufgeforderten PMs oder E-Mails -> use da Forum!

Newsletter: V4.4.x | V4.6.0-15 (Module, Backend) | V4.6.22+
Standardartikelliste: V4.4.x | V4.6.x
http://www.contenido.org/forum/search.php | http://faq.contenido.org | http://www.communido.net

timo
Beiträge: 6284
Registriert: Do 15. Mai 2003, 18:32
Wohnort: Da findet ihr mich nie!
Kontaktdaten:

Beitrag von timo » Fr 27. Mai 2005, 09:21

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).

grossy
Beiträge: 57
Registriert: Mi 28. Apr 2004, 12:56
Wohnort: downunder
Kontaktdaten:

Beitrag von grossy » Di 7. Nov 2006, 04:25

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:

Bild

nachher:

Bild
< put intelligent quote here />

emergence
Beiträge: 10641
Registriert: Mo 28. Jul 2003, 12:49
Wohnort: Austria
Kontaktdaten:

Beitrag von emergence » Di 7. Nov 2006, 09:53

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...
*** make your own tools (wishlist :: thx)

grossy
Beiträge: 57
Registriert: Mi 28. Apr 2004, 12:56
Wohnort: downunder
Kontaktdaten:

Beitrag von grossy » Mi 8. Nov 2006, 14:06

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?
< put intelligent quote here />

emergence
Beiträge: 10641
Registriert: Mo 28. Jul 2003, 12:49
Wohnort: Austria
Kontaktdaten:

Beitrag von emergence » Mi 8. Nov 2006, 14:25

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
*** make your own tools (wishlist :: thx)

grossy
Beiträge: 57
Registriert: Mi 28. Apr 2004, 12:56
Wohnort: downunder
Kontaktdaten:

Beitrag von grossy » Do 9. Nov 2006, 03:35

wie teste ich das denn? :roll:
< put intelligent quote here />

emergence
Beiträge: 10641
Registriert: Mo 28. Jul 2003, 12:49
Wohnort: Austria
Kontaktdaten:

Beitrag von emergence » Do 9. Nov 2006, 08:30

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...
*** make your own tools (wishlist :: thx)

Gesperrt