Orivel Orivel
Menue oeffnen

Markdown-Subset-zu-HTML-Konverter

Vergleiche Modellantworten fuer diese Programmierung-Benchmark-Aufgabe und pruefe Scores, Kommentare und verwandte Beispiele.

Bitte einloggen oder registrieren, um Likes und Favoriten zu nutzen. Registrieren

X f L

Inhalt

Aufgabenubersicht

Vergleichsgenres

Programmierung

Aufgaben-Erstellermodell

Antwortende Modelle

Bewertungsmodelle

Aufgabenstellung

Schreiben Sie eine Python-Funktion `markdown_to_html(markdown_text: str) -> str`, die einen String, der eine bestimmte Teilmenge von Markdown enthält, in die entsprechende HTML-Darstellung konvertiert. Die Funktion muss die folgenden Merkmale unterstützen: **Block-Elemente:** 1. **Kopfzeilen:** Zeilen, die mit `# ` bis `###### ` beginnen, sollten in `<h1>`- bis `<h6>`-Tags umgewandelt werden. 2. **Ungeordnete Listen:** Zeilen, die mit `- ` beginnen, sollten in `<ul>`- und `<li>`-Tags umgewandelt werden. Verscha...

Mehr anzeigen

Schreiben Sie eine Python-Funktion `markdown_to_html(markdown_text: str) -> str`, die einen String, der eine bestimmte Teilmenge von Markdown enthält, in die entsprechende HTML-Darstellung konvertiert. Die Funktion muss die folgenden Merkmale unterstützen: **Block-Elemente:** 1. **Kopfzeilen:** Zeilen, die mit `# ` bis `###### ` beginnen, sollten in `<h1>`- bis `<h6>`-Tags umgewandelt werden. 2. **Ungeordnete Listen:** Zeilen, die mit `- ` beginnen, sollten in `<ul>`- und `<li>`-Tags umgewandelt werden. Verschachtelte Listen, eingerückt durch zwei Leerzeichen pro Ebene, müssen unterstützt werden. Eine Liste endet durch eine Leerzeile oder ein anderes Block-Element. 3. **Codeblöcke:** Inhalt, der zwischen Zeilen mit dreifachen Backticks (```) eingeschlossen ist, sollte in `<pre><code>...</code></pre>` umgewandelt werden. Der Sprachbezeichner in den öffnenden Backticks (z. B. ```python) sollte ignoriert werden. Innerhalb eines Codeblocks darf keine weitere Markdown-Verarbeitung stattfinden. 4. **Absätze:** Jeder andere Text sollte in `<p>`-Tags eingeschlossen werden. Aufeinanderfolgende Textzeilen gehören zum gleichen Absatz. Absätze werden durch eine oder mehrere Leerzeilen getrennt. **Inline-Elemente:** 1. **Fett & Kursiv:** `***text***` sollte in `<strong><em>text</em></strong>` umgewandelt werden. 2. **Fett:** `**text**` sollte in `<strong>text</strong>` umgewandelt werden. 3. **Kursiv:** `*text*` sollte in `<em>text</em>` umgewandelt werden. **Regeln und Einschränkungen:** - Inline-Elemente können innerhalb von Kopfzeilen und Listenelementen verschachtelt sein. - Der Parser sollte robust gegenüber fehlerhaften oder kniffligen Eingaben sein, wie z. B. nicht geschlossenen Inline-Tags. Zum Beispiel sollte `*italic` als `<p>*italic</p>` gerendert werden. - Die Prioritätsreihenfolge für Inline-Elemente ist `***`, dann `**`, dann `*`. - Gehen Sie davon aus, dass die Eingabe ein einzelner mehrzeiliger String ist. - Implementieren Sie keine Unterstützung für andere Markdown-Funktionen wie Links, Bilder, Blockzitate oder geordnete Listen. - Das ausgegebene HTML muss kein vollständiges Dokument sein (keine `<html>`- oder `<body>`-Tags erforderlich). **Beispiel-Eingabe:** ```markdown # Header 1 This is a paragraph with **bold** and *italic* text. This is the same paragraph. - List item one - List item two with ***bold and italic*** - Nested list item - Back to the first level ```python def hello(): print("Hello, World!") ``` ```

Erganzende Informationen

Diese Aufgabe testet die Fähigkeit, einen Parser für eine einfache, gut definierte Sprache zu schreiben. Sie erfordert sorgfältiges Handling verschiedener Zustände (z. B. innerhalb einer Liste, innerhalb eines Codeblocks), das Parsen sowohl von Block- als auch Inline-Elementen und das Verwalten verschachtelter Strukturen. Eine erfolgreiche Lösung zeigt gutes Algorithmendesign, Aufmerksamkeit für Randfälle und eine robuste Code-Struktur.

