TxtToXmlConverter escaping scheint nicht alle Zeichen zu betreffen

[dhaeb]

z.B. bei commt eb9cb67 existiert folgender Diff:

-innerhalb und außerhalb des Stadtbereiches unterschieden wird, ist somit auch durch eine Vergleichsregelung innerhalb der gleichen Quelle die Haltlosigkeit derartiger „Vergleiche" eindeutig bewiesen. +innerhalb und außerhalb des Stadtbereiches unterschieden wird, ist somit auch durch eine Vergleichsregelung innerhalb der gleichen Quelle die Haltlosigkeit derartiger „Vergleiche" eindeutig bewiesen.

Interessant sind die ungleich escapten Anführungszeichen beim Wort Vergleiche. Warum wird das ausführende doppelte Hochkomma escapt, aber nicht das einführende? Ist jetzt nicht so wichtig, da deswegen keine Fehler geworfen werden. Aber wenn wir escapen, dann sollten wir es richtig tun.

[mam10dfd]

Hallo Dan,

das ist mir auch aufgefallen, aber da ich die Zeile oder den Teil der
Zeile einfach nur in die Funktion escape...() schreibe dachte ich,
dass du dir deinen Teil dabei schon gedacht haben magst, oder dass die
unteren Anführungszeichen keine Fehler werfen und deswegen nicht
escaped werden. Vorher wurden keine der beiden erkannt, weil in der
Methode speakerAtt bisher nicht escaped wurde, das habe ich geändert.
(also vielleicht funktioniert es jetzt sogar besser als vorher)

Viele Grüße

Peggy

Zitat von Dan Häberlein notifications@github.com:

z.B. bei commt eb9cb67 existiert folgender Diff:

-innerhalb und außerhalb des Stadtbereiches unterschieden wird, ist
somit auch durch eine Vergleichsregelung innerhalb der gleichen
Quelle die Haltlosigkeit derartiger „Vergleiche" eindeutig bewiesen. +innerhalb und außerhalb des Stadtbereiches unterschieden wird, ist
somit auch durch eine Vergleichsregelung innerhalb der gleichen
Quelle die Haltlosigkeit derartiger „Vergleiche" eindeutig
bewiesen.

Interessant sind die ungleich escapten Anführungszeichen beim Wort
Vergleiche. Warum wird das ausführende doppelte Hochkomma escapt, aber nicht das
einführende? Ist jetzt nicht so wichtig, da deswegen keine Fehler geworfen
werden. Aber wenn wir escapen, dann sollten wir es richtig tun.

---

Reply to this email directly or view it on GitHub: https://github.com/DHLeipzig-CurrentTopics-SS2014/openLegislature/issues/21

---

This message was sent using IMP, the Internet Messaging Program.

[dhaeb]

Alles klar,

du hast auf jeden Fall Recht, dass es nicht schlimm ist, die doppelten Anführungszeichen nicht zu escapen. Ist das jetzt denn schon aus der Welt? Es könnte auch sein, dass ein Unterschied zwischen Anfürhungszeichen (also " unten) und Ausführungszeichen (" normal wie hier gezeigt) gibt (zumindest wäre ersteres das dann nicht ASCII). Müsste man sich nochmal in Ruhe anschauen. Hat aber nicht so hohe Priorität in meinen Augen.

Viele Grüße!

Dan

[mam10dfd]

Naja, da wir dazu nur eine vorgefertigte Methode aus Java nutzen,
müsste man das dann dort umschreiben, wenn es denn stört. Dies wird ja immer aufgerufen:

private String escapeString(String escapable){ return StringEscapeUtils.escapeXml11(escapable); }

und escapeXml11 scheint es nicht nötig zu haben die unteren
Anführungszeichen zu escapen. Wenn es keine Fehler wirft würde ich da
drin nicht rumspielen wollen.

Viele Grüße

Peggy

Zitat von Dan Häberlein notifications@github.com:

Alles klar,

du hast auf jeden Fall Recht, dass es nicht schlimm ist, die
doppelten Anführungszeichen nicht zu escapen. Ist das jetzt denn schon aus der Welt? Es könnte auch sein, dass ein
Unterschied zwischen Anfürhungszeichen (also " unten) und
Ausführungszeichen (" normal wie hier gezeigt) gibt (zumindest wäre
ersteres das dann nicht ASCII). Müsste man sich nochmal in Ruhe
anschauen. Hat aber nicht so hohe Priorität in meinen Augen.

Viele Grüße!

Dan

---

Reply to this email directly or view it on GitHub: https://github.com/DHLeipzig-CurrentTopics-SS2014/openLegislature/issues/21#issuecomment-44746057

---

This message was sent using IMP, the Internet Messaging Program.