Zurück zum Blog
Community

PTT-Bildlinks öffnen sich nicht automatisch? Ich habe den Quellcode von term.ptt.cc und PttChrome gelesen — es gibt 4 verschiedene Regelwerke

Veröffentlicht am12 min read
Teilen

Der gleiche Link, einmal Bild, einmal nur Text — woran liegt das?

Wer regelmäßig in deutschsprachigen Tech-Foren wie Heise oder Computerbase unterwegs ist, kennt das Gefühl: Ein Bildlink wird im einen Forum automatisch eingebettet, im anderen bleibt nur eine nackte URL übrig. Bei PTT, Taiwans größtem textbasiertem Forum, ist dieses Chaos noch eine Nummer größer — und ich habe den Quellcode der wichtigsten PTT-Clients gelesen, um herauszufinden, warum.

Ehrlich gesagt war meine erste Vermutung, dass ich einfach das falsche Linkformat gepostet hatte. Falsch gedacht. Das eigentliche Problem: Derselbe Link wird in der PTT-App automatisch zum Thumbnail, während er in der Webversion nur als Zeichenkette stehen bleibt. Kein Zufall, kein Tippfehler — hinter dem Namen „PTT" verstecken sich mindestens vier komplett unterschiedliche Client-Programme, jedes mit einer eigenen Logik, ob eine URL zum Bild wird oder nicht. Manche prüfen nur die Dateiendung, andere nur die Domain-Whitelist, wieder andere verlangen beides gleichzeitig. Und dann gibt es noch einen Fall, der die Dateiendungsprüfung komplett überspringt und einfach darauf wettet, dass der gepostete Link von Imgur stammt — dazu gleich mehr.

Im PTT-ask-Forum lief im Oktober 2025 eine Diskussion genau zu diesem Thema. Ein Nutzer schrieb, dass term.ptt.cc früher beim Überfahren eines Imgur-Links automatisch eine Bildvorschau eingeblendet habe — das habe aber vor rund einem halben Jahr aufgehört zu funktionieren. Genau das ist der Punkt, den viele übersehen: Dieselbe Client-Software, derselbe Bild-Host, aber die Regeln ändern sich mit der Zeit, ohne dass irgendwo offiziell etwas dazu verlautbart wird. Statt mich auf Hörensagen zu verlassen, habe ich den Quellcode der wichtigsten PTT-Clients direkt ausgegraben. Jede Zeile in diesem Artikel lässt sich auf eine konkrete Codestelle zurückführen.

Fünf Wege, ein PTT-Bild zu betrachten — nicht nur „PTT"

Bevor die Vergleichstabellen weiter unten überhaupt Sinn ergeben, muss klar sein: „PTT" ist kein einzelnes Programm, sondern ein Ökosystem aus mindestens fünf verschiedenen Zugangswegen.

  • Reine BBS-Textterminals (PCMan, Welly): Verstehen nur Text. Bildlinks bleiben für immer eine Zeichenkette, es gibt keinerlei automatische Bilddarstellung.
  • www.ptt.cc-Webversion: Beim Laden der Artikelseite wandelt der Server passende URLs serverseitig direkt in <img>-Tags um.
  • term.ptt.cc: Ein webbasierter Terminal-Emulator. Beim Überfahren eines Links mit der Maus erscheint eine Bildvorschau, gesteuert durch clientseitiges JavaScript.
  • PttChrome: Ein traditionsreicher Browser-Telnet-Client, der Bilder direkt in die Artikelansicht einbettet.
  • Mobile Apps (Mo PTT, JPTT, PiTT, BePTT): Wandeln Links direkt in Thumbnails um — allesamt Closed-Source-Software, deren Verhalten sich nur aus Community-Berichten und offiziellen Beschreibungen rekonstruieren lässt.

Der Unterschied zwischen den ersten beiden und den letzten drei Kategorien ist größer, als man auf den ersten Blick vermutet.

Vier Regelwerke im direkten Quellcode-Vergleich

www.ptt.cc-Webversion: Serverseitige Prüfung, Dateiendung zählt — WebP fällt durch