Bewertungsrichtlinie

Eine qualitativ hochwertige Antwort wird alle angegebenen Merkmale korrekt implementieren. Die Lösung sollte robust sein und Randfälle elegant behandeln, wie z. B. verschachtelte Listen, verschachtelte Inline-Formatierungen und fehlerhafte Syntax. Der Code sollte gut strukturiert, lesbar und effizient sein. - **Korrektheit:** Das erzeugte HTML muss die Markdown-Eingabe gemäß allen Regeln genau wiedergeben. Achten Sie besonders auf die korrekte Verschachtelung von Listen und Inline-Stilen. - **Robustheit:** Der Cod...

Mehr anzeigen

Eine qualitativ hochwertige Antwort wird alle angegebenen Merkmale korrekt implementieren. Die Lösung sollte robust sein und Randfälle elegant behandeln, wie z. B. verschachtelte Listen, verschachtelte Inline-Formatierungen und fehlerhafte Syntax. Der Code sollte gut strukturiert, lesbar und effizient sein. - **Korrektheit:** Das erzeugte HTML muss die Markdown-Eingabe gemäß allen Regeln genau wiedergeben. Achten Sie besonders auf die korrekte Verschachtelung von Listen und Inline-Stilen. - **Robustheit:** Der Code darf bei kniffligen oder fehlerhaften Eingaben nicht abstürzen. Beispielsweise sollte ein nicht geschlossenes `*` als Literal behandelt werden. - **Codequalität:** Die Lösung sollte gut organisiert und leicht verständlich sein. Die Verwendung von regulären Ausdrücken ist zulässig, aber auch ein Zustandsautomat oder andere Parsing-Techniken sind akzeptabel. Die Wahl des Algorithmus und die Qualität der Implementierung werden bewertet. - **Vollständigkeit:** Alle angegebenen Merkmale (Kopfzeilen, Absätze, Listen mit Verschachtelung, Codeblöcke und alle drei Inline-Stile) müssen implementiert werden.

Antworten

import re import html def markdown_to_html(markdown_text: str) -> str: """Konvertiert eine Teilmenge von Markdown in HTML. Unterstützte Funktionen: - Überschriften (# .. ######) - Ungeordnete Listen mit 2-Leerzeichen-Einrückung - Eingefasste Codeblöcke (```) - Absätze - Inline: ***fett+kursiv***, **fett**, *kursiv* """ def escape(text: str) -> str: # HTML-sensible Zeichen escapen. return html.escape(text, quote=False) def process_inline(text: str) -> str: """Verarbeitet Inline-Markdown. Funktioniert auch mit bereits escapedem Text, da...

Vollstandige Antwort anzeigen

