I just hit this same problem, and have found a fix.
As an answer to Martjin's question, the problem is that these URF-8 BOM characters invalidate the javascript when the client is expecting pure ASCII. So it will say there is an error at char 1, line 1 or some such, basically, right at the beginning of the file because it makes the codefile look like there's a typo in the first few bytes of the script.
In my case, I have a Site in IIS that is an ASP.NET app, and an Application underneath it that is also an ASP.NET app. This had caused some complications with inheriting web.configs, and the solution was to put a tag that negates inheritance from that point on.
I then discovered that all my .js in the child site was throwing an error for that stupid UTF-8 encoding symbol that was the first 3 bytes of every file. I am reasonably confident, that it is caused by some confusion in the httphandlers from my 2-tier solution for web.configs.
My solution, however was to convert the .js files back to pure ASCII, as that's what IIS was sending out and the client was expecting. For me, I have a build.bat that copies all the web files, removes any source control and project files and puts them all in a final build directory for copying to the test or production server. I made a modification to that script to also convert all the .js files to ASCII format.
It uses a combination of DOS batch (because that's where I started) and PowerShell (because that's the only way I found to convert without adding even more utility programs):
set DIRTOCONVERT=whatever path you want it to convert all the files for
ECHO remove UTF-8 BOM chars ï»? from front of files
for /r %DIRTOCONVERT% %%g in (*.js) do (
powershell -command "gc -en utf8 \"%%g\" | Out-File -en ascii .\tmp.txt"
move /y .\tmp.txt "%%g"
)
Note, a few people online (even in StackOverflow) had the idea to try:
type badfile.txt > goodfile.txt
but that still carries over the UTF-8 encoding. Apparently, it did not used to do that.