Das Web-Frontend von www.ptt.cc heißt pttweb, der Quellcode liegt öffentlich im GitHub-Repository ptt/pttweb. Zuständig für die Umwandlung von URLs in Bilder ist die Datei richcontent/url_based_finder.go, die eine Liste sequenziell geprüfter Regeln enthält:

var defaultUrlPatterns = []*UrlPattern{
    newUrlPattern(`^https?://(?:www\.youtube\.com/watch\?(?:.+&)*v=|youtu\.be/)([\w\-]+)`, handleYoutube),
    newUrlPattern(`^https?://i\.imgur\.com/([\w]+)\.((?i)png|jpeg|jpg|gif)$`, handleImgurSingle),
    newUrlPattern(`^http://picmoe\.net/d\.php\?id=(\d+)`, handlePicmoe),
    newUrlPattern(`\.(?i:png|jpeg|jpg|gif)$`, handleGenericImage),
}

Entscheidend ist die letzte Zeile. Die ersten drei Regeln gelten nur für YouTube, Imgur und picmoe.net — Regel vier ist der eigentliche Clou: Jede URL, die auf .png, .jpeg, .jpg oder .gif endet (Groß-/Kleinschreibung egal), wird unabhängig vom Host als <img>-Tag dargestellt. Die pttweb-Logik prüft also die Dateiendung, nicht die Domain — genau umgekehrt zu term.ptt.cc, wie wir gleich sehen werden.

Eine Einschränkung gibt es: Die URL muss exakt mit der Dateiendung enden, ein Query-String dahinter verhindert den Treffer (das Regex fixiert das Ende mit $). Liefert ein Bild-Host also einen Direktlink im Format xxx.jpg?token=abc123, greift die letzte Regel nicht. Und .webp fehlt in der Liste komplett — selbst ein echter WebP-Direktlink wird auf der www.ptt.cc-Webversion niemals automatisch eingebettet, es bleibt bei einer nackten URL. Dieses Detail habe ich in keinem anderen Überblick zu PTT-Bildformaten so klar dokumentiert gesehen.

term.ptt.cc: Domain-Whitelist zuerst, Dateiendung als zweite Hürde

Der Quellcode von term.ptt.cc liegt im GitHub-Repository ptt/ptt-term — ein webbasiertes BBS-Terminal, das per WebSocket verbindet. Das Modul für die Bildvorschau beim Hovern heißt src/plugins/media_previewer/image_preview_util.js und enthält eine fest codierte Liste vertrauenswürdiger Domains:

export const INITIAL_TRUSTED_IMAGE_DOMAINS = [
  "imgur.com", "imgtok.com", "meee.com.tw", "duk.tw",
  "upload.cc", "ibb.co", "imgbb.com", "postimg.cc",
  "twimg.com", "gyazo.com",
];

Auffällig: urusai.cc, vgy.me und lpic.cc stehen nicht auf dieser Liste. Im PTT-ask-Forum berichten aber Nutzer, dass urusai.cc und vgy.me bei ihnen problemlos automatisch geöffnet werden. Widerspruch? Nicht ganz — im Code existiert zusätzlich eine Funktion namens parseTrustedDomains, die belegt: Die Whitelist lässt sich in den persönlichen Einstellungen erweitern. Die Standardliste mit zehn Einträgen ist nur die Out-of-the-Box-Konfiguration, nicht das Gesamtbild. Der zitierte Nutzer hat urusai.cc also höchstwahrscheinlich selbst in seine persönliche Konfiguration eingetragen — das ist keine Regel, die für alle gilt. Eine Verwechslungsgefahr, die man leicht als „systemweite Regel" fehlinterpretiert.

Die Prüflogik hat zwei Ebenen: Imgur besitzt ein eigenes Regex, das auch ohne Dateiendung greift; Links unter pbs.twimg.com/media/ werden ohne Endungsprüfung durchgelassen; alle übrigen Whitelist-Domains müssen zwingend auf .jpg, .jpeg, .png, .gif, .webp oder .bmp enden (ein Query-String dahinter ist hier erlaubt, anders als bei der Webversion). term.ptt.cc verlangt also „Domain UND Dateiendung" — beide Bedingungen müssen gleichzeitig erfüllt sein.