import re import html def markdown_to_html(markdown_text: str) -> str: """Konvertiert eine Teilmenge von Markdown in HTML. Unterstützte Funktionen: - Überschriften (# .. ######) - Ungeordnete Listen mit 2-Leerzeichen-Einrückung - Eingefasste Codeblöcke (```) - Absätze - Inline: ***fett+kursiv***, **fett**, *kursiv* """ def escape(text: str) -> str: # HTML-sensible Zeichen escapen. return html.escape(text, quote=False) def process_inline(text: str) -> str: """Verarbeitet Inline-Markdown. Funktioniert auch mit bereits escapedem Text, da die Marker *, ** und *** keine escapeden Zeichen enthalten. """ escaped = escape(text) # Reihenfolge der Priorität: ***, dann **, dann *. # Nicht-gierige Übereinstimmung verwenden und lose Nicht-Leerzeichen-Grenzen erfordern. # ***text*** escaped = re.sub( r'\*\*\*(.+?)\*\*\*', r'<strong><em>\1</em></strong>', escaped, ) # **text** escaped = re.sub( r'\*\*(.+?)\*\*', r'<strong>\1</strong>', escaped, ) # *text* escaped = re.sub( r'\*(.+?)\*', r'<em>\1</em>', escaped, ) return escaped lines = markdown_text.split('\n') output = [] # Zustandsvariablen in_code_block = False code_buffer = [] paragraph_buffer = [] # Listen-Stack: Liste der aktuell offenen Einrückungsebenen (0, 1, 2, ...) list_stack = [] def flush_paragraph(): if paragraph_buffer: content = ' '.join(paragraph_buffer) output.append(f'<p>{process_inline(content)}</p>') paragraph_buffer.clear() def close_lists_to(level): """Schließt Listen, bis nur noch `level` Listen offen sind (level = Anzahl der offenen <ul>).""" while len(list_stack) > level: output.append('</li>') output.append('</ul>') list_stack.pop() if list_stack: # Nach dem Schließen einer verschachtelten Liste bleibt das übergeordnete <li> offen; # es wird geschlossen, wenn der nächste Geschwister beginnt oder wenn es vollständig geschlossen wird. pass def close_all_lists(): while list_stack: output.append('</li>') output.append('</ul>') list_stack.pop() i = 0 while i < len(lines): line = lines[i] # Codeblock-Verarbeitung if in_code_block: if line.strip().startswith('```'): # Codeblock beenden code_content = '\n'.join(code_buffer) output.append(f'<pre><code>{escape(code_content)}</code></pre>') code_buffer = [] in_code_block = False else: code_buffer.append(line) i += 1 continue # Prüfung auf Codeblock-Start stripped = line.strip() if stripped.startswith('```'): flush_paragraph() close_all_lists() in_code_block = True i += 1 continue # Leerzeile if stripped == '': flush_paragraph() close_all_lists() i += 1 continue # Überschrift? header_match = re.match(r'^(#{1,6}) +(.*)$', line) if header_match: flush_paragraph() close_all_lists() level = len(header_match.group(1)) content = header_match.group(2).rstrip() output.append(f'<h{level}>{process_inline(content)}</h{level}>') i += 1 continue # Listenpunkt? # Führende Leerzeichen abgleichen (müssen gerade sein für Verschachtelung) gefolgt von "- " list_match = re.match(r'^( *)- +(.*)$', line) if list_match: flush_paragraph() indent_spaces = len(list_match.group(1)) # Nur als gültige Einrückungsebene behandeln, wenn die Einrückung ein Vielfaches von 2 ist indent_level = indent_spaces // 2 content = list_match.group(2) # Listen-Stack anpassen if not list_stack: # Frisch beginnen: Die erste Liste muss auf Ebene 0 sein indent_level = 0 output.append('<ul>') list_stack.append(0) output.append(f'<li>{process_inline(content)}') else: current_depth = len(list_stack) - 1 # oberster Index if indent_level > current_depth: # Eine neue verschachtelte Liste öffnen (nur eine Ebene tiefer pro Schritt) indent_level = current_depth + 1 output.append('<ul>') list_stack.append(indent_level) output.append(f'<li>{process_inline(content)}') elif indent_level == current_depth: # Geschwister auf derselben Ebene: vorheriges <li> schließen output.append('</li>') output.append(f'<li>{process_inline(content)}') else: # Einrücken reduzieren: tiefere Listen schließen while len(list_stack) - 1 > indent_level: output.append('</li>') output.append('</ul>') list_stack.pop() # Auch das übergeordnete <li> schließen, das diese verschachtelte Liste enthielt output.append('</li>') # Jetzt auf derselben Ebene: Geschwister hinzufügen output.append(f'<li>{process_inline(content)}') i += 1 continue # Andernfalls ist es eine Absatzzeile if list_stack: close_all_lists() paragraph_buffer.append(line.strip()) i += 1 # Ende der Eingabe: alles leeren if in_code_block: # Nicht geschlossener Codeblock: alles ausgeben, was wir haben code_content = '\n'.join(code_buffer) output.append(f'<pre><code>{escape(code_content)}</code></pre>') flush_paragraph() close_all_lists() return '\n'.join(output) if __name__ == '__main__': sample = '''# Überschrift 1 Dies ist ein Absatz mit **fettem** und *kursivem* Text. Dies ist derselbe Absatz. - Listenpunkt eins - Listenpunkt zwei mit ***fett und kursiv*** - Verschachtelter Listenpunkt - Zurück zur ersten Ebene ```python def hallo(): print("Hallo, Welt!") ``` ''' print(markdown_to_html(sample))

Ergebnis

#2

Siegstimmen

0 / 3

Durchschnittsscore

64

Gesamtpunktzahl

70

Gesamtkommentar

Antwort A implementiert alle erforderlichen Funktionen und ist gut strukturiert mit klaren Kommentaren. Der Inline-Parser verwendet Regex-Ersetzungen in der Reihenfolge der Priorität, was für die meisten Fälle funktioniert, aber einen subtilen Fehler aufweist: Er maskiert keine HTML-Zeichen, bevor Inline-Muster angewendet werden, und die Maskierung wird zuerst angewendet, was Muster beeinträchtigen könnte. Kritischer ist, dass die Logik zum Schließen von Listen einen Fehler beim Einrücken aufweist: Sie gibt ein zusätzliches `</li>` für das übergeordnete Element aus, bevor sie auf derselben Ebene wieder geöffnet wird, was zu fehlerhaftem HTML führen kann. Die Erkennung von Codeblöcken verwendet `line.strip().startswith('```')`, was etwas nachgiebiger ist als nötig. Insgesamt ist es ein solider Versuch mit einigen Randfallproblemen bei der Listenbehandlung.

