J'ai vu cet article:  characters appended to the begining of each file.Caractère ï »¿(BOM UTF-8) au milieu de la réponse ASP.NET en raison de HttpResponse.TransmitFile()
Dans ce cas, l'auteur lisait manuellement le fichier source et écrivait le contenu. Dans mon cas, je suis abstraite par HttpRequest. TransmitFile():
public void ProcessRequest(HttpContext context)
{
HttpRequest req = context.Request;
HttpResponse resp = context.Response;
resp.ContentType = "application/javascript";
resp.TransmitFile("foo.js");
resp.TransmitFile("bar.js");
resp.TransmitFile("baz.js");
}
Les fichiers .js sont en effet encodées en UTF-8. Cela signifie que la nomenclature n'apparaît pas correctement au début de chaque fichier sauf le premier. Les bonnes choses à propos de TransmitFile() sont que (a) il extrait tout le processus de lecture et d'écriture, et (b) il est optimisé pour ne pas lire les fichiers en mémoire - ce qui est extrêmement important quand les fichiers sont grand et/ou vous avez beaucoup de demandes simultanées. Mais le revers de la médaille est que je ne suis pas capable de le ré-encoder en UTF-8 sans la nomenclature. (Je suppose que ceci est un exemple d'abstraction qui fuit.)
Existe-t-il une manière élégante de résoudre ce problème? Merci!
Est-ce réellement un problème en pratique? La nomenclature est un caractère d'espace (espace non brisé de largeur nulle, point de code U + FFFE). L'interprète JS étouffe-t-il? –
Plus important encore, IE7 et ci-dessous s'étrangler dessus (caractère non valide). Moins important mais toujours agaçant, JSLint s'étouffe. –
Je ne pense pas que TransmitFile fait des optimisations magiques pour la transmission, rien que vous ne pourriez recréer avec les pompes de lecture/écriture de flux – meandmycode