Torna al blog
Community

Perché il link immagine su PTT non si apre da solo? Nel codice sorgente ho trovato 4 regole diverse

Pubblicato il14 min read
Condividi

Un solo link, quattro risultati diversi — e non è colpa tua

Se non hai mai usato PTT, ecco la versione in trenta secondi: è il BBS (bulletin board system) testuale più vecchio e più grande di Taiwan, ancora oggi in stile terminale telnet, con milioni di account attivi. Chiunque ci passi del tempo prima o poi si imbatte nello stesso rompicapo che ho trovato io — incolli un link a un'immagine e a volte diventa una miniatura, a volte resta lì come una stringa di testo blu sottolineata.

Onestamente, il primo pensiero di molti è di aver sbagliato il formato del link. Non è così. La vera sorpresa non è "quale host è migliore" — è che lo stesso identico link si apre in miniatura sull'app mobile e appare come un URL nudo sulla versione desktop, senza che l'utente cambi niente.

Non è un caso, e non è nemmeno colpa tua. Sotto il nome "PTT" si nascondono in realtà almeno quattro software completamente diversi, ognuno con una logica propria per decidere se un URL deve trasformarsi automaticamente in immagine. Alcuni guardano solo l'estensione del file, altri una whitelist di domini, altri ancora pretendono che entrambe le condizioni siano vere insieme. C'è persino un caso limite: salta del tutto il controllo dell'estensione, scommettendo semplicemente che tu abbia incollato un link Imgur — ci arrivo più avanti.

Nell'ottobre 2025 sulla board ask di PTT (una sezione forum dedicata alle domande della community) è girata una discussione proprio su quali host supportino l'apertura automatica delle immagini. L'autore del post originale — nel gergo PTT si dice 原po — ha raccontato che tempo fa passando il mouse su un link Imgur in term.ptt.cc l'immagine appariva in anteprima, ma da sei mesi questo non funziona più. Ecco il punto che quasi nessuno coglie: stesso client, stesso host, ma le regole cambiano nel tempo e nessuno lo annuncia ufficialmente. Invece di fidarmi del sentito dire, sono andato a leggere il codice sorgente dei principali client, e ogni riga di questa guida ha una fonte verificabile alle spalle.

Anche nei gruppi WhatsApp italiani succede la stessa cosa

Se pensi che sia un problema solo taiwanese, pensa a quante volte in un gruppo WhatsApp o su un forum italiano un link a un'immagine si apre con l'anteprima e altre volte resta un semplice testo blu. WhatsApp si basa sui meta-tag Open Graph della pagina, i client PTT invece leggono direttamente il pattern dell'URL — tecnologia diversa, ma il problema di fondo è identico: ogni piattaforma ha una sua regola privata, e non esiste uno standard condiviso da tutti.

Guardare immagini su PTT: 5 percorsi diversi, non uno solo

Prima di andare avanti, meglio chiarire lo scenario, altrimenti la tabella dopo diventa incomprensibile.

  • Terminale BBS testuale (PCMan, Welly): legge solo testo, il link resta sempre una stringa, non diventa mai immagine da solo.
  • Articolo sulla versione web www.ptt.cc: quando leggi un post, il server converte lato server gli URL che rispettano la regola direttamente in tag <img>.
  • term.ptt.cc: emulatore di terminale via browser, passando il mouse sul link il JavaScript frontend fa comparire l'anteprima.
  • PttChrome: storico client telnet via browser, l'immagine viene inserita direttamente dentro il post.
  • App mobile (Mo PTT, JPTT, PiTT, BePTT): trasformano il link in miniatura visibile subito, ma sono software closed source, quindi si può ragionare solo su segnalazioni della community e documentazione ufficiale.

La differenza tra i primi due e gli ultimi tre è più grande di quanto sembri a prima vista.

Sono andato a leggere il codice sorgente — 4 regole, nessuna uguale all'altra

Articolo sulla versione web www.ptt.cc: decisione lato server, priorità all'estensione, ma niente WebP

Il frontend di www.ptt.cc si chiama pttweb, il codice sorgente è pubblico su GitHub nel repository ptt/pttweb. Il file che converte gli URL dei post in immagini è richcontent/url_based_finder.go, con un elenco di regole controllate in ordine:

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