Bewertungsdetails anzeigen

Korrektheit

Gewichtung 35%
65

Antwort A behandelt Überschriften, Absätze, Codeblöcke und grundlegende Inline-Formatierungen korrekt. Die Logik zum Einrücken von Listen weist jedoch einen Fehler auf: Beim Schließen verschachtelter Listen gibt sie ein zusätzliches `</li>` für das übergeordnete Element aus, was zu fehlerhaftem HTML führen kann. Der Inline-Regex-Ansatz kann auch über unbeabsichtigte Grenzen für nicht geschlossene Marker wie `*kursiv` hinausgehen und potenziell mit einem späteren `*` im Text übereinstimmen.

Vollstandigkeit

Gewichtung 20%
80

Alle erforderlichen Funktionen sind implementiert: Überschriften (h1-h6), ungeordnete Listen mit Verschachtelung, Codeblöcke mit ignoriertem Sprachspezifizierer, Absätze und alle drei Inline-Stile (fett+kursiv, fett, kursiv). Die Hauptprobe aus der Aufgabe wird behandelt.

Codequalitat

Gewichtung 20%
70

Der Code ist gut organisiert mit klaren Hilfsfunktionen und guten Kommentaren. Die Docstring ist hilfreich. Die Logik zur Listenverwaltung ist jedoch etwas komplex und weist subtile Fehler auf. Der Regex-Ansatz für die Inline-Analyse ist einfacher, aber weniger robust. Die Funktion `close_lists_to` ist definiert, wird aber in der Hauptschleife nicht verwendet (nur `close_all_lists` wird verwendet).

Praktischer Nutzen

Gewichtung 15%
65

Die Lösung funktioniert für gängige Fälle und enthält einen ausführbaren `__main__`-Block mit den Beispiel-Eingaben, was für Tests hilfreich ist. Die Fehler bei der Listenverschachtelung und die potenziellen Inline-Regex-Probleme reduzieren jedoch die praktische Zuverlässigkeit für Randfälle.

Befolgung der Anweisungen

Gewichtung 10%
75

Folgt allen angegebenen Anweisungen: korrekte Funktionssignatur, unterstützt alle erforderlichen Funktionen, behandelt die angegebene Reihenfolge der Inline-Priorität, implementiert keine nicht unterstützten Funktionen und behandelt nicht geschlossene Tags (wenn auch unvollkommen mit Regex). HTML-Maskierung wird angewendet.

Bewertungsmodelle OpenAI GPT-5.2

Gesamtpunktzahl

59

Gesamtkommentar

Implementiert die erforderlichen Blocktypen und Inline-Formatierungen mit einer einfachen Zustandsmaschine und Regex-basierten Inline-Ersetzungen und maskiert HTML korrekt, auch innerhalb von Codeblöcken. Die Listen-Generierung weist jedoch mehrere strukturelle Probleme auf: Sie gibt </li>- und </ul>-Sequenzen aus, die zu ungültigen Verschachtelungen führen können, behandelt Einrückungen falsch (zusätzliche </li>) und kann verschachtelte <ul> öffnen, ohne sich innerhalb eines übergeordneten <li> zu befinden. Die Inline-Verarbeitung mittels Regex ist nicht robust für knifflige/fehlerhafte Fälle (z. B. überlappende Marker wie **fett *kursiv***) und unterstützt keine rekursive Verschachtelung von Inline-Elementen, wie es erforderlich/erwartet wird.

Bewertungsdetails anzeigen

Korrektheit

Gewichtung 35%
48

Korrekt für einfache Überschriften/Absätze/Codeblöcke und einfache Hervorhebungen, aber Listenverschachtelung/-schluss ist häufig ungültig (zusätzliche </li>, Probleme bei der Platzierung von verschachtelten <ul>) und Regex-Hervorhebungen können überlappende/verschachtelte Fälle falsch behandeln (z. B. **fett *kursiv***).

Vollstandigkeit

Gewichtung 20%
68

Deckt alle angeforderten Feature-Kategorien ab, aber die Unterstützung für Listenverschachtelung ist unzuverlässig und die Inline-Verschachtelung wird über einfache Muster hinaus nicht wirklich unterstützt, was die effektive Vollständigkeit verringert.

Codequalitat

Gewichtung 20%
62

Lesbar und modular, aber die Listen-Stack-Logik ist kompliziert mit einem ungenutzten/ineffektiven Helfer (close_lists_to) und fragilen Zustandsübergängen; starke Regex-Ersetzungen verringern Klarheit/Robustheit.

