Laden...

XMLWriter soll & nicht ersetzten

Erstellt von mvollmer vor 12 Jahren Letzter Beitrag vor 12 Jahren 1.456 Views
M
mvollmer Themenstarter:in
61 Beiträge seit 2011
vor 12 Jahren
XMLWriter soll & nicht ersetzten

Guten Tag,

ich möchte mir in Silverlight eine HTML Page generieren lassen, dies tue ich mit dem XMLWriter.

Ich konvertiere die Umlaute und Sonderzeichen in html Code ala ß um.

Das Problem ist der XMLWriter konvertiert das & in & und dann ergibt es ß

Kann ich mit XMLWriterSettings bestimmen, welche Zeichen er nicht konvertieren soll? Gibt es eine andere möglichkeit?

1.346 Beiträge seit 2008
vor 12 Jahren

Macht der XmlWriter die Umlautkonvertierung nicht automatisch?

lg pdelvo

656 Beiträge seit 2008
vor 12 Jahren

Ich denke eher, dein Problem fängt schon früher an. Wenn du das "ß" als Text einfügst, wird das & direkt durch & ersetzt - eben weil es ja eine Spezialbedeutung hat und du "Text" einfügst; keine EntityReference. Der Writer nimmt das dann nur 1:1 und schreibt es als & raus.

Ohne DTD (oder entsprechenden Resolver, oder was auch immer man dafür braucht - ich würd selber gern wissen was!) kann weder System.Xml noch System.Xml.Linq mit Character-Entities umgehen - die einzige Ausnahme ist &

C
2.121 Beiträge seit 2010
vor 12 Jahren

Vielleicht wäre es ja ein Ansatz dass du auf diese Ersetzung verzichtest und stattdessen ein Encoding verwendest, das mit allen Sonderzeichen umgehen kann?
Es ist meines Wissens längst nicht mehr Stand der Technik, solche Zeichen in HTML zu ersetzen.

M
mvollmer Themenstarter:in
61 Beiträge seit 2011
vor 12 Jahren

Danke für die Antworten.

Ich habs nun so gemacht, das ich meine eigene Konvertierung entfernt habe und folgendes in den HTML Header geschrieben habe


 <meta http-equiv="Content-Style-Type" content="text/css" charset="utf-8" />

Früher hab ich es halt so gelernt, das zu Barrierefreiem HTML dazu gehört alle Sonderzeichen umzuwandeln 😃

C
2.121 Beiträge seit 2010
vor 12 Jahren

Zu barrierefreiem? Ich denke halt das kommt aus der Zeit wo man noch keine verschiedenen Codierungen kannte. Aber diese Zeiten sind ja schon lange vorbei.
Mit Barrierefreiheit hat die Codierung jedenfalls nichts zu tun, das Ergebnis im Browser ist ja so oder so das selbe.