„Bildschirmgr%C3%B6%C3%9Fe“ - wie bitte?

[Rolf B]

Hallo,

die "Im Forum fragen" Funktion des Wiki hatte einen blöden Bug, der dem Forum den Artikelnamen doppelt prozentcodiert übermittelte. Die Folge war, dass die betreffenden Zeichen im Betreff des Postings dann prozentcodiert angezeigt wurden, so wie „Bildschirmgr%C3%B6%C3%9Fe“ statt „Bildschirmgröße“ im Betreff dieses Artikels.

(Hinweis: Ich habe versucht, Mudguards Hinweis einzuarbeiten)

Was für mich ein Anlass ist, darüber zu sinnieren, dass Maskierungen zwecks Kontextwechsel gut gemeint sein können, aber immer mit der nötigen Prise Salz genossen werden müssen. Und ich kann ein bisschen davon erzählen, was beim Makeover so alles passiert.

Die fragliche Stelle hat eine längere Historie. Der Autor dieser Funktion hatte ursprünglich den Text der h1-Überschrift der Seite herangezogen, um den Link zum Forum zu generieren. Diese wurde in die Pfadteile zerlegt, die Teile mit encodeURIComponent %-codiert und alles zusammen mit "https://wiki.selfhtml.org/wiki/" zusammengefügt. So weit, so gut, aber dies wurde dann mittels $.param^[1] zu der URL montiert, mit der das Forum zum Erstellen des neuen Beitrags aufgefordert wurde. Und $.param führt eine eigene %-Codierung durch, und damit wurden die Maskierungs-Prozentzeichen maskiert.

Das heißt also: Im Artikelnamen steht "größe". Frage ich das aus der URL der Seite ab, bekomme ich vom Location API die %-codierten UTF-8 Bytes: "gr%C3%B6%C3%9Fe". Speichere ich das in $.params (oder URLSearchParams), codiert der mir die Prozentzeichen nochmal und am Ende steht "gr%25C3%25B6%25C3%259Fe" im "Fragen"-Link. Wird der Link geklickt, empfängt CForum "gr%25C3%25B6%25C3%259Fe" und decodiert das zu "gr%C3%B6%C3%9Fe". Richtig wäre hingegen, "gr%C3%B6%C3%9Fe" zu senden, so dass CForum daraus "größe" machen kann.

Was ich nicht weiß: das war 2016, und die damalige CForum-Version hat das möglicherweise so gebraucht. Oder unter der Hand nachgebessert. Man findet im Forum auch nur ganz wenige Postings, die Kandidaten für den Fehler sind, und die meisten enthalten korrekte Sonderzeichen. Es ist also auch nicht auszuschließen, dass der Fehler anfangs gar nicht auffiel, aber Matthias (Sch.) meinte, das sei eigentlich immer so gewesen und er hätte die Postings editiert.

Jedenfalls gab's einige Weiterentwicklungen dieser Stelle, die Permalinks kamen hinzu, aber der überzählige Kontextwechsel blieb. Es ist auch gar nicht so einfach, ihn zu vermeiden, weil es einfach kein Mediawiki- oder Browser-API zu geben scheint, das die URL der Seite uncodiert liefert.

Für den Namen der angefragten Seite geht's noch, dafür gibt es ein API, aber wenn man die URL nicht an Mediawiki vorbei aus dem Seitennamen bauen will, ist das Ergebnis immer %-codiert. Woraus folgt, dass ich einen vom System netterweise angebotenen Kontextwechsel gleich wieder rückgängig machen muss, damit der dann wieder vorgenommen wird:

const headingparts = mw.config.get('wgTitle').split('/'),
      frage_parms = new URLSearchParams([
        [ 'message[subject]', 
          'Frage zum Wiki-Artikel „' + headingparts[headingparts.length-1] + '“'
        ],
        [ 'message[problematic_site]', 
          decodeURI(location.origin + location.pathname)
        ],
        ...
      ]);

(Im Makeover, der noch im Testwiki steckt, kommt da mw.util.getUrl hin, aber dafür muss ich Abhängigkeiten zu mw.util beachten und dafür habe ich im Hauptwiki noch nicht die Infrastruktur)

(Durch Einsatz von wgTitle statt wgPageName werden auch Artikel mit Leerstellen im Lemma korrekt übergeben)

(Ja, statt [headingparts.length-1] könnte ich .at(-1) nehmen - aber das ist ES2022 und selbst für die die letzte Compatibility-Liste von Mediawiki zu neu. Und ich will nicht anfangen, das Wiki zu polyfillen)

Rolf

---

1. die jQuery-Antwort von 2007 auf eine Frage, die nativ erst 2014 mit URLSearchParams beantwortet wurde ↩︎