Il punto chiave è l'ultima riga. Le prime tre sono regole dedicate a YouTube, Imgur e picmoe.net, ma quella davvero interessante è la quarta: qualsiasi URL che termina in .png, .jpeg, .jpg o .gif (maiuscole o minuscole non fanno differenza), a prescindere dall'host, viene incapsulato in un tag <img> e mostrato direttamente. Questo significa che l'articolo sulla versione web www.ptt.cc ragiona "sull'estensione, non sul dominio" — l'esatto opposto della logica di term.ptt.cc.

Ma questa regola pretende che l'URL finisca proprio con l'estensione, senza query string dopo (la regex blocca la fine con $). Se il link diretto del tuo host è del tipo xxx.jpg?token=abc123, non farà match con l'ultima regola. E poi .webp non compare affatto nell'elenco — quindi anche con un link diretto WebP autentico, l'articolo sulla versione web www.ptt.cc non lo espanderà mai automaticamente, resterà solo un URL. È un dettaglio che raramente viene spiegato con chiarezza nelle altre guide su come postare immagini su PTT.

term.ptt.cc: prima la whitelist dei domini, poi l'estensione come secondo filtro

Il codice sorgente di term.ptt.cc sta su GitHub in ptt/ptt-term, un terminale web che si collega al BBS via WebSocket. Il modulo che gestisce l'anteprima al passaggio del mouse è src/plugins/media_previewer/image_preview_util.js, dove è scritta direttamente la lista di domini fidati di default:

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

Notato? In questa lista non c'è urusai.cc, non c'è vgy.me, e tantomeno lpic.cc. Eppure sulla board ask di PTT qualcuno sosteneva che urusai.cc e vgy.me gli funzionassero perfettamente. Non è una contraddizione — nel codice esiste anche una funzione parseTrustedDomains, il che significa che questa whitelist può essere estesa dalle impostazioni personali; i dieci domini di default sono solo il set "pronto all'uso", non l'elenco completo. In altre parole, quell'utente probabilmente aveva aggiunto urusai.cc alla propria configurazione personale, non che term.ptt.cc lo supporti nativamente per tutti. È un punto facilmente frainteso come "regola generale del sito".

La logica si divide in due livelli: Imgur ha una regex dedicata, riconosciuta anche senza estensione nel link; i link che iniziano con pbs.twimg.com/media/ passano senza controllo dell'estensione; per tutti gli altri domini in whitelist, l'URL deve terminare in .jpg, .jpeg, .png, .gif, .webp o .bmp (anche con query string, a differenza della versione web www.ptt.cc). In sintesi, term.ptt.cc richiede "dominio E estensione" insieme, un doppio sbarramento.

PttChrome: guarda solo il dominio, non si preoccupa nemmeno dell'estensione

PttChrome è più datato, la versione storica è mantenuta in iamchucky/PttChrome. Il file responsabile dell'anteprima immagini è js/term_view.js, con questo selettore jQuery per scegliere i link da elaborare:

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

Qui la situazione si fa un po' imbarazzante. PttChrome non controlla mai l'estensione, guarda solo l'inizio dell'URL — la whitelist contiene solo i link brevi ppt.cc, imgur.com (esclusi album e pagine gallery), flic.kr e flickr.com/photos. urusai.cc, vgy.me, duk.tw, meee, ImgBB, Postimages, lpic.cc non ci sono, quindi per quanto il tuo link diretto sia formattato correttamente, PttChrome non lo espanderà mai automaticamente — resterà per sempre una riga di testo blu. E la parte più curiosa è come gestisce i link Imgur: il codice riscrive direttamente l'URL in i.imgur.com/ID.jpg, con l'estensione .jpg hardcoded, indipendentemente dal fatto che l'immagine originale sia PNG o GIF. È un piccolo difetto rimasto lì da oltre un decennio, che quasi nessuno nota perché Imgur di solito restituisce comunque l'immagine corretta anche a fronte di una richiesta con estensione sbagliata.

App mobile (Mo PTT, JPTT, PiTT): closed source, solo prove indirette dalla community

