Klammern in Markdown-Links [Updated]

Markdown bietet ein sehr gut zu handhabendes Markup für Links in der Form [Text](URL "Titel"), wobei der Titel auch weggelassen werden kann.

Nicht ganz so einfach wird es, wenn die URL schließende Klammern enthält1. Dann wird die schließende Klammer in der URL als die abschließende Klammer des Link-Markups interpretiert, was eigentlich nie zu brauchbaren Ergebnissen führt.

Update: Das Problem scheint ausschließlich bei meinem Lieblingstexteditor Editorial aufzutreten

Beispielsweise wird dann aus dem syntaktisch und inhaltlich zutreffenden Markup

[Paterson der Film](https://de.wikipedia.org/wiki/Paterson_(Film))

das zwar syntaktisch zutreffende, aber inhaltlich falsche Markup

[Paterson der Film](https://de.wikipedia.org/wiki/Paterson_(Film)

was zu einem Fehler führt, weil dies auf die nicht existierende Seite https://de.wikipedia.org/wiki/Paterson_(Film verlinkt

Lösung: Prozentdarstellung

Das Problem lässt sich lösen, indem man die schließende Klammer in die sogenannte Prozentdarstellung überträgt, d.h. aus ) wird %29:

[Paterson der Film](https://de.wikipedia.org/wiki/Paterson_(Film&29)

Der von mir – z.B. zum Schreiben dieses Artikels – verwendete Editor Editorial kommt mit dieser Darstellung klar. Der Editor Drafts hingegen, mag diese Form gar nicht und möchte beide Klammern ersetzt bekommen:

[Paterson der Film](https://de.wikipedia.org/wiki/Paterson_&28Film&29)

Beide Editoren vertragen es auch, wenn man statt &28 und &29 die Schreibweise #28 und #29 verwendet oder sogar beide mischt.

Wahrscheinlich nur Editorial betroffen (Update 31.10.2017)

Editorial ist unter iOS mein bevorzugter Texteditor für die Erstellung von Markdown. Daher bin ich auch beim Arbeiten mit Editorial auf das Problem gestoßen. Vor ein paar Wochen habe ich begonnen testweise parallel mit Ulysses zu arbeiten2.

Dort trat das Problem nicht auf. Zunächst ging ich – irrigerweise – davon aus, dass es daran liegt, dass Ulysses in Markdown bei Links den Referenz-Stil nutzt. Als ich mich für einen Artikel zum Thema intensiver mit dem Problem beschäftigte, fiel mir auf, dass Ulysses sehr wohl in der Lage sein muss, entsprechendes Markup im Inline-Stil zutreffend zu parsen: Dateien mit entsprechenden Inline-Links werden zutreffend geparst und in den Referenz-Stil umgesetzt.

In der Folge habe ich ein paar Exemplare aus meinen Zoo von iOS-Texteditoren auf das Problem losgelassen:

  • 1Writer: kein Fehler bei Darstellung in der Bearbeitungsansicht (nur minimale Syntaxdarstellung, die nur verlinkten Text hervorhebt), fehlerfreie Vorschau und fehlerfreies HTML
  • Drafts: unzutreffend Darstellung in der Bearbeitungsansicht (Markdown nach erster schließender Klammer nicht “leichter” dargestellt), fehlerfreie Vorschau und fehlerfreies HTML
  • IA Writer: unzutreffend Darstellung in der Bearbeitungsansicht (Markdown nach erster schließender Klammer nicht “leichter” dargestellt), fehlerfreie Vorschau und fehlerfreies HTML (mir aber etwas zu bloated)
  • Editorial: wie oben beschrieben betroffen; unzutreffend Darstellung in der Bearbeitungsansicht (Markdown nach erster schließender Klammer nicht “leichter” dargestellt), fehlerhafte Vorschau und fehlerhaftes HTML
  • Texttastic: kein Fehler bei Darstellung in der Bearbeitungsansicht (nur minimale Syntaxdarstellung, die nur verlinkten Text hervorhebt), fehlerfreie Vorschau und fehlerfreies HTML

  1. Auf den ersten Blick fragt man sich, ob es tatsächlich viele URLs mit Klammern gibt. Ja, es gibt eine sehr große Quelle mit relativ vielen ensprechenden URLs: Die Wikipedia.
    Um die verschieden gleichlaufenden Lemma unterscheiden zu können, wird hinter das Lemma ein Schlagwort in Klammern angefügt, was sich dann genauso in der URL wiederfindet. Als Beispiel sei der Ort Paterson (Paterson (New Jersey) https://de.wikipedia.org/wiki/Paterson_(New_Jersey)) und der gleichnamige Film (Paterson (Film) https://de.wikipedia.org/wiki/Paterson_(Film)) genannt, wobei es noch mehr Bedeutungen von Paterson gibt
  2. Editorial ist weiterhin meine Nummer 1. 

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Kommentare abonnieren

Es erfolgt keine Weitergabe von Daten an externe Dienste wie WordPress.com.

eMail-Benachrichtigung bei weiteren Kommentaren.
Auch möglich: Abo ohne Kommentar.