Retour au blog
Communauté

Pourquoi vos images PTT ne s'affichent pas automatiquement : j'ai lu le code source de term.ptt.cc et PttChrome, il y a 4 règles différentes

Publié le14 min read
Partager

Le même lien s'affiche en image ici, en texte brut là-bas : pourquoi ?

Sur JV.com ou HardwareFr, tout le monde connaît cette galère : coller un lien image et prier pour que l'aperçu apparaisse, sinon c'est un URL tout nu qui traîne dans le message. Sur PTT, le plus grand forum textuel de Taïwan, ce chaos est encore pire — et ce n'est pas une question d'hébergeur meilleur qu'un autre.

Franchement, la première hypothèse de la plupart des gens, c'est qu'ils ont mal collé le format du lien. Raté. Le vrai problème : le même lien devient automatiquement une miniature dans l'appli mobile, mais reste une simple chaîne de caractères sur la version web. Ce n'est ni un hasard ni une faute de frappe — derrière le nom « PTT » se cachent en réalité au moins quatre logiciels clients totalement différents, chacun avec sa propre logique pour décider si un lien devient une image ou pas. Certains regardent seulement l'extension du fichier, d'autres seulement la liste blanche de domaines, d'autres encore exigent les deux conditions à la fois. Il y a même un cas encore plus radical qui zappe carrément la vérification d'extension et parie tout simplement que le lien collé vient d'Imgur — j'y reviens plus loin.

En octobre 2025, une discussion sur le forum ask de PTT posait justement la question « quels hébergeurs supportent l'affichage automatique ». L'auteur du message mentionnait que term.ptt.cc affichait autrefois un aperçu au survol des liens Imgur, mais que ça a arrêté de fonctionner il y a environ six mois. C'est exactement le point que beaucoup de gens ratent : même client, même hébergeur, mais les règles changent avec le temps sans qu'aucune annonce officielle ne soit faite nulle part. Plutôt que de me fier au bouche-à-oreille, je suis allé lire directement le code source des principaux clients PTT. Chaque affirmation de cet article s'appuie sur une ligne de code précise et vérifiable.

Voir une image sur PTT, ce sont en fait 5 chemins différents

Avant que les tableaux plus bas aient du sens, il faut clarifier une chose : « PTT » n'est pas un logiciel unique, c'est un écosystème d'au moins cinq points d'accès différents.

  • Terminaux BBS purement texte (PCMan, Welly) : ne comprennent que du texte. Les liens image restent des chaînes de caractères pour toujours, aucun affichage automatique.
  • Version web www.ptt.cc : au chargement de la page article, le serveur convertit directement les URL correspondantes en balises <img>.
  • term.ptt.cc : un émulateur de terminal web, un aperçu apparaît au survol de la souris, géré par du JavaScript côté client.
  • PttChrome : un client telnet historique dans le navigateur, qui intègre les images directement dans l'affichage de l'article.
  • Applications mobiles (Mo PTT, JPTT, PiTT, BePTT) : convertissent les liens en miniatures directement affichées — ce sont toutes des applications propriétaires à code fermé, leur comportement ne se déduit que via les retours de la communauté et les descriptions officielles.

L'écart entre les deux premières catégories et les trois dernières est bien plus grand qu'on ne l'imagine.

Quatre règles, comparées directement dans le code source

Version web www.ptt.cc : vérification côté serveur, extension prioritaire, mais le WebP passe à la trappe

Le frontend web de www.ptt.cc s'appelle pttweb, code source public sur le dépôt GitHub ptt/pttweb. Le fichier chargé de convertir les liens en images s'appelle richcontent/url_based_finder.go, avec une liste de règles vérifiées dans l'ordre :

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),
}

La dernière ligne est celle qui compte vraiment. Les trois premières règles ciblent spécifiquement YouTube, Imgur et picmoe.net — la quatrième est la vraie clé : n'importe quelle URL qui se termine par .png, .jpeg, .jpg ou .gif (peu importe la casse), quel que soit l'hébergeur, sera transformée en balise <img> et affichée directement. Autrement dit, la logique de pttweb reconnaît l'extension, pas le domaine — exactement l'inverse de term.ptt.cc, qu'on va voir juste après.