Onestamente qui non posso darti una risposta al livello del codice sorgente. Mo PTT, JPTT, PiTT sono tutte app commerciali closed source, su GitHub non esiste un repository corrispondente. La prova più solida che ho trovato sono due discussioni ravvicinate nel tempo sulla board ask di PTT (una a giugno 2025, l'altra a ottobre 2025), dove gli utenti riportavano le proprie esperienze: aggiungendo manualmente l'estensione .jpg a meee.com.tw l'anteprima funziona, il formato i.urusai.cc/ID.png di urusai.cc funziona, mentre per imgpoi.com è stato messo in dubbio che esista un'apertura automatica. Tutti questi segnali indicano una logica "basata sull'estensione", più vicina a quella della versione web www.ptt.cc, ma nessuno possiede il codice sorgente o la documentazione tecnica ufficiale di queste app per confermare se esista anche una whitelist di domini. Su questo punto rimango esplicitamente sul non verificato, non fingo di aver smontato il loro codice.

Le 4 regole a confronto

Client Criterio di decisione Requisito estensione WebP Livello di prova
Articolo web www.ptt.cc Solo estensione, non dominio Deve terminare in .jpg/.jpeg/.png/.gif, niente query string Non supportato Codice sorgente (ptt/pttweb)
term.ptt.cc Whitelist dominio + estensione, doppio filtro Sui domini in whitelist serve .jpg/.jpeg/.png/.gif/.webp/.bmp, query string ammessa Supportato Codice sorgente (ptt/ptt-term)
PttChrome Solo dominio, nessun controllo estensione Nessun controllo (i link Imgur vengono forzati in .jpg) Non applicabile Codice sorgente (iamchucky/PttChrome)
App mobile (Mo PTT/JPTT/PiTT) Presumibilmente basato sull'estensione Presumibilmente .jpg/.png/.gif funzionano Non verificato Segnalazioni community, nessun codice sorgente visibile

Guardando questa tabella si capisce una cosa: non esiste una "regola universale di PTT". Lo stesso link a un host di immagini può dare quattro risultati diversi su quattro client diversi.

Tabella di compatibilità host × client

Ho costruito questa tabella applicando ogni regola vista sopra ai formati di link diretto dei principali host di immagini. "✅" significa che in teoria dovrebbe aprirsi da solo, "❌" che non si apre, "⚠️" che dipende dalle impostazioni personali o dall'estensione usata.

Host immagini (esempio link diretto) Articolo web www.ptt.cc term.ptt.cc (default) PttChrome App (segnalazioni community)
Imgur i.imgur.com/ID.jpg ✅ ✅ ✅ (forzato in .jpg) ✅
meee meee.com.tw/ID.jpg ✅ ✅ ❌ ✅ (serve aggiungere l'estensione a mano)
duk.tw ✅ (con estensione) ✅ ❌ Non verificato
urusai.cc i.urusai.cc/ID.png ✅ (con estensione) ⚠️ va aggiunto manualmente in whitelist ❌ ✅ (segnalazioni community)
vgy.me ✅ (con estensione) ⚠️ va aggiunto manualmente in whitelist ❌ Non verificato, la community lo definisce "il più complicato"
ImgBB ibb.co / i.ibb.co ✅ (con estensione) ✅ ❌ Non verificato
Postimages postimg.cc ✅ (con estensione) ✅ ❌ Non verificato
lpic.cc lpic.cc/{code} ❌ (senza estensione) ❌ (fuori whitelist, senza estensione) ❌ ❌ (nessun link diretto disponibile)

Sull'ultima riga vale la pena essere onesti fino in fondo.

lpic.cc funziona per l'apertura automatica su PTT? No, questo è il limite attuale

Prima di scrivere questo articolo ho riverificato il formato dei link di condivisione di lpic.cc. L'URL che ottieni dopo un caricamento è oggi del tipo https://lpic.cc/{codice}, una pagina di condivisione, non un link diretto tipo i.imgur.com/xxx.jpg che termina con l'estensione dell'immagine — quindi né la regola dell'estensione di www.ptt.cc, né le whitelist di domini di term.ptt.cc e PttChrome riescono a intercettarlo. La pagina di condivisione mostra sì una miniatura, ma solo aprendo la pagina, non incollando semplicemente il link.

Sinceramente, per chi vuole aprire immagini direttamente su PTT non è una buona notizia, e non ho intenzione di presentarla diversamente. Se il tuo bisogno è che il link diventi automaticamente una miniatura, gli host con la spunta verde nella tabella sopra (Imgur, meee, e i pochi già nella whitelist di default di term.ptt.cc) sono più adatti. Il vantaggio di un modello a pagina di condivisione come lpic.cc sta altrove — protezione con password, conteggio visualizzazioni, sezione commenti: funzioni utili quando vuoi controllare "chi può vedere, e se la visualizzazione viene registrata", ad esempio uno screenshot di una transazione o contenuti privati, dove mandi il link e chiedi alla persona di cliccare per guardare, invece di mostrare automaticamente la miniatura a chiunque passi di lì. Sono due esigenze diverse, forzarne una al posto dell'altra crea solo attrito.

Allora come scegliere?

Se ti interessa solo che "incollato il link, la miniatura appaia subito", dipende dal client che usi di più: se principalmente l'app mobile, scegli Imgur o meee (abituandoti ad aggiungere l'estensione); se leggi principalmente sulla versione web, va bene qualunque host con estensione standard nel link diretto, ma ricorda che WebP non funziona mai sulla versione web www.ptt.cc; se usi term.ptt.cc, controlla prima se il tuo host è nella whitelist personale, e in caso contrario aggiungilo a mano.

Se ti serve un link universale su più client, Imgur resta ancora l'unica opzione che rientra in tutte e quattro le regole — al prezzo che ha già bloccato gli IP di Taiwan, argomento che approfondisco nella guida completa alla pubblicazione di immagini su PTT. In realtà nessun host ti evita completamente il pensiero del formato in ogni situazione — l'ho verificato sulla mia pelle, e non ho motivo di fare inutili complimenti a nessun servizio in particolare.

Domande frequenti

D1: Perché lo stesso link Imgur ieri apriva l'immagine e oggi no?

Imgur blocca gli IP di Taiwan da maggio 2025 — se ti trovi a Taiwan, potrebbe essere che i.imgur.com semplicemente non sia raggiungibile, indipendentemente dalle regole del client PTT. Inoltre PttChrome riscrive forzatamente i link Imgur con estensione .jpg: se l'originale è un PNG con trasparenza, qualità o trasparenza possono risentirne, ma questo non influisce sul fatto che l'immagine si apra o meno, solo su come viene visualizzata.

D2: Si può modificare la lista dei domini fidati di term.ptt.cc?

Dal codice sorgente risulta che la funzione parseTrustedDomains supporta la lettura di un elenco personalizzato, quindi è un'impostazione modificabile, non una regola scritta in modo definitivo. Dove trovare esattamente il percorso per modificarla nell'interfaccia, e se serva ricaricare la pagina per renderla effettiva, non l'ho verificato di persona — conviene cercare direttamente nel menu impostazioni di term.ptt.cc.

D3: Perché non hai una risposta certa sulla whitelist di dominio nelle app mobile?

Perché Mo PTT, JPTT, PiTT sono tutte software closed source, non ho trovato codice sorgente pubblico da controllare riga per riga. Tutto quello che questo articolo racconta su queste tre app viene esclusivamente da segnalazioni della community sulla board ask di PTT, non da un'analisi diretta del codice — l'ho già segnalato come non verificato nell'articolo, e non intendo far passare questa parte per una conclusione confermata.

D4: Perché www.ptt.cc non supporta WebP mentre term.ptt.cc sì?

Perché sono due codebase completamente indipendenti — una server-side scritta in Go (pttweb), l'altra frontend in JavaScript (ptt-term), mantenute da persone diverse in momenti diversi. La diffusione del formato WebP è arrivata relativamente tardi, e la regola di pttweb evidentemente non è mai stata aggiornata di conseguenza. Ed è proprio questo il punto centrale di tutto l'articolo: PTT non è un sistema unificato, ma un insieme di software mantenuti in modo indipendente e messi insieme nel tempo.

D5: Se voglio un link che si apra automaticamente su tutti i client PTT, che combinazione conviene?

Non esiste un singolo link adatto a ogni scenario, ma il compromesso più vicino è: assicurarsi che il link diretto dell'host termini con un'estensione standard (.jpg/.png/.gif, evitando di fare affidamento solo su WebP), senza query string, e preferire un host già presente nella whitelist di default di term.ptt.cc (Imgur, meee, duk.tw, ImgBB e Postimages sono tutti in lista). Chi usa PttChrome ha meno margine di scelta — al momento funzionano solo Imgur e Flickr.

Fonti

#PTT#term.ptt.cc#PttChrome#hosting immagini#anteprima automatica immagini#link diretto immagine#forum taiwanese#BBS
A

Scritto da

Alex Chen

Tester di Prodotto

Test pratici di ogni strumento, condividendo esperienze reali in prima persona.