2

I'm currently working on a website that has two versions, one American website that's served as utf-8 and one Japanese version that's served as Shift JIS. The site is generated using Perl.

The problem:

I'm serving Javascript akin to the following. 

var text = "test \"quote\"";

Which, on the Japanese site, is returning an error "Uncaught SyntaxError: Unexpected identifier." This is because the backslash is being converted to an elongated backslash character ＼, which isn't seen as an escape character and thus is breaking the line.

I can't seem to find anyone else running into this problem which makes me suspicious that there isn't something fundamentally wrong with our website. Has anyone encountered a similar situation and found a solution?

Many thanks

Sir Hound
  • 94
  • 3
  • 1
    It's impossible to help you without your Perl code. – daxim May 02 '13 at 12:03
  • Well that line is raw JS as part of a Mason template that is embedded in a few thousand other lines of code. – Sir Hound May 02 '13 at 13:09
  • You should at least show us the part of the code that does the encoding. If it is done by Mason, show us how you setup Mason to do it. – dolmen May 02 '13 at 15:25
  • I don't have ownership or access to it, I realise that's not particularly helpful but the only part of it that's relevant is that its encoded in shift JIS. I'm going to update this with a hack that I found though. Thanks for reading! – Sir Hound May 02 '13 at 15:41

1 Answers1

1

I found some helpful information here:

Why browser is showing different back slash for a email validation regex. How to prevent that?

Which lead me to this upsetting hack:

var text = "test ¥"quote¥"";

This works perfectly. Now, obviously this isn't the way to do it, but it will enable other devs to get on testing other JS interactions on the site while I concentrate on refactoring this code into something that doesn't rely on character escaping. I hope this information helps someone else at some point!

Community
  • 1
  • 1
Sir Hound
  • 94
  • 3
  • 1
    I've run into the same thing, but in the reverse direction, "\" in the Shift_JIS encoded Simulink files is getting turned into "¥", most frequently with "\n" becoming "¥n" (that's a literal \n and not a new-line character, although if not for the "conversion" it would get interpreted by Simulink as such). This happens in my case using `iconv -f shift_jis -t utf8 `. – Ben Hocking Jul 16 '15 at 07:55