Decodifica del carattere scaricato non riuscita

Questo è un errore che sto riscontrando in Chrome e purtroppo la ricerca non mi ha dato molti risultati. Il carattere stesso viene visualizzato correttamente. Tuttavia ricevo ancora questo errore / avviso. Più specificamente, questo è l'avvertimento completo:

"Impossibile decodificare il carattere scaricato: http: // localhost: 8000 / app / fonts / Lato / "

I miei CSS sono questi:

@font-face {
    font-family:"Lato";
    src: url("../fonts/Lato/");
}

html, body {
    font-family:'Lato';
}

Non capisco. Il carattere è applicato correttamente, ma l'avviso è sempre presente. Cercare di utilizzare Sans-Seriffa tornare il carattere al normale carattere del browser, quindi potrebbe essere così, ma non ne sono sicuro, e anche dopo la ricerca non ho trovato nulla. Grazie!

MODIFICARE

Esistono vari file di caratteri, tutti della stessa famiglia. Sto cercando di caricarli tutti. I file dei caratteri sono .ttf. Li sto caricando da una cartella locale, e ci sono diversi di font-files, come Lato-Black.ttf, Lato-Bold.ttf, Lato-Italic.ttfetc.

Nella regola CSS devi aggiungere l'estensione del file. Questo esempio con il supporto più profondo possibile:

@font-face {
  font-family: 'MyWebFont';
  src: url('webfont.eot'); /* IE9 Compat Modes */
  src: url('webfont.eot?#iefix') format('embedded-opentype'), /* IE6-IE8 */
       url('webfont.woff2') format('woff2'), /* Super Modern Browsers */
       url('webfont.woff') format('woff'), /* Pretty Modern Browsers */
       url('webfont.ttf')  format('truetype'), /* Safari, Android, iOS */
       url('webfont.svg#svgFontName') format('svg'); /* Legacy iOS */
}

MODIFICARE:

"Impossibile decodificare il carattere scaricato" significa che il carattere è corrotto o incompleto (metriche mancanti, tabelle necessarie, record di denominazione, un milione di cose possibili).

A volte questo problema è causato dal font stesso. Google font fornisce il font corretto di cui hai bisogno, ma se il font face è necessario io uso Transfonter per generare tutto il formato del font.

A volte è il client FTP che corrompe il file (non in questo caso perché si trova sul PC locale). Assicurati di trasferire il file in binario e non in ASCII.

Ho riscontrato un problema simile in Visual Studio, causato da un url()percorso errato del carattere in questione.

Ho smesso di ottenere questo errore dopo aver modificato (ad esempio):