Il y a une contrainte : l'URL doit se terminer exactement par l'extension, une chaîne de requête derrière empêche le déclenchement (le regex fixe la fin avec $). Si un hébergeur fournit un lien direct au format xxx.jpg?token=abc123, la dernière règle ne matchera pas. Et .webp n'apparaît nulle part dans la liste — même avec un vrai lien direct WebP, la version web www.ptt.cc ne l'affichera jamais automatiquement, ça restera un simple URL. C'est un détail que je n'ai vu clairement documenté nulle part ailleurs dans les guides sur le sujet.

term.ptt.cc : la liste blanche de domaines d'abord, l'extension en deuxième filtre

Le code source de term.ptt.cc est sur le dépôt GitHub ptt/ptt-term, un terminal BBS web connecté via WebSocket. Le module qui gère l'aperçu au survol s'appelle src/plugins/media_previewer/image_preview_util.js, avec une liste de domaines de confiance codée en dur :

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",
];

Vous avez remarqué ? urusai.cc, vgy.me et lpic.cc n'y figurent pas. Pourtant sur le forum ask de PTT, des utilisateurs affirment qu'urusai.cc et vgy.me s'affichent très bien chez eux. Contradiction ? Pas vraiment — le code contient aussi une fonction parseTrustedDomains, preuve que cette liste blanche peut être étendue dans les paramètres personnels. La liste par défaut de dix hébergeurs n'est que la config « prête à l'emploi », pas l'ensemble complet. L'utilisateur en question a probablement ajouté urusai.cc à sa propre configuration, ce n'est pas un support universel intégré pour tout le monde. C'est un point qu'on confond facilement avec « une règle valable pour tous ».

La logique de vérification a deux niveaux : Imgur a une regex dédiée qui fonctionne même sans extension ; les liens commençant par pbs.twimg.com/media/ passent sans vérification d'extension ; pour toutes les autres domaines de la liste blanche, l'URL doit se terminer par .jpg, .jpeg, .png, .gif, .webp ou .bmp (une chaîne de requête derrière est acceptée ici, contrairement à la version web). Autrement dit, term.ptt.cc exige « domaine ET extension » — les deux conditions doivent être remplies simultanément.

PttChrome : seul le domaine compte, l'extension n'intéresse personne

PttChrome est un produit plus ancien, dont la version maintenue se trouve chez iamchucky/PttChrome. Le fichier chargé de l'aperçu à l'écran est js/term_view.js, qui utilise ce sélecteur jQuery pour repérer les liens à traiter :

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/']");

Et là, ça se corse. PttChrome ne vérifie absolument pas l'extension, seul le début de l'URL compte — la liste blanche se limite au raccourcisseur ppt.cc, imgur.com (albums et galeries exclus), flic.kr et flickr.com/photos. urusai.cc, vgy.me, duk.tw, meee, ImgBB, Postimages et lpic.cc n'y figurent pas du tout, même le lien direct le plus standard ne s'affichera jamais automatiquement dans PttChrome, ça restera une ligne bleue pour toujours. Plus amusant encore, la façon dont il traite les liens Imgur : le code réécrit directement l'URL en i.imgur.com/ID.jpg, l'extension .jpg est codée en dur, peu importe que l'image d'origine soit en réalité un PNG ou un GIF. Un petit bug hérité depuis plus d'une décennie, que personne ne remarque en temps normal parce qu'Imgur renvoie généralement la bonne image malgré une extension incorrecte dans la requête.

Applications mobiles (Mo PTT, JPTT, PiTT) : code fermé, seulement des preuves indirectes

Là, je dois être honnête : je ne peux pas vous donner de réponse au niveau du code source. Mo PTT, JPTT et PiTT sont des applications commerciales à code fermé, aucun dépôt correspondant sur GitHub. Les preuves les plus solides que j'ai pu trouver viennent de deux discussions proches dans le temps sur le forum ask de PTT (postées en juin et octobre 2025), où des utilisateurs partagent leurs observations pratiques : ajouter manuellement l'extension .jpg fait fonctionner l'affichage automatique sur meee.com.tw ; le format i.urusai.cc/ID.png d'urusai.cc fonctionne ; pour imgpoi.com, certains doutent même qu'un affichage automatique existe. Ces descriptions vont toutes dans le sens « l'appli vérifie l'extension », une logique proche de celle de la version web www.ptt.cc — mais personne n'a pu fournir le code source ou une documentation technique officielle pour confirmer si une liste blanche de domaines existe aussi. Je marque clairement ce point comme non vérifié, je ne prétends pas avoir décompilé ces applications moi-même.