Praktischer Nutzen

Gewichtung 15%
58

Nützlich für einfache Eingaben, aber ungültiges Listen-HTML und Hervorhebungs-Randfälle schränken die reale Nutzbarkeit für den angegebenen Teil ein.

Befolgung der Anweisungen

Gewichtung 10%
70

Implementiert den angeforderten Teil und ignoriert den Sprachspezifizierer für Codeblöcke; die Anforderung an die Robustheit für knifflige Inline-Eingaben und die korrekte Listenverschachtelung/-terminierung wird jedoch nicht gut erfüllt.

Bewertungsmodelle Google Gemini 2.5 Pro

Gesamtpunktzahl

63

Gesamtkommentar

Antwort A präsentiert eine gut strukturierte, zustandsautomatenbasierte Lösung, die die meisten Blockelemente wie Überschriften, Absätze und Codeblöcke korrekt verarbeitet. Sein Ansatz zur Analyse von Inline-Elementen mittels sequenzieller regulärer Ausdruckssubstitutionen ist jedoch grundlegend fehlerhaft. Diese Methode behandelt verschachtelte Inline-Stile (z. B. Fett, das Kursiv enthält) nicht korrekt, was ein erhebliches Korrektheitsproblem darstellt. Die Listenlogik ist ebenfalls komplex und weniger robust als die Alternative.

Bewertungsdetails anzeigen

Korrektheit

Gewichtung 35%
50

Die Lösung analysiert verschachtelte Inline-Stile nicht korrekt. Zum Beispiel wird `**fett *kursiv* fett**` falsch gerendert, da die sequenziellen `re.sub`-Aufrufe auf der Zwischenzeichenfolge mit neu hinzugefügten HTML-Tags operieren. Dies ist ein erheblicher Korrektheitsfehler in der Parsing-Logik.

Vollstandigkeit

Gewichtung 20%
80

Die Lösung versucht, alle erforderlichen Funktionen zu implementieren. Da die Implementierung verschachtelter Inline-Stile jedoch fehlerhaft ist, kann sie funktional nicht als vollständig betrachtet werden.

Codequalitat

Gewichtung 20%
60

Der Code ist im Allgemeinen gut strukturiert mit Hilfsfunktionen und Zustandsvariablen. Die Wahl einer sequenziellen Regex-Substitution für die Analyse ist jedoch eine schlechte algorithmische Wahl für dieses Problem und zeigt ein mangelndes Verständnis seiner Fallstricke. Die Listenlogik ist ebenfalls ziemlich verschlungen.

Praktischer Nutzen

Gewichtung 15%
50

Die fehlerhafte Behandlung eines gängigen Anwendungsfalls (verschachtelte Inline-Stile) durch den Parser schränkt seinen praktischen Wert stark ein. Er wäre nicht zuverlässig für die Konvertierung von Markdown-Dokumenten aus der realen Welt.

Befolgung der Anweisungen

Gewichtung 10%
100

Die Lösung hält sich an alle Anweisungen in der Eingabeaufforderung, einschließlich der Funktionssignatur, des zu unterstützenden spezifischen Markdown-Teils und des Ausgabeformats.

Antwort B: OpenAI GPT-5.4

def markdown_to_html(markdown_text: str) -> str: import re from html import escape lines = markdown_text.splitlines() out = [] paragraph_lines = [] list_stack = [] i = 0 in_code_block = False code_lines = [] def parse_inline(text: str) -> str: parts = [] i = 0 n = len(text) while i < n: if text.startswith('***', i): j = text.find('***', i + 3) if j != -1: inner = parse_inline(text[i + 3:j]) parts.append(f'<strong><em>{inner}</em></strong>')...

Vollstandige Antwort anzeigen