@@font-face{
    font-family: "Example Font";
    src: url("/Fonts/ExampleFont.eot?#iefix");

a questa:

@@font-face{
    font-family: "Example Font";
    src: url("../fonts/ExampleFont.eot?#iefix");

Il passaggio dal formato ('woff') al formato ('font-woff') mi aiuta a risolvere questo problema proprio ora.

Basta cambiare un piccolo cambiamento qui dalla risposta Germano Plebani

 @font-face {
  font-family: 'MyWebFont';
  src: url('webfont.eot'); /* IE9 Compat Modes */
  src: url('webfont.eot?#iefix') format('embedded-opentype'), /* IE6-IE8 */
       url('webfont.woff2') format('woff2'), /* Super Modern Browsers */
       url('webfont.woff') format('font-woff'), /* Pretty Modern Browsers */
       url('webfont.ttf')  format('truetype'), /* Safari, Android, iOS */
       url('webfont.svg#svgFontName') format('svg'); /* Legacy iOS */
}

Controlla se le fonti del tuo browser possono aprirlo e qual è il tipo

Assicurati che il tuo server stia inviando i file dei caratteri con il mime / tipo giusto .

Recentemente ho avuto lo stesso problema usando nginx perché nel suo /etc/nginx/mime.typesfile vanilla mancano alcuni tipi di font mime .

Ho risolto il problema aggiungendo i tipi di mime mancanti nella posizione in cui ne avevo bisogno in questo modo:

location /app/fonts/ {

  #Fonts dir
  alias /var/www/app/fonts/;

  #Include vanilla types
  include mime.types;

  #Missing mime types
  types  {font/truetype ttf;}
  types  {application/font-woff woff;}
  types  {application/font-woff2 woff2;}
}

Puoi anche verificarlo per estendere mime.types in nginx: estensione del file mime.types predefinito nginx

Ho dovuto aggiungere type="text/css"al mio tag-link. L'ho cambiato da:

<link href="https://fonts.googleapis.com/css?family=Roboto+Condensed:300,400,700" rel="stylesheet">

per:

<link href="https://fonts.googleapis.com/css?family=Roboto+Condensed:300,400,700" rel="stylesheet" type="text/css">

Dopo averlo modificato, l'errore è scomparso.

Ho appena avuto lo stesso problema e risolto cambiando

src: url("Roboto-Medium-webfont.eot?#iefix")

per

src: url("Roboto-Medium-webfont.eot?#iefix") format('embedded-opentype')

Per me, questo errore si è verificato quando ho fatto riferimento a un carattere Google utilizzando https. Quando sono passato a http, l'errore è scomparso. (e sì, l'ho provato più volte per confermare che era la causa)

Quindi ho cambiato:

@import url(https://fonts.googleapis.com/css?family=Roboto:300,400,100,500,900);

Per:

@import url(http://fonts.googleapis.com/css?family=Roboto:300,400,100,500,900);

A volte questo problema si verifica quando si caricano / scaricano i caratteri utilizzando il metodo FTP errato. I caratteri devono essere FTP-ed usando il metodo binario, non ASCII. (A seconda del tuo umore, può sembrare controintuitivo, lol). Se si ftp i file dei caratteri utilizzando il metodo ASCII, è possibile visualizzare questo messaggio di errore. Se si ftp i file con un metodo "auto" e viene visualizzato questo messaggio di errore, provare ftp forzando il metodo binario.

Stavo avendo lo stesso problema con font awesome v4.4 e l'ho risolto rimuovendo il formato woff2. Stavo ricevendo un avviso solo in Chrome.

@font-face {
  font-family: 'FontAwesome';
  src: url('../fonts/fontawesome-webfont.eot?v=4.4.0');
  src: url('../fonts/fontawesome-webfont.eot?#iefix&v=4.4.0') format('embedded-opentype'), url('../fonts/fontawesome-webfont.woff?v=4.4.0') format('woff'), url('../fonts/fontawesome-webfont.ttf?v=4.4.0') format('truetype'), url('../fonts/fontawesome-webfont.svg?v=4.4.0#fontawesomeregular') format('svg');
  font-weight: normal;
  font-style: normal;
}

Nel mio caso è stato causato con un file di percorso errato, in .htaccess. si prega di verificare la correttezza del percorso del file.

Per me, l'errore era dimenticare di mettere FTP in modalità binaria prima di caricare i file dei caratteri.

modificare

Puoi verificarlo caricando altri tipi di dati binari come le immagini. Se anche non riescono a essere visualizzati, questo potrebbe essere il tuo problema.

Ho anche avuto lo stesso problema, ma ho risolto aggiungendo 'Content-Type': 'application / x-font-ttf' nell'intestazione della risposta per tutti i file .ttf

Nel mio caso, ciò è stato causato dalla creazione di un file patch SVN che includeva l'aggiunta dei file dei caratteri. Così:

1. Aggiungi i file dei font dal file system locale al trunk sovversivo
2. Il trunk funziona come previsto
3. Crea patch SVN di modifiche al trunk, per includere l'aggiunta di file di font
4. Applica patch su un altro ramo
5. I file di caratteri vengono aggiunti al ramo secondario (e possono essere sottoposti a commit), ma sono danneggiati, producendo errori in OP.

La soluzione era caricare i file dei caratteri direttamente nel ramo dal mio file system locale. Suppongo che ciò sia accaduto perché i file patch SVN devono convertire tutto in formato ASCII e non necessariamente conservare i file binari per i file dei caratteri. Ma questa è solo una supposizione.

Nel mio caso - usando React con Gatsby - il problema è stato risolto ricontrollando tutti i miei percorsi. Stavo usando React / Gatsby con Sass e i file sorgente di Gatsby cercavano i caratteri in un posto diverso rispetto ai file compilati. Dopo aver duplicato i file in ogni percorso, questo problema era scomparso.

Nel mio caso durante il download di un modello i file dei caratteri erano solo file vuoti. Probabilmente un problema con il download. Chrome ha dato questo errore generico al riguardo. All'inizio ho pensato alla soluzione di cambiarla woffper font-woffrisolverla, ma ha fatto sì che Chrome ignorasse solo i caratteri. La mia soluzione era trovare i caratteri uno per uno e scaricarli / sostituirli.

Se stai usando express devi consentire la pubblicazione di contenuti statici aggiungendo qualcosa come: var server = express (); server.use (express.static ( './ pubblico')); // dove public è la cartella principale dell'app, con i caratteri in essa contenuti, a qualsiasi livello, ad esempio public / fonts o public / dist / fonts ... // Se si utilizza connect, google per una configurazione simile.

Uso .Net Framework 4.5 / IIS 7

Per ripararlo ho messo il file Web.config nella cartella con il file del carattere.

Contenuto di Web.config:

<?xml version="1.0"?>
<configuration>
  <system.web>
    <authorization>
      <allow users="*" />
    </authorization>
  </system.web>
</configuration>

per me è stato un problema con i file lfs che non sono stati scaricati

git lfs fetch --all

risolto il problema.

vedi https://github.com/git-lfs/git-lfs/issues/325

Se si trova sul server (non in localhost), prova a caricare manualmente i caratteri, perché a volte il client FTP (ad esempio FileZilla) corrompe i file e può causare il problema. Per quanto mi riguarda, ho caricato manualmente utilizzando l'interfaccia Cpanel.

Il mio caso sembrava simile ma il carattere era corrotto (e quindi impossibile da decodificare). È stato causato dalla configurazione in Maven. L'aggiunta di nonFilteredFileExtension per le estensioni dei font all'interno maven-resources-pluginmi ha aiutato:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-resources-plugin</artifactId>
    <configuration>
        <nonFilteredFileExtensions>
            <nonFilteredFileExtension>ttf</nonFilteredFileExtension>
            <nonFilteredFileExtension>otf</nonFilteredFileExtension>
            <nonFilteredFileExtension>woff</nonFilteredFileExtension>
            <nonFilteredFileExtension>woff2</nonFilteredFileExtension>
            <nonFilteredFileExtension>eot</nonFilteredFileExtension>
        </nonFilteredFileExtensions>
    </configuration>
</plugin>