PttChrome: Nur die Domain zählt, die Dateiendung interessiert niemanden

PttChrome ist der ältere Vertreter unter den PTT-Clients, die aktiv gepflegte Version liegt bei iamchucky/PttChrome. Für die Bildvorschau zuständig ist js/term_view.js, das bei der Linkauswahl diesen jQuery-Selektor verwendet:

var aNodes = $(".main a[href^='http://ppt.cc/'], .main a[type='p'], " +
  ".main a[href^='http://imgur.com/'], .main a[href^='https://imgur.com/'], " +
  ".main a[href^='https://flic.kr/p/'], .main a[href^='https://www.flickr.com/photos/']")
  .not("a[href^='http://imgur.com/a/'], a[href^='https://imgur.com/a/'], " +
       "a[href^='http://imgur.com/gallery/'], a[href^='https://imgur.com/gallery/']");

Hier wird es unschön: PttChrome prüft die Dateiendung überhaupt nicht, nur den URL-Anfang zählt — auf der Whitelist stehen ausschließlich der ppt.cc-Kurzlink-Dienst, imgur.com (ohne Alben und Galerie-Seiten), flic.kr und flickr.com/photos. urusai.cc, vgy.me, duk.tw, meee, ImgBB, Postimages und lpic.cc fehlen komplett — selbst der sauberste Direktlink bleibt bei PttChrome eine blaue Zeile. Noch kurioser ist der Umgang mit Imgur-Links: Der Code schreibt die URL fest auf i.imgur.com/ID.jpg um, die Dateiendung .jpg ist hart codiert, unabhängig davon, ob das Originalbild eigentlich ein PNG oder GIF ist. Ein Relikt aus über einem Jahrzehnt PTT-Geschichte, das kaum jemandem auffällt, weil Imgur bei falscher Dateiendung trotzdem meistens korrekt ausliefert.

Mobile Apps (Mo PTT, JPTT, PiTT): Closed Source, nur Community-Indizien

An dieser Stelle muss ich ehrlich zugeben: Eine Antwort auf Quellcode-Niveau kann ich hier nicht liefern. Mo PTT, JPTT und PiTT sind kommerzielle Closed-Source-Apps, auf GitHub findet sich kein zugehöriges Repository. Die belastbarsten Belege, die ich finden konnte, stammen aus zwei zeitlich nah beieinanderliegenden Diskussionen im PTT-ask-Forum (verfasst im Juni und Oktober 2025), in denen Nutzer ihre praktischen Beobachtungen teilen: Bei meee.com.tw funktioniert das automatische Öffnen, wenn man die Endung .jpg manuell ergänzt; das Format i.urusai.cc/ID.png von urusai.cc klappt; bei imgpoi.com wird angezweifelt, ob überhaupt eine automatische Bildvorschau existiert. Diese Beschreibungen deuten alle in Richtung „App prüft die Dateiendung", ähnlich der Logik der www.ptt.cc-Webversion — aber niemand kann mit Quellcode oder offizieller technischer Dokumentation belegen, ob zusätzlich eine Domain-Whitelist existiert. Diesen Punkt markiere ich bewusst als unverifiziert, ich tue nicht so, als hätte ich diese Apps selbst zerlegt.

Die vier Regelwerke im Überblick

Client Prüfkriterium Dateiendungs-Anforderung WebP Beleglage
www.ptt.cc-Webversion Nur Dateiendung, keine Domain Muss auf .jpg/.jpeg/.png/.gif enden, kein Query-String Nicht unterstützt Quellcode (ptt/pttweb)
term.ptt.cc Domain-Whitelist + Dateiendung (beides Pflicht) Bei Whitelist-Domains .jpg/.jpeg/.png/.gif/.webp/.bmp, Query-String erlaubt Unterstützt Quellcode (ptt/ptt-term)
PttChrome Nur Domain, Dateiendung egal Keine Prüfung (Imgur-Links werden zu .jpg umgeschrieben) Nicht relevant Quellcode (iamchucky/PttChrome)
Mobile App (Mo PTT/JPTT/PiTT) Vermutlich Dateiendung Vermutlich .jpg/.png/.gif funktionsfähig Unverifiziert Community-Berichte, kein Quellcode