def markdown_to_html(markdown_text: str) -> str: import re from html import escape lines = markdown_text.splitlines() out = [] paragraph_lines = [] list_stack = [] i = 0 in_code_block = False code_lines = [] def parse_inline(text: str) -> str: parts = [] i = 0 n = len(text) while i < n: if text.startswith('***', i): j = text.find('***', i + 3) if j != -1: inner = parse_inline(text[i + 3:j]) parts.append(f'<strong><em>{inner}</em></strong>') i = j + 3 continue if text.startswith('**', i): j = text.find('**', i + 2) if j != -1: inner = parse_inline(text[i + 2:j]) parts.append(f'<strong>{inner}</strong>') i = j + 2 continue if text.startswith('*', i): j = text.find('*', i + 1) if j != -1: inner = parse_inline(text[i + 1:j]) parts.append(f'<em>{inner}</em>') i = j + 1 continue parts.append(escape(text[i])) i += 1 return ''.join(parts) def flush_paragraph(): nonlocal paragraph_lines if paragraph_lines: text = ' '.join(line.strip() for line in paragraph_lines) out.append(f'<p>{parse_inline(text)}</p>') paragraph_lines = [] def close_lists_to(level: int): while len(list_stack) > level: out.append('</li>') out.append('</ul>') list_stack.pop() def handle_list_item(indent_spaces: int, content: str): level = indent_spaces // 2 if indent_spaces % 2 != 0: return False if level > len(list_stack): if level != len(list_stack) + 1: return False out.append('<ul>') list_stack.append(True) elif level < len(list_stack): close_lists_to(level) out.append('</li>') else: if list_stack: out.append('</li>') else: out.append('<ul>') list_stack.append(True) while len(list_stack) < level + 1: out.append('<ul>') list_stack.append(True) out.append(f'<li>{parse_inline(content)}') return True while i < len(lines): line = lines[i] if in_code_block: if line.startswith('```'): out.append(f'<pre><code>{escape("\n".join(code_lines))}</code></pre>') code_lines = [] in_code_block = False else: code_lines.append(line) i += 1 continue if line.startswith('```'): flush_paragraph() close_lists_to(0) in_code_block = True code_lines = [] i += 1 continue if not line.strip(): flush_paragraph() close_lists_to(0) i += 1 continue header_match = re.match(r'^(#{1,6})\s+(.*)$', line) if header_match: flush_paragraph() close_lists_to(0) level = len(header_match.group(1)) content = parse_inline(header_match.group(2).strip()) out.append(f'<h{level}>{content}</h{level}>') i += 1 continue list_match = re.match(r'^( *)(- )(.+)$', line) if list_match: flush_paragraph() indent = len(list_match.group(1)) content = list_match.group(3) if handle_list_item(indent, content): i += 1 continue if list_stack: close_lists_to(0) paragraph_lines.append(line) i += 1 if in_code_block: out.append(f'<pre><code>{escape("\n".join(code_lines))}</code></pre>') flush_paragraph() close_lists_to(0) return '\n'.join(out)

Ergebnis

#1 | Sieger

Siegstimmen

3 / 3

Durchschnittsscore

79

Gesamtpunktzahl

75

Gesamtkommentar

Antwort B implementiert einen zeichenweisen Inline-Parser, der verschachtelte Inline-Elemente korrekt verarbeitet und bei nicht geschlossenen Markierungen anstandslos auf literale Zeichen zurückfällt. Dies ist ein robusterer Ansatz als Regex für die Inline-Analyse. Die Listenbehandlungslogik ist sauberer und korrekter. Die Codeblockerkennung verwendet `line.startswith('```')`, was gemäß Spezifikation korrekt ist. Die Funktion `handle_list_item` hat im `else`-Zweig ein Logikproblem, da sie nur `<ul>` anhängt, wenn `list_stack` leer ist, aber die nachfolgende while-Schleife den Fall behandelt, dass level > len(list_stack), was sie leicht redundant, aber funktional macht. Der Inline-Parser maskiert einzelne Zeichen, die nicht Teil von Markdown-Mustern sind, korrekt und bietet eine ordnungsgemäße HTML-Maskierung. Insgesamt ist dies eine robustere und korrektere Implementierung.

Bewertungsdetails anzeigen

Korrektheit

Gewichtung 35%
75

Antwort B behandelt alle Blockelemente korrekt. Der zeichenweise Inline-Parser behandelt nicht geschlossene Markierungen korrekt, indem er auf literale Zeichen zurückfällt. Die Listenbehandlung ist im Allgemeinen korrekt, obwohl der else-Zweig von `handle_list_item` ein geringfügiges Logikproblem aufweist. Die Codeblockerkennung ist korrekt. Insgesamt korrekter als A bei den wichtigsten Robustheitsanforderungen.

Vollstandigkeit

Gewichtung 20%
80

Alle erforderlichen Funktionen sind implementiert: Überschriften, ungeordnete Listen mit Verschachtelung, Codeblöcke, Absätze und alle drei Inline-Stile. Die Implementierung deckt alle im Aufgabenprompt spezifizierten Funktionen ab.

Codequalitat

Gewichtung 20%
75

Der Code ist gut organisiert mit klarer Trennung der Zuständigkeiten. Der zeichenweise Inline-Parser ist ausgefeilter und korrekter. Die Funktion `handle_list_item` kapselt die Listenlogik gut. Kleines Problem: Der else-Zweig in `handle_list_item` hat redundante Logik. Insgesamt sauberer und wartungsfreundlicher.

Praktischer Nutzen

Gewichtung 15%
70

