nicht angemeldet
Hallo,
ich habe auf die Schnelle auch keine Patentlösung, aber ein paar Anmerkungen:
Letztlich scheint der Flaschenhals darin zu bestehen, ein »zufälliges« Zeichen aus dem Dokument zu wählen. Darin sehe ich wenig Sinn. Wenn das Dokument mit einer größeren Menge natürlichem deutschsprachigem Text arbeitet, so ist der Zeichenbestand ziemlich überschaubar und man wird die übliche Buchstabenhäufigkeit finden. »Zufällig« wird dann sehr oft ein »e« oder »n« gewählt werden. ;)
Insofern kostet es viel, nutzt aber wenig, wirklich statistisch mit dem Gesamtstring des Dokuments zu arbeiten. Ich würde daher vielleicht mit einer festen Zeichenliste arbeiten (z.B. lateinisches Alphabet plus Umlaute plus Satzzeichen), die sich wirklich zufällig durchsuchen lässt. Wobei in dem Fall (wenn auch unwahrscheinlich) ein Zeichen gewählt werden kann, was im Dokument nicht vorkommt, dann müsste neu gewürfelt und gesucht werden, was langsam wäre. Aber unter dem Strich wohl schneller als die vorgestellten Ansätze.
Was das Durchlaufen des DOM angeht, so sollte man möglichst auf das händische rekursive Durchlaufen verzichten. Einerseits kann man mit einem TreeWalker arbeiten, andererseits müsste es (glaube ich zumindest) auch möglich sein, Textknoten mit XPath auszuwählen (document.evaluate usw.). Beides sollte auf jeden Fall performanter sein. Letztlich ist das natürlich ein schwacher Trost, weil man um das manuelle Durchlaufen im IE nicht herum kommt (vielleicht kann man irgendwas mit TextRanges basteln).
innerHTML stellt keine Alternative dar - abgesehen davon, dass man da mit ebenfalls unperformanten regulären Ausdrücken oder einem eigenen Parser Tags von Textinhalt trennen müsste, würden Entities ein weiteres Problem darstellen - > sind vier Zeichen, die ein sichtbares Zeichen repräsentieren.
Was spricht dagegen, die für reine Zeichenauswahl innerText bzw. textContent vom body zu nehmen und dann erst beim Markiervorgang die Textknoten zu suchen, in denen das Zeichen liegt?
Mathias