Webpack" OTS parsing error " chargement des polices de caractères
ma configuration webpack spécifie que les polices doivent être chargées en utilisant url-loader
, et quand j'essaie de voir la page en utilisant Chrome j'obtiens l'erreur suivante:
OTS parsing error: invalid version tag
Failed to decode downloaded font: [My local URL]
les parties pertinentes de ma config ressemblent à ceci:
{
module: {
loaders: [
// ...
{
test: /.scss$/,
loaders: ['style', 'css?sourceMap', 'autoprefixer', 'sass?sourceMap'],
},
{
test: /images/.*.(png|jpg|svg|gif)$/,
loader: 'url-loader?limit=10000&name="[name]-[hash].[ext]"',
},
{
test: /fonts/.*.(woff|woff2|eot|ttf|svg)$/,
loader: 'file-loader?name="[name]-[hash].[ext]"',
}
],
},
}
ça n'arrive pas en Safari, et je n'ai pas essayé le Firefox.
en développement je sers des fichiers à travers webpack-dev-server
, en production ils sont écrits sur disque et copiés sur S3; en dans les deux cas, J'obtiens le même comportement dans Chrome.
cela arrive aussi aux images plus grandes (plus grandes que la limite de 10kB dans la configuration du chargeur d'image).
9 réponses
TL;DR utilisez des chemins absolus vers vos actifs (y compris votre nom d'hôte complet) en paramétrant votre output.publicPath
à " http://example.com/assets / ".
le problème
le problème est la façon dont les URLs sont résolues par Chrome lorsqu'elles sont séparées à partir d'un blob CSS chargé dynamiquement.
lorsque vous chargez la page, le navigateur charge votre entrée webpack bundle Le fichier JavaScript, qui (lorsque vous utilisez le style-loader
) contient aussi une copie codée Base64 de votre CSS, qui est chargée dans la page.
c'est très bien pour toutes les images ou les polices qui sont encodées dans le CSS comme URIs de données (c.-à-d. le contenu du fichier est intégré dans le CSS), mais pour les actifs référencé par URL , le navigateur doit trouver et récupérer le fichier.
maintenant par défaut le file-loader
(auquel url-loader
délègue pour les grands fichiers) utilisera relatif URLs aux biens de référence-et c'est le problème!
ce sont les URLs générées par
file-loader
par défaut d'Url relatives
lorsque vous utilisez des URLs relatives, Chrome les résoudra par rapport au fichier CSS contenant. Normalement c'est très bien, mais dans ce cas le fichier contenant est à blob://...
et toutes les URL relatives sont référencées de la même manière. Le résultat final est que Chrome tente de les charger à partir du fichier HTML parent, et finit par essayer d'analyser le fichier HTML comme le contenu de la police, ce qui évidemment ne fonctionnera pas.
La Solution
oblige le file-loader
à utiliser des chemins absolus incluant le protocole ("http "ou"https").
changez votre configuration webpack pour inclure quelque chose d'équivalent à:
{
output: {
publicPath: "http://localhost:8080/", // Development Server
// publicPath: "http://example.com/", // Production Server
}
}
maintenant les URLs qu'il génère ressembleront à ceci:
ces URLs seront correctement interprétées par Chrome et tous les autres navigateurs.
utilisant extract-text-webpack-plugin
il est intéressant de noter que si vous extrayez votre CSS vers un fichier séparé, vous n'aurez pas ce problème car votre CSS sera dans un fichier approprié et les URL seront correctement résolues.
comme asnwered ici par @mcortesi si vous supprimez les sources de la requête du chargeur css le css sera construit sans l'utilisation de blob et les urls de données seront analysés amende
pour moi le problème était mon expression regex. Le ci-dessous a fait le tour pour obtenir bootstrap de travail
{ test: /\.(woff|ttf|eot|svg)(\?v=[a-z0-9]\.[a-z0-9]\.[a-z0-9])?$/, loader: 'url-loader?limit=100000' },
comme pour @user3006381 ci-dessus, mon problème n'était pas seulement les URL relatives mais que webpack plaçait les fichiers comme s'ils étaient des fichiers javascript. Leur contenu était essentiellement:
module.exports = __webpack_public_path__ + "7410dd7fd1616d9a61625679285ff5d4.eot";
dans le répertoire de polices au lieu des polices réelles et les fichiers de polices se trouvaient dans le dossier de sortie sous des codes de hachage. Pour corriger cela, j'ai dû changer le test sur mon chargeur d'url (dans mon cas mon processeur d'image) pour ne pas charger le dossier fonts. Je devais encore régler la sortie.publicPath in webpack.config.js as @will-madden note dans son excellente réponse.
j'ai connu le même problème, mais pour des raisons différentes.
après la solution de Will Madden n'a pas aidé, j'ai essayé toutes les solutions de rechange que je pouvais trouver via les Intertubes - également en vain. Pour en savoir plus, je viens d'ouvrir un des fichiers de police en question. Le contenu original du fichier avait été en quelque sorte écrasé par Webpack pour inclure une sorte d'information de configuration, probablement à cause de bricolages antérieurs avec le chargeur de fichiers. J'ai remplacé les corrompus les fichiers avec les originaux, et voilà, les erreurs ont disparu (pour Chrome et Firefox).
je sais que cela ne répond pas à la question exacte de L'OPs mais je suis venu ici avec le même symptôme mais une cause différente:
j'ai eu le .fichiers scss de Slider Slick inclus comme ceci:
@import "../../../node_modules/slick-carousel/slick/slick.scss";
après une inspection plus approfondie, il s'est avéré que le il essayait de charger la police d'un emplacement invalide ( <host>/assets/css/fonts/slick.woff
), la façon dont il a été référencé à partir de la feuille de style.
j'ai fini par simplement copier le /font/
à mon assets/css/
et le problème a été résolu pour moi.
puisque vous utilisez url-loader
:
le chargeur d'url fonctionne comme le chargeur de fichiers, mais peut renvoyer un Datarul si le fichier est plus petit qu'une limite de byte.
donc une autre solution à ce problème serait de rendre la limite suffisamment élevée pour que les fichiers de police soient inclus comme DataURL, par exemple à 100000
qui sont plus ou moins 100Kb
:
{
module: {
loaders: [
// ...
{
test: /\.scss$/,
loaders: ['style', 'css?sourceMap', 'autoprefixer', 'sass?sourceMap'],
},
{
test: /images\/.*\.(png|jpg|svg|gif)$/,
loader: 'url-loader?limit=10000&name="[name]-[hash].[ext]"',
},
{
test: /\.woff(\?v=\d+\.\d+\.\d+)?$/,
use: 'url-loader?limit=100000&mimetype=application/font-woff',
},
{
test: /\.woff2(\?v=\d+\.\d+\.\d+)?$/,
use: 'url-loader?limit=100000&mimetype=application/font-woff',
},
{
test: /\.ttf(\?v=\d+\.\d+\.\d+)?$/,
use: 'url-loader?limit=100000&mimetype=application/octet-stream',
},
{
test: /\.eot(\?v=\d+\.\d+\.\d+)?$/,
use: 'file-loader',
},
{
test: /\.svg(\?v=\d+\.\d+\.\d+)?$/,
use: 'url-loader?limit=100000&mimetype=image/svg+xml',
},
],
},
}
Tout en tenant compte de ce que représente le nombre limite:
limite d'Octets de l'inclure des fichiers de Données d'URL
de cette façon, vous n'avez pas besoin de spécifier l'URL complète des actifs. Ce qui peut être difficile quand vous voulez que Webpack ne réponde pas seulement depuis localhost.
dernière considération, cette configuration n'est pas recommandée pour la production. C'est juste pour le développement de la facilité.
si vous utilisez Angular vous devez vérifier pour être sûr de votre
<base href="/">
tag vient avant votre paquet de feuilles de style. J'ai changé mon code de ceci:
<script src="~/bundles/style.bundle.js"></script>
<base href="~/" />
à ceci:
<base href="~/" />
<script src="~/bundles/style.bundle.js"></script>
et le problème a été résolu. Merci à ce post pour m'avoir ouvert les yeux.
en date de 2018,
use MiniCssExtractPlugin
pour Webpack(> 4.0) résoudra ce problème.
https://github.com/webpack-contrib/mini-css-extract-plugin
utilisant extract-text-webpack-plugin
dans la réponse acceptée est et non recommandé pour Webpack 4.0+.