Die Lösung ist praktisch und behandelt die gängigen Fälle gut. Die Robustheit des Inline-Parsers für nicht geschlossene Markierungen macht ihn im realen Einsatz zuverlässiger. Kein `__main__`-Block, aber die Funktion ist in sich geschlossen und importierbar.

Befolgung der Anweisungen

Gewichtung 10%
75

Folgt allen spezifizierten Anweisungen: korrekte Funktionssignatur, unterstützt alle erforderlichen Funktionen, behandelt die angegebene Inline-Prioritätsreihenfolge, implementiert keine nicht unterstützten Funktionen und behandelt explizit nicht geschlossene Inline-Tags, indem sie als literale Zeichen behandelt werden. HTML-Maskierung wird pro Zeichen angewendet.

Bewertungsmodelle OpenAI GPT-5.2

Gesamtpunktzahl

71

Gesamtkommentar

Implementiert eine klarere Zustandsmaschine für Codeblöcke, Überschriften, Listen und Absätze und verwendet einen rekursiven Inline-Parser, der die Priorität (***) dann (**) dann (*) beachtet und gleichzeitig robust gegenüber nicht geschlossenen Markierungen ist (bleiben als Literal). HTML-Escaping wird sicher auf Zeichenebene für normalen Text und über html.escape für Codeblöcke gehandhabt. Die Listenbehandlung ist näher an A, aber immer noch unvollkommen: Einrückungssprünge und einige Schließ-/Öffnungssequenzen können fragwürdige HTML-Ausgaben ergeben, und es wird nicht in allen Fällen klar sichergestellt, dass verschachtelte <ul> innerhalb eines übergeordneten <li> erscheinen. Insgesamt ist es robuster und spec-treuer als A.

Bewertungsdetails anzeigen

Korrektheit

Gewichtung 35%
66

Korrekt für Überschriften/Absätze/Codeblöcke; Inline-Hervorhebungen werden mit richtiger Priorität und Rekursion geparst und sind robust gegenüber nicht geschlossenen Markierungen. Die Listenverschachtelung ist in allen Fällen noch nicht vollständig korrekte HTML (verschachtelte <ul> nicht immer unter einem offenen <li>, Randfälle mit Ebenenwechsel), aber im Allgemeinen näher am Spec als A.

Vollstandigkeit

Gewichtung 20%
76

Deckt alle spezifizierten Blöcke und alle drei Inline-Stile mit Verschachtelungsunterstützung durch Rekursion ab; die verbleibende Lücke sind hauptsächlich Randfälle der Listen-HTML-Struktur.

Codequalitat

Gewichtung 20%
72

Gut strukturiert mit Hilfsfunktionen und einem deterministischen Inline-Parser; die Listenbehandlung ist etwas komplex, aber kohärenter als A, und das Escaping wird konsistent gehandhabt.

Praktischer Nutzen

Gewichtung 15%
69

Praktischer nutzbar dank robuster Inline-Handhabung und sicherem Escaping; verbleibende Unvollkommenheiten bei der Listenverschachtelung schränken die Zuverlässigkeit immer noch ein, aber weniger als bei A.

Befolgung der Anweisungen

Gewichtung 10%
80

Folgt den Subset-Anforderungen genau, einschließlich Priorität und Behandlung von fehlerhaften Inlines, und deaktiviert Inline-Parsing innerhalb von Codeblöcken korrekt; geringfügige Abweichungen betreffen hauptsächlich strenge Details der Listen-HTML-Verschachtelung.

Bewertungsmodelle Google Gemini 2.5 Pro

Gesamtpunktzahl

91

Gesamtkommentar

Antwort B ist eine ausgezeichnete und robuste Lösung. Ihre wichtigste Stärke liegt in der `parse_inline`-Funktion, die einen rekursiven Abstiegsansatz verwendet, um Inline-Stile korrekt zu verarbeiten, einschließlich komplexer Verschachtelungen und Vorrangregeln. Dies ist eine weitaus geeignetere und leistungsfähigere Technik als die Regex-Substitution, die von Antwort A verwendet wird. Die Block-Level-Analyse ist ebenfalls sehr solide, mit robusteren Prüfungen für die Einrückung von Listen. Das einzige geringfügige stilistische Problem ist die Platzierung von Imports innerhalb der Funktion, aber dies beeinträchtigt nicht die überlegene Korrektheit und Qualität der Implementierung.

Bewertungsdetails anzeigen

Korrektheit

Gewichtung 35%
90

Die Lösung ist hochgradig korrekt. Die rekursive `parse_inline`-Funktion verarbeitet Vorrang und Verschachtelung aller Inline-Stile korrekt, was ein schwieriger Teil der Aufgabe ist. Die Block-Level-Analyse, einschließlich der Listenverschachtelung, ist ebenfalls korrekt und robust implementiert.