Diese Tabelle macht deutlich: Es gibt kein einheitliches „PTT-Standardregelwerk". Derselbe Bild-Host-Link kann bei vier verschiedenen Clients vier verschiedene Ergebnisse liefern. Bei PTT hängt das Ergebnis also vom gewählten Zugangsweg ab, nicht allein vom Bild-Host.

Bild-Host × Client: Kompatibilitätstabelle

Diese Tabelle vergleicht die vier Regelwerke mit den Direktlink-Formaten gängiger Bild-Hosts. „✅" bedeutet, dass automatisches Öffnen nach der Logik zu erwarten ist, „❌" bedeutet nein, „⚠️" bedeutet, dass es von manueller Konfiguration oder Dateiendung abhängt.

Bild-Host (Direktlink-Beispiel) www.ptt.cc-Webversion term.ptt.cc (Standard) PttChrome App (Community-Berichte)
Imgur i.imgur.com/ID.jpg ✅ ✅ ✅ (wird zu .jpg gezwungen) ✅
meee meee.com.tw/ID.jpg ✅ ✅ ❌ ✅ (Endung manuell ergänzen)
duk.tw ✅ (mit Endung) ✅ ❌ Unverifiziert
urusai.cc i.urusai.cc/ID.png ✅ (mit Endung) ⚠️ Whitelist muss selbst ergänzt werden ❌ ✅ (Community-Bericht)
vgy.me ✅ (mit Endung) ⚠️ Whitelist muss selbst ergänzt werden ❌ Unverifiziert, gilt als „am umständlichsten"
ImgBB ibb.co / i.ibb.co ✅ (mit Endung) ✅ ❌ Unverifiziert
Postimages postimg.cc ✅ (mit Endung) ✅ ❌ Unverifiziert
lpic.cc lpic.cc/{Code} ❌ (keine Dateiendung) ❌ (nicht auf Whitelist, keine Endung) ❌ ❌ (kein Direktlink verfügbar)

Die letzte Zeile verdient eine eigene Erklärung.

Kann man lpic.cc-Links auf PTT automatisch öffnen lassen? Aktuell nein

Vor diesem Artikel habe ich das Freigabeformat von lpic.cc selbst noch einmal geprüft. Nach dem Upload erhält man aktuell eine URL im Format https://lpic.cc/{Kurzcode} — eine Werkseite, keinen Direktlink mit Dateiendung wie i.imgur.com/xxx.jpg. Das bedeutet: Weder die Dateiendungslogik der www.ptt.cc-Webversion noch die Domain-Whitelists von term.ptt.cc und PttChrome greifen hier. Die Freigabeseite selbst zeigt zwar ein Thumbnail an, aber erst, wenn man die Seite öffnet — nicht als automatische Einbettung direkt im Beitrag.

Für alle, die auf PTT einfach nur Links posten und automatische Thumbnails wollen, ist das ehrlich gesagt keine gute Nachricht, und ich möchte das nicht schönreden. Wer genau das braucht, ist mit den in der Tabelle grün markierten Hosts (Imgur, meee, alles auf der term.ptt.cc-Standardliste) besser bedient. Der Vorteil des lpic.cc-Freigabeseitenmodells liegt woanders: Passwortschutz, Aufrufzähler, Kommentarfunktion — Features, die relevant werden, wenn man kontrollieren will, wer etwas sehen darf und ob eine Ansicht protokolliert wird, etwa bei Transaktionsscreenshots oder privaten Inhalten, bei denen der Link gezielt geteilt wird statt öffentlich als Thumbnail aufzupoppen. Zwei unterschiedliche Bedürfnisse, die sich nicht gegenseitig ersetzen lassen.

Welcher Bild-Host passt zu welchem Einsatzzweck?

Wer nur will, dass ein Link sofort automatisch als Bild erscheint, sollte sich am hauptsächlich genutzten Client orientieren: Bei App-Nutzung eignen sich Imgur oder meee mit manuell ergänzter Endung; bei der Webversion funktioniert jeder Host mit sauberem Dateiendungs-Direktlink — WebP ausgenommen, das die www.ptt.cc-Webversion komplett ignoriert; bei term.ptt.cc lohnt vorher ein Blick in die eigene Whitelist-Konfiguration, notfalls die Domain manuell ergänzen.

