Ich nehme an es geht immer noch um den HTML Parser?
Dafür ist der lexer verantwortlich, welcher leerzeichen solange nicht part von content einfach überspringt, das hat bessere Performance als du mit RegEx jemals schaffen kannst, außerdem durchläufst du das ganze sowieso schon -> noch besser für die performance...
Wenn du etwas haben willst, was dir den HTML Code schön ausgibt, sogenanntes pretty-print, dann macht man das idr indem man nach dem Parsing-Schritt aus dem Baum wieder HTML Code erzeugen lässt. So macht es mit ziemlicher Sicherheit auch Chrome. So macht es Visual Studio(autoformat). So macht es clang formatting

beim gezeigten Problem sicherlich. Es geht sogar auch ohne Regex:

\s{2,}

@ErfinderDesRades das würde aber doch auch die aus dem Content nehmen.

Der soll doch aber hoffentlich so bleiben => Kann ja vom Ersteller des HTML-Skripts so gewollt sein.

Oder war das nicht die Vorgabe?

Ich hab mal nen test gemacht zu .Replace("\r", "").Replace("\t", "").Replace("\n", ""); und .Replace(text, replacement);



das ergebniss lautet

RegEx ist generell langsamer

Snickbrack schrieb:

@ErfinderDesRades das würde aber doch auch die aus dem Content nehmen.

Der soll doch aber hoffentlich so bleiben => Kann ja vom Ersteller des HTML-Skripts so gewollt sein.

Oder war das nicht die Vorgabe?

Nein, war es nicht.
Übrigens auch Facebams Replacing entfernt Spaces aussm Content.

Aber egal - meine Einlassung hatte eh den Sinn, aufzuzeigen, dass die Fragestellung nicht sonderlich sinnvoll war - und war ja eh nur eine Interesse-Frage.

ErfinderDesRades schrieb:

Übrigens auch Facebams Replacing entfernt Spaces aussm Content.

zu 100% würde man es schon hinbekommen aber dann wird der Regex hässlich, so wie der in meinem Projekt
@"(?:<td(?:[^>]+)?>([^<]+)[^\n]+\n[^>]+>((?:<em>)|[^<]+)<\/td>\n)|(?:<td(?:[^>]+)?><a\shref=""(?:\/cssref\/)?([^\/\""]+)\"">([^<]+)[^\n]+\n[^>]+>(<em>|<\/em>|[^<]+)+)"

Edit: aber wo zu will ich im Content zwei mal ein Leerzeichen in folge?
H|E|L|L|O| | |W|O|R|L|D => H|E|L|L|O| |W|O|R|L|D und deswegen \\s{2,}

φConst schrieb:

ErfinderDesRades schrieb:

Aber
egal - meine Einlassung hatte eh den Sinn, aufzuzeigen, dass die
Fragestellung nicht sonderlich sinnvoll war

Warum ?

Na, weil die Ersetzungen auch innerhalb der Contents sämtliche Spaces entfernen.

φConst schrieb:

ErfinderDesRades schrieb:

Facebamm schrieb:

Edit:
aber wo zu will ich im Content zwei mal ein Leerzeichen in
folge

Stimmt.
_

Siehst du?
Die Anforderung ist nun deutlich geändert, und die jetzige Lösung erfüllt nun nicht mehr, was in Post#1 durch das einzige gegebene Input-OutPut - Beispiel gefordert ist.

Facebamm dir also eine brauchbare Lösung geliefert, ohne dass du dazu eine brauchbare Anforderung formulieren musstest.

Facebamm schrieb:

Edit: aber wo zu will ich im Content zwei mal ein Leerzeichen in folge?

Auf HTML generell bezogen?
Zum Beispiel bei <pre>, <script>, <style>, (allen Attributen), Elemente mit der CSS-Eigenschaft white-space, etc.

3daycliff schrieb:

Zum Beispiel bei <pre>, <script>, <style>, (allen Attributen), Elemente mit der CSS-Eigenschaft white-space, etc.

was will ich da mit doppelten leerzeichen, ich bin doch froh, wenn mein code am ende komprimiert wird und der user nicht 100kb runterlanden muss sondern nur 80kb oder so O.O
selbst bei CSS-Eigenschaften kommen keine doppelten Leerzeichen vor, oder irre ich mich da?


wird dann einfach zu

selbst in der Anwendung
<|d|i|v| |i|d|=|"|p|r|o|p|e|r|t|i|e|I|D|"|>|H|e|l|l|o| |W|o|r|l|d|<|/|d|i|v|> wird zu, bzw. bleibt <|d|i|v| |i|d|=|"|p|r|o|p|e|r|t|i|e|I|D|"|>|H|e|l|l|o| |W|o|r|l|d|<|/|d|i|v|>

oder hab ich was übersehen? OO

Facebamm schrieb:

ich bin doch froh, wenn mein code am ende komprimiert wird und der user nicht 100kb runterlanden muss sondern nur 80kb oder so O.O

Genau. Deswegen finde ich es eigentlich völlig nicht nötig wenn der Parser da irgendwas kürzt. Denn runtergeladen hat man die große Datei trotzdem und ändert sie nur ab.
Der Parser ist meiner Meinung nicht dafür da die arbeit des Entwicklers zu machen in dem er den HTML Code nochmal anpasst.
Wenn der HTML Code "scheiße" ist und nicht geparsed werden kann ist ja nicht der Parser schuld sondern der HTML Code Schreiber oder nicht?

Bei Komprimierung sollte man schon zwischen lossy und lossless unterscheiden. Natürlich können manche Whitepsaces getrost ignoriert werden, aber halt nicht alle.

Im Post #1 und #5 finden sich z.B. ein paar Leerzeichen, die man nicht wegschmeißen will.
Bezüglich Attribute: <a onClick="foo('___');"> und <style>.foo { background-image:url("pfad___mit___leerzeichen.png"); }</style>.
(Unterstrich hier mal als Leerzeichen interpretieren, weil die hier im Forum bei tt ignoriert werden...)

Über die Sinnhaftigkeit kann man natürlich streiten, der Standard erlaubt es aber.

((?=\s{2,})(?!.*"\s|.*')\s*)|((?=\s{2,})(?!.*"|.*')\s*) so, der tut jetzt
der ist zwar auch nicht die Bombe aber besser wird es glaub net gehen
regexr.com/3vs0c