Vollstandigkeit

Gewichtung 20%
100

Alle angegebenen Funktionen, einschließlich Überschriften, Absätze, Codeblöcke, verschachtelte Listen und alle drei Inline-Stilvarianten mit korrektem Vorrang und Verschachtelung, sind vollständig und korrekt implementiert.

Codequalitat

Gewichtung 20%
85

Der Code ist gut organisiert und zeigt ein starkes Verständnis von Parsing-Techniken. Die Verwendung einer rekursiven Funktion für die Inline-Analyse ist eine ausgezeichnete und geeignete algorithmische Wahl. Der Code ist lesbar und robust. Ein kleiner Abzug erfolgt für die unkonventionelle Platzierung von Imports innerhalb der Funktion.

Praktischer Nutzen

Gewichtung 15%
85

Diese Lösung ist robust und korrekt genug, um für ihre angegebene Teilmenge von Markdown verwendet zu werden. Ihre solide algorithmische Grundlage bedeutet, dass sie zuverlässig um weitere Funktionen erweitert werden könnte, was ihr einen hohen praktischen Wert verleiht.

Befolgung der Anweisungen

Gewichtung 10%
100

Die Lösung folgt perfekt allen Anweisungen in der Eingabeaufforderung, implementiert die erforderliche Funktion mit der korrekten Signatur und unterstützt den exakt angeforderten Funktionsumfang.

Vergleichsuebersicht

Fur jede Aufgabe und Diskussion wird die Endrangfolge per Richter-Rangaggregation bestimmt (Durchschnittsrang + Borda-Tie-Break). Der Durchschnittsscore wird als Referenz angezeigt.

Bewerter: 3

Siegstimmen

0 / 3

Durchschnittsscore

64
Diese Antwort ansehen

Siegstimmen

3 / 3

Durchschnittsscore

79
Diese Antwort ansehen

Bewertungsergebnisse

Bewertungsmodelle Google Gemini 2.5 Pro

Warum diese Seite gewann

Antwort B ist der klare Gewinner aufgrund ihrer überlegenen Korrektheit und Robustheit, insbesondere bei der Handhabung von Inline-Markdown-Elementen. Antwort A verwendet eine sequentielle Regex-Substitutionsmethode, die bei verschachtelten Inline-Stilen fehlschlägt, ein kritischer Mangel für einen Parser. Im Gegensatz dazu implementiert Antwort B einen ordnungsgemäßen rekursiven Parser für Inline-Elemente, der Verschachtelung und Vorrang korrekt wie erforderlich behandelt. Darüber hinaus ist die Listenverarbeitungslogik von Antwort B robuster, mit expliziten Prüfungen auf gültige Einrückungen, was sie insgesamt zu einer qualitativ hochwertigeren und zuverlässigeren Lösung macht.

Bewertungsmodelle OpenAI GPT-5.2

Warum diese Seite gewann

Antwort B gewinnt, da sie einen korrekteren und robusteren Inline-Parser (korrekte Präzedenz, Rekursion und ordnungsgemäße Behandlung von nicht geschlossenen Markierungen) und generell eine sauberere Block-Analyse bietet. Obwohl beide Probleme mit der HTML-Struktur von Listenverschachtelungen haben, ist die Logik zum Schließen/Öffnen von Listen bei A fehleranfälliger und die Inline-Verarbeitung per Regex ist für knifflige verschachtelte/überlappende Hervorhebungsmuster weniger robust, was B zum am höchsten gewichteten Kriterium (Korrektheit) und insgesamt besser macht.

Warum diese Seite gewann

Antwort B gewinnt hauptsächlich aufgrund von Korrektheit und Robustheit. Der zeichenweise Inline-Parser verarbeitet nicht geschlossene Marker korrekt (behandelt sie als reinen Text) und unterstützt verschachtelte Inline-Elemente, was eine Schlüsselanforderung ist. Der Regex-basierte Inline-Parser von Antwort A kann bei nicht geschlossenen Markern fehlschlagen, indem er über unbeabsichtigte Grenzen hinweg passt. Antwort B hat auch eine sauberere Logik für Listen und eine ordnungsgemäße HTML-Maskierung pro Zeichen im Inline-Parser. Während beide Antworten einige Randfälle bei der Listenverwaltung aufweisen, ist der Gesamtansatz von Antwort B robuster und korrekter für die angegebenen Anforderungen, insbesondere für das Kriterium der Robustheit der Inline-Analyse, das in der Aufgabe ausdrücklich genannt wird.

X f L