Les quatre règles côte à côte

Client Critère de vérification Exigence d'extension WebP Niveau de preuve
Version web www.ptt.cc Extension seule, pas de domaine Doit se terminer par .jpg/.jpeg/.png/.gif, pas de chaîne de requête Non supporté Code source (ptt/pttweb)
term.ptt.cc Liste blanche de domaines + extension (double condition) Domaines listés : .jpg/.jpeg/.png/.gif/.webp/.bmp, chaîne de requête acceptée Supporté Code source (ptt/ptt-term)
PttChrome Domaine seul, extension ignorée Aucune vérification (liens Imgur forcés en .jpg) Non applicable Code source (iamchucky/PttChrome)
App mobile (Mo PTT/JPTT/PiTT) Probablement l'extension Probablement .jpg/.png/.gif fonctionnels Non vérifié Retours communautaires, pas de code source

Ce tableau parle de lui-même : il n'existe aucune « règle universelle PTT ». Le même lien d'hébergeur d'images peut donner quatre résultats différents selon les quatre clients — une situation qu'on retrouve rarement de cette façon sur des forums français, où l'aperçu dépend surtout d'une balise ou du protocole og:image, pas d'un patchwork de logiciels indépendants.

Tableau de compatibilité hébergeur × client

Ce tableau croise les quatre règles avec le format de lien direct des hébergeurs les plus courants. « ✅ » signifie que l'affichage automatique devrait fonctionner selon la logique, « ❌ » signifie non, « ⚠️ » signifie que ça dépend d'un réglage manuel ou de l'extension.

Hébergeur (exemple de lien direct) Version web www.ptt.cc term.ptt.cc (par défaut) PttChrome App (retours communautaires)
Imgur i.imgur.com/ID.jpg ✅ ✅ ✅ (forcé en .jpg) ✅
meee meee.com.tw/ID.jpg ✅ ✅ ❌ ✅ (extension à ajouter manuellement)
duk.tw ✅ (avec extension) ✅ ❌ Non vérifié
urusai.cc i.urusai.cc/ID.png ✅ (avec extension) ⚠️ À ajouter soi-même à la liste blanche ❌ ✅ (retour communautaire)
vgy.me ✅ (avec extension) ⚠️ À ajouter soi-même à la liste blanche ❌ Non vérifié, réputé « le plus galère »
ImgBB ibb.co / i.ibb.co ✅ (avec extension) ✅ ❌ Non vérifié
Postimages postimg.cc ✅ (avec extension) ✅ ❌ Non vérifié
lpic.cc lpic.cc/{code} ❌ (pas d'extension) ❌ (hors liste blanche, pas d'extension) ❌ ❌ (pas de lien direct disponible)

La dernière ligne mérite une explication à part.

Peut-on faire s'afficher un lien lpic.cc automatiquement sur PTT ? Pas pour l'instant

Avant d'écrire cet article, j'ai revérifié le format de partage de lpic.cc moi-même. Après l'upload, l'URL obtenue actuellement est du type https://lpic.cc/{code court} — une page de présentation, pas un lien direct qui se termine par une extension image comme i.imgur.com/xxx.jpg. Résultat : ni la logique d'extension de la version web www.ptt.cc, ni les listes blanches de term.ptt.cc et PttChrome ne peuvent l'attraper. La page de partage affiche bien une miniature, mais seulement une fois qu'on l'ouvre — pas en intégration automatique directe dans le message.

Franchement, ce n'est pas une bonne nouvelle pour ceux qui veulent juste coller un lien pour un affichage automatique, et je ne vais pas essayer de vous le présenter autrement. Si c'est exactement votre besoin, les hébergeurs cochés dans le tableau (Imgur, meee, tout ce qui est dans la liste par défaut de term.ptt.cc) sont plus adaptés. L'avantage du modèle « page de partage » de lpic.cc se joue ailleurs : protection par mot de passe, compteur de vues, zone de commentaires — des fonctions utiles quand on veut contrôler qui a le droit de voir et si la consultation laisse une trace, par exemple pour des captures de transaction ou du contenu privé qu'on veut partager sur invitation plutôt que voir s'afficher en miniature devant tout le monde. Deux besoins différents, qu'on ne peut pas confondre sans se compliquer la vie.

Alors, comment choisir ?

