0

Possible Duplicate:
UTF-8 issue in Firefox - response header overriding meta tag?

I have a jPlayer playlist that works fine in all browsers except Firefox.

The issue is with non-standard characters, i.e. characters with accents or asian characters. I have set up a demo playlist so that you can see here.

When I enter the characters in UTF-8 form (track 1 in the playlist) they work on all browsers except for Firefox, and when I enter them in ISO Latin 1 (track 2 in the playlist) they work in Firefox but no other browsers.

So, for instance in Firefox 大å°æ¸æ¿.mp3 works, whereas 大地書房.mp3 doesn't.

When I use 大地書房.mp3 in the Firebug console I see the following error:

"NetworkError: 404 Not Found - http://monthlymixup.com/mixups/july_2012/media/simon/03%20????.mp3"

So, for some reason 大地書房.mp3 becomes %20????. When I inspect the page the link to the audio file shows as 大地書房.mp3 though.

There is a meta tag for UTF-8 on the demo page, i.e. <meta charset=utf-8 />

My understanding is that Firefox overwrites this with the response header if a default encoding isn't set in FF. I have however set UTF-8 to be the default encoder and I have checked that the page is using UTF-8 by going to Tools/Page Info (I am on a Mac and I believe this is the way to check the encoding on the page).

So, I'm at a loss as to what is going on, and would be glad of some help.

Community
  • 1
  • 1
Nick
  • 4,304
  • 15
  • 69
  • 108
  • Can you please specify how the issue can be reproduced on Firefox? Something like “go to URL ... and click on ..., then ... should happen but in fact ... happens”. When I go to http://monthlymixup.com/mixups/july_2012/demo.html I cannot see any problem. – Jukka K. Korpela Jul 25 '12 at 17:06
  • @JukkaK.Korpela In Firefox only the 2nd and 3rd tracks in the playlist play (i.e. the 1st track doesn't play) – Nick Jul 25 '12 at 18:08
  • @Daniel Do you mean, who hosts my website? If so, it's a shared hosting package on Cirtex – Nick Jul 25 '12 at 18:21
  • @Daniel It's php/apache. – Nick Jul 25 '12 at 18:34

1 Answers1

0

This seems to be an encoding issue in jQuery or other software used. The entry 2 is in an odd format: looking at the source as UTF-8, I see

mp3:"media/nick/Guessi-Guéré-Guessi (Pop Bariba).mp3"

This means that the letter “é” has been represented in UTF-8, as two octets, and then these octets have been interpreted as if they were ISO-8859-1 encoded, and the resulting characters have been UTF-8 encoded. Presumably the software deals with the mess by performing the opposite double decoding. In any case, it does not work with

mp3:"media/simon/03 大地書房.mp3"

which is just UTF-8 encoded.

It puzzles me how it works on any browser, but presumably the code is browser-dependent.

The software should be changed to deal with UTF-8 as such and pass it forward, if possible. All modern browsers, including Firefox, can then deal with it properly.

As a quick fix, though, you might try to use a percent-encoded form (see e.g. online percent-encoder):

mp3: "media/simon/03%20%E5%A4%A7%E5%9C%B0%E6%9B%B8%E6%88%BF.mp3"

But this is just a guess; the software might munge this, percent-encoding the “%” sign.

Jukka K. Korpela
  • 195,524
  • 37
  • 270
  • 390
  • Thanks. Just to be clear, the `mp3:"media/nick/Guessi-Guéré-Guessi (Pop Bariba).mp3"` is how I have written the code, to show that it works in Firefox. `Guéré` is the ISO-8859-1 version of `Guéré` – Nick Jul 25 '12 at 20:49
  • @Nick, no, in ISO-8859-1, “é” is a single byte. You can get “é” only by first UTF-8 encoding the “é”, then interpreting the resulting bytes as characters. – Jukka K. Korpela Jul 25 '12 at 21:11