captFuture
I'm new here

HTML special Chars werden nicht konvertiert

In unserem Projekt abseits von der standard Webseite verwenden wir Datenquellen um inhalte zu pflegen und dann in verschiedenste Kanäle auszuspielen.

Die Eingabe erfolgt z.B. über:

<CMS_INPUT_TEXT name="ITEM_ID" convertEntities="standard" editable="yes" maxInputLength="30">

    <LANGINFOS>

      <LANGINFO lang="*" label="ITEM_ID" description=""/>

    </LANGINFOS>

  </CMS_INPUT_TEXT>

<CMS_INPUT_TEXT name="ITEM_NAME" convertEntities="standard" editable="yes" maxInputLength="150">

    <LANGINFOS>

      <LANGINFO lang="*" label="ITEM_NAME" description=""/>

    </LANGINFOS>

  </CMS_INPUT_TEXT>

Bei der Ausgabe wird dann ein Mapping file generiert, das aus den eingegebenen ITEM_IDs und den generierten files aus der Datenquelle über ein perlscript eine ordnerstruktur und darin enthaltene files erstellt.

Soweit so gut... (das funktioniert schon seit jahren ohne probleme)

Was wir leider nicht in den Griff bekommen ist trotz oft kontrollierten konvertierungseinstellungen ein austausch der Umlaute aus den ITEM_NAME feldern. Es kommen immer die Umlaute im ausgegebenen .html file heraus, was uns am frontend dann natürlich probleme bereitet.

Gibt es da einen speziellen Trick um das zu kontrollieren und funktionsfähig zu machen?

(Dazugesagt befinden sich in der Datenquelle mitlerweile tausende Einträge und jeden einzeln anzugreifen wäre ein absoluter overkill)

Danke

0 Kudos
4 Replies
kohlbrecher
Crownpeak employee

Hallo,

was bei den convertEntities schief läuft kann ich dir nicht sagen aber was passiert denn, wenn im Ausgabekanal eine Konvertierungsregel mit den entsprechenden Angaben angegeben wird?

Ist UTF-8 als Format für die Ausgabe keine Option?

Grüße

Jan

0 Kudos

Hallo,

konnte Jans Antwort Ihre Fragen lösen oder benötigen Sie noch weitere Hilfe?

Viele Grüße

Michaela

0 Kudos

Utf-8 ist in diesem Stadium leider keine option (obwohl ich es mir wünsche) aber die webserverkonfiguration lässt dies im moment nicht zu, da die zeichen dann komplett falsch ausgeliefert werden. (Dazugesagt sind es 8 Apache Produktionsfrontendserver und 8 dazugehörige Bea Weblogic Applikationsserver ... dies macht die umstellung auf utf-8 zu einem ziemlich großen projekt)

0 Kudos

Christoph Prantl schrieb:

Was wir leider nicht in den Griff bekommen ist trotz oft kontrollierten konvertierungseinstellungen ein austausch der Umlaute aus den ITEM_NAME feldern. Es kommen immer die Umlaute im ausgegebenen .html file heraus, was uns am frontend dann natürlich probleme bereitet.

Über $CMS_VALUE(ITEM_NAME)$ wird die Ersetzung transparent vorgenommen (convertEntities Einstellung der Komponente). D.h. der Wert wird in euren Templates noch auf andere Weise ausgegeben (z.B. direktes Auslesen über die API). Diese Stelle(n) sollte(n) sich finden lassen. Dort muss dann im Template ein ".convert" vor der Ausgabe ergänzt werden, um die Zeichenkonvertierung vorzunehmen.

Peter
0 Kudos