Wer über mehrere Clients hinweg konsistente Ergebnisse braucht, kommt aktuell nur mit Imgur durch alle vier Regelwerke — mit dem Nachteil, dass Imgur taiwanische IP-Adressen inzwischen blockiert. Mehr dazu in meinem PTT-Bild-Hosting-Tutorial. Einen Host, der in jeder Situation sorgenfrei funktioniert, gibt es schlicht nicht — das habe ich selbst leidvoll erfahren, und es bringt niemandem etwas, das anders darzustellen.

Häufig gestellte Fragen (FAQ)

Warum hat sich derselbe Imgur-Link gestern noch geöffnet, heute aber nicht mehr?

Imgur blockiert seit Mai 2025 taiwanische IP-Adressen. Wer sich in Taiwan befindet, kann unter Umständen i.imgur.com selbst gar nicht erreichen — das hat nichts mit den PTT-Client-Regeln zu tun. Zusätzlich schreibt PttChrome Imgur-Links zwangsweise auf die Endung .jpg um; ist das Original ein PNG mit Transparenz, kann Bildqualität oder Transparenz verloren gehen — das betrifft aber nur die Darstellung, nicht ob das Bild grundsätzlich angezeigt wird.

Kann man die Whitelist von term.ptt.cc selbst anpassen?

Laut Quellcode unterstützt die Funktion parseTrustedDomains das Einlesen einer eigenen Liste — die Whitelist ist also konfigurierbar, keine unveränderliche Vorgabe. Wo genau in der Benutzeroberfläche diese Einstellung vorgenommen wird und ob ein Neuladen der Seite nötig ist, habe ich nicht selbst getestet — am besten direkt im Einstellungsmenü von term.ptt.cc nachsehen.

Warum gibt es zur Domain-Whitelist der mobilen Apps keine klare Antwort?

Weil Mo PTT, JPTT und PiTT allesamt Closed-Source-Software sind, gibt es keinen öffentlichen Quellcode zum Nachvollziehen. Alle Aussagen zu diesen drei Apps in diesem Artikel stammen aus Praxisberichten im PTT-ask-Forum, nicht aus eigener Code-Analyse — das ist im Artikel bereits klar als unverifiziert gekennzeichnet, ich tue nicht so, als hätte ich es selbst nachgeprüft.

Warum unterstützt die www.ptt.cc-Webversion kein WebP, term.ptt.cc aber schon?

Weil es sich um zwei völlig unabhängige Codebasen handelt: pttweb ist serverseitig in Go geschrieben, ptt-term ist clientseitiges JavaScript — unterschiedliche Maintainer, unterschiedliche Entstehungszeiten. WebP hat sich erst relativ spät durchgesetzt, und die pttweb-Regel wurde offenbar nie entsprechend aktualisiert. Genau das ist die Kernaussage dieses Artikels: PTT ist kein einheitliches System, sondern ein gewachsenes Ökosystem aus mehreren unabhängigen Programmen.

Gibt es für deutschsprachige Leser eine vergleichbare Situation wie bei PTT?

Ja, wenn auch in kleinerem Ausmaß. Auch in anderen Foren-Software-Systemen hängt es vom BBCode-Tag und vom unterstützten Format ab, ob ein verlinktes Bild automatisch eingebettet wird, und mancher Hotlink-Filter blockiert bestimmte Hosts komplett. Der Unterschied zu PTT ist eher graduell als grundsätzlich: Bei PTT entsteht die Uneinheitlichkeit dadurch, dass mindestens vier unabhängige Client-Programme unterschiedliche Regeln fahren, während andere Foren das Verhalten meist zentral über eine einzige Forensoftware festlegen.

Quellen

#PTT Taiwan Forum#Bildlink automatisch anzeigen#term.ptt.cc#PttChrome#Bild-Hosting Taiwan#Forum Bildvorschau Regeln#Direktlink Dateiformat#Hotlink Whitelist
A

Verfasst von

Alex Chen

Produkttester

Praktisches Testen jedes Tools – mit direkten Erfahrungsberichten aus erster Hand.