Si vous voulez juste que ça s'affiche automatiquement dès que vous collez le lien, tout dépend du client que vous utilisez principalement : pour l'appli mobile, Imgur ou meee avec l'extension ajoutée manuellement ; pour la version web, n'importe quel hébergeur avec un lien direct à extension standard fonctionne, mais attention, le WebP ne passe jamais sur la version web www.ptt.cc ; avec term.ptt.cc, vérifiez d'abord si l'hébergeur figure dans votre propre liste blanche, sinon ajoutez-le manuellement.

Si vous devez couvrir plusieurs clients à la fois, Imgur reste actuellement le seul hébergeur qui passe les quatre règles — au prix d'un blocage des adresses IP taïwanaises, un sujet que je détaille plus complètement dans mon tutoriel d'hébergement d'images pour PTT. Il n'existe vraiment aucun hébergeur qui fonctionne sans accroc dans toutes les situations, je l'ai constaté à mes dépens et il n'y a aucun intérêt à faire semblant du contraire.

Questions fréquentes

Pourquoi le même lien Imgur s'affichait encore hier, et plus aujourd'hui ?

Imgur bloque les adresses IP taïwanaises depuis mai 2025. Si vous êtes physiquement à Taïwan, il se peut que vous ne puissiez même plus accéder à i.imgur.com, ce qui n'a rien à voir avec les règles des clients PTT. Par ailleurs, PttChrome force la réécriture des liens Imgur en .jpg — si l'image d'origine est un PNG à fond transparent, la qualité ou la transparence peut se dégrader, mais ça n'affecte que le rendu, pas le fait que l'image s'affiche ou non.

Peut-on modifier soi-même la liste blanche de term.ptt.cc ?

D'après le code source, la fonction parseTrustedDomains permet bien de charger une liste personnalisée, donc c'est un réglage ajustable, pas une règle figée. Je n'ai pas testé exactement où se trouve ce réglage dans l'interface ni s'il faut recharger la page pour qu'il prenne effet — le mieux est d'aller directement fouiller dans le menu de paramètres de term.ptt.cc.

Pourquoi n'avez-vous pas de réponse claire sur la liste blanche des applis mobiles ?

Parce que Mo PTT, JPTT et PiTT sont toutes des applications à code fermé, impossible de vérifier ligne par ligne sans code source public. Tout ce que cet article dit sur ces trois applis vient de retours d'utilisateurs sur le forum ask de PTT, pas d'une analyse de code que j'aurais faite moi-même — c'est déjà clairement indiqué comme non vérifié dans l'article, je ne prétends pas l'avoir confirmé.

Pourquoi la version web www.ptt.cc ne supporte pas le WebP, alors que term.ptt.cc oui ?

Parce que ce sont deux bases de code totalement indépendantes : pttweb est écrit en Go côté serveur, ptt-term est en JavaScript côté client — mainteneurs différents, périodes de développement différentes. Le WebP s'est démocratisé assez tardivement, et la règle de pttweb n'a visiblement jamais été mise à jour en conséquence. C'est exactement le point central de cet article : PTT n'est pas un système unifié, c'est un écosystème composé de plusieurs logiciels indépendants qui cohabitent tant bien que mal.

Est-ce qu'un lecteur francophone retrouve une situation comparable à PTT ?

Oui, dans une moindre mesure. Sur JV.com, l'aperçu automatique passe par NoelShack et une balise dédiée, sinon rien ne s'affiche ; sur HardwareFr, il faut souvent insérer la balise [img] à la main ; sur Discord, en revanche, un lien direct vers une image (peu importe l'hébergeur, tant que ça se termine par une extension reconnue) génère quasi toujours un embed automatique, ce qui est plus proche de la logique de www.ptt.cc que de celle de term.ptt.cc. La vraie différence avec Taïwan, c'est que sur les forums francophones, une seule plateforme dominante (Discord) a fini par imposer une logique d'aperçu à peu près cohérente, alors que sur PTT, cinq points d'accès coexistent avec cinq comportements différents, sans jamais converger.

Sources

#PTT forum taïwanais#aperçu image automatique#term.ptt.cc#PttChrome#hébergement image compatible#règles forum image#lien direct extension fichier#liste blanche hotlink
A

Rédigé par

Alex Chen

Testeur produit

Il teste chaque outil en conditions réelles et partage son vécu à la première personne, sans filtre.