Не удалось декодировать загруженный шрифт
это ошибка, которую я получаю в Chrome и, к сожалению, поиск его не дал мне много результатов. Сам шрифт отображается правильно. Однако я все еще получаю эту ошибку/предупреждение. Более конкретно, это полное предупреждение:
Я просто не понимаю. Шрифт применяется правильно, но предупреждение всегда есть. Пытаюсь использовать Sans-Serif заставляет шрифт вернуться к обычному шрифту браузера, так что это может быть, но я не уверен, и даже после поиска я ничего не нашел. Спасибо!
есть различные файлы шрифтов, все из той же семьи. Я пытаюсь загрузить их все. Файлы шрифтов .ttf . Я загружаю их из локальной папки, и есть различные шрифтовые файлы, такие как Lato-Black.ttf , Lato-Bold.ttf , Lato-Italic.ttf etc.
14 ответов:
в правиле css вы должны добавить расширение файла. Этот пример с максимально возможной поддержкой:
переход из формата (‘woff’) в формат (‘font-woff’) поможет мне решить эту проблему только сейчас.
просто измените небольшое изменение здесь от Germano Plebani answer
пожалуйста, проверьте, если Ваш браузер источники могут открыть его и какой тип
я испытал аналогичную проблему в Visual Studio, которая была вызвана неправильным url() путь к шрифту в вопрос.
я перестал получать эту ошибку после смены (например):
для этого:
убедитесь, что ваш сервер отправляет файлы шрифтов с правом mime / type.
у меня недавно была такая же проблема с использованием nginx потому что некоторые типы шрифтов mime отсутствуют в его ванили .
я исправил проблему, добавив недостающие типы mime в том месте, где они мне были нужны:
вы также можете проверить это для расширения mime.типы в nginx: расширения по умолчанию nginx mime.типы файлов
у меня просто была такая же проблема, и я решил ее, изменив
до
для меня эта ошибка возникла, когда я ссылался на шрифт google с помощью https. Когда я переключился на http, ошибка исчезла. (и да, я пробовал это несколько раз, чтобы подтвердить, что это было причиной)
Я:
To:
мне пришлось добавить type=»text/css» в моей ссылке-теге. Я изменил его с:
to:
после того как я его поменял ошибка исчезла.
У меня была та же проблема с font awesome v4.4, и я исправил ее, удалив формат woff2. Я получал предупреждение только в Chrome.
иногда эта проблема возникает, когда вы загружаете/загружаете шрифты, используя неправильный метод FTP. Шрифты должны быть FTP-ed с использованием двоичного метода, а не ASCII. (В зависимости от вашего настроения, это может показаться нелогичным, lol). Если вы ftp файлы шрифтов с помощью метода ASCII, вы можете получить это сообщение об ошибке. Если вы ftp-файлы с помощью метода «auto», и вы получаете это сообщение об ошибке, попробуйте ftp принудительно двоичный метод.
в моем случае это было вызвано неправильным файлом пути, in .htaccess. пожалуйста, проверьте правильность пути к файлу.
У меня также была такая же проблема, но я решил, добавив «Content-Type»: «application/x-font-ttf» в заголовке ответа для всех .ttf файлы
- добавить файлы шрифтов из локальной файловой системы в subversioned trunk
- ствол работает как ожидалось
- создать SVN патч изменений магистрали, чтобы включить добавление файлов шрифтов
- применить патч к другой ветви
- файлы шрифтов добавляются в ветку subversioned (и могут быть зафиксированы), но повреждены, давая ошибки в ОП.
для меня ошибка заключалась в том, что я забыл перевести FTP в двоичный режим перед загрузкой файлов шрифтов.
Edit
вы можете проверить это, загрузив другие типы двоичных данных, таких как изображения. Если они также не отображаются, то это может быть ваш вопрос.
Если вы используете Express вам нужно обслуживать статического контента, добавив что-то вроде: var server = express(); сервер.использовать(экспресс.статический.'(/общественных’)); // где общественность корневой папке приложения, шрифты, содержащиеся в нем, на любом уровне, т. е. общественных/Fonts или общественных/дист/шрифты. // Если вы используете connect, google для аналогичной конфигурации.
Failed to decode downloaded font
This is an error I am getting in Chrome and unfortunately searching for it hasn’t given me much results. The font itself is appearing correctly. However I still get this error/warning. More specifically, this is the full warning:
My CSS are these:
I just do not understand. The font is applied correctly, but the warning is always there. Trying to use Sans-Serif makes the font revert to the normal browser font, so that may be it, but I am not sure, and even after searching I have found nothing. Thanks!
Webpack «Ошибка разбора OTS» загрузка шрифтов
В моей конфигурации веб-пакета указано, что шрифты должны загружаться с использованием url-loader , и когда я пытаюсь просмотреть страницу с помощью Chrome, я получаю следующую ошибку:
Соответствующие части моей конфигурации выглядят так:
В Safari этого не происходит, и я не пробовал Firefox.
В разработке я обслуживаю файлы через webpack-dev-server , в производстве они записываются на диск и копируются в S3; в обоих случаях я получаю одинаковое поведение в Chrome.
Это также происходит с изображениями большего размера (превышающими ограничение в 10 КБ в конфигурации загрузчика изображений).
13 ответов
TL; DR Используйте абсолютные пути к своим активам (включая полное имя хоста), задав для output.publicPath значение, например «http://example.com/assets/».
Проблема
Проблема заключается в способе разрешения URL-адресов в Chrome при их анализе из динамически загружаемого блоба CSS.
Когда вы загружаете страницу, браузер загружает ваш файл JavaScript записи пакета Webpack, который (когда вы используете style-loader ) также содержит копию вашего CSS в кодировке Base64, которая загружается на страницу.
Вот как это выглядит в Chrome DevTools
Это нормально для всех изображений или шрифтов, которые закодированы в CSS как URI данных (т.е. содержимое файла встроено в CSS), но для ресурсов, на которые ссылается URL , браузер должен найти и загрузите файл.
Теперь по умолчанию file-loader (который url-loader делегирует для больших файлов) будет использовать относительные URL-адреса для ссылки на ресурсы — и в этом проблема!
Это URL-адреса, сгенерированные file-loader по умолчанию — относительные URL-адреса
Когда вы используете относительные URL-адреса, Chrome разрешает их относительно содержащего CSS-файла. Обычно это нормально, но в этом случае содержащий файл находится по адресу blob://. , и любые относительные URL-адреса указываются таким же образом. Конечным результатом является то, что Chrome пытается загрузить их из родительского HTML-файла и пытается проанализировать HTML-файл как содержимое шрифта, что, очевидно, не сработает.
Решение
Заставьте file-loader использовать абсолютные пути, включая протокол («http» или «https»).
Измените конфигурацию вашего веб-пакета, чтобы включить что-то эквивалентное:
Теперь генерируемые им URL-адреса будут выглядеть так:
Эти URL-адреса будут правильно анализироваться Chrome и любым другим браузером.
Использование extract-text-webpack-plugin
Стоит отметить, что если вы извлекаете свой CSS в отдельный файл, у вас не будет этой проблемы, потому что ваш CSS будет в правильном файле, а URL-адреса будут правильно разрешены.
По состоянию на 2018 год
use MiniCssExtractPlugin
Для Webpack (> 4.0) решит эту проблему.
Использование extract-text-webpack-plugin в принятом ответе НЕ рекомендуется для Webpack 4.0+.
У меня была такая же проблема с Font Awesome. Оказалось, это было вызвано проблемой с FTP. Файл был загружен как текстовый (ASCII), а не как двоичный, что повредило файл. Я просто изменил свое программное обеспечение FTP на двоичный, повторно загрузил файлы шрифтов, и все заработало.
https: // css-tricks .com / forum / topic / custom-fonts-returns-failed-to-decode-loaded-font /. это помогло мне в конце концов У меня была такая же проблема с FTP-передачей файлов в виде текста
У меня возникла та же проблема, но по разным причинам.
После того, как решение Уилла Мэддена не помогло, я попробовал все альтернативные исправления, которые мог найти через Intertubes — также безрезультатно. Исследуя дальше, я случайно открыл один из рассматриваемых файлов шрифтов. Исходное содержимое файла каким-то образом было перезаписано Webpack, чтобы включить какую-то информацию о конфигурации, вероятно, из-за предыдущей работы с загрузчиком файлов. Я заменил поврежденные файлы на оригиналы, и вуаля, ошибки исчезли (как для Chrome, так и для Firefox).
[loader] Failed to decode downloaded font. OTS parsing error: invalid version tag #1468
The text was updated successfully, but these errors were encountered:
But the url is .woff2?v=4.4.0 and .woff2?xxxx
Thank you. It works when the test is /\.woff2(\?\S*)?$/ .
Please verify on awesome-fonts .css file if the url path for fonts are ok. It works for me.
I removed all other config and used this:
I hope this helps someone else too.
remember: remove other font test configurations for fonts.
Hello @isramv, on your snippet, I think there is a typo on minetype , shouldn’t be mimetype ?
I’m having this same issue, and none of the above seem to work for me.
Not yet, unfortunately :/
@mbifulco if you find anything I’d love to see that as well .. ��
Thanks, @isramv . This worked great for me.
Didn’t work neither for woff/woff2 files, but now it’s ok. What I did:
I also re-converted my font files using online convertors, and now it works like a charm.
@LaCroute What is «utils» in your example?
I’d like to share the solution to my problem that’s fairly same as yours for those who google they way out here (like me).
Given my folder structure
The output css file was trying to import font files at the same folder level of it.
So it always hit 404 /css/font.x and my server rendered 404 error was mistaken as a broken font. That’s why Failed to decode downloaded font. OTS parsing error: invalid version tag .