http://dev.clojure.org/jira This file is an XML representation of an issue en-us 4.4 649 25-07-2011 http://dev.clojure.org/jira/browse/CLJS-133 ClojureScript <p>the following call: (reader/read-string "{:status :ok}") produces {"\uFFFD'status" "\uFFFD'ok"} which differs from expected {:status :ok}<br/> the server inserts proper content-type (utf-8) header for all javascript files</p> <p>the problem disappears if unicode special characters are manually replaced with their escaped equivalents ("\uFDD0") in cljs.core.keyword function in the compiled core.js file<br/> it doesn't disappear when call to the str_STAR_ function is replaced to the concatenation operators, which suggest that the function works correctly and adds some mystery to the problem</p> <p>currently I have no possibility to reproduce the problem on other system, so I'm not certain in all of the aspects</p> Windows 7 x86, MSIE 9, Jetty CLJS-133

reader/read-string produces malformed keywords in IE9

Defect Minor Resolved Completed Unassigned g. christensen reader Fri, 20 Jan 2012 20:17:19 -0600 Sat, 25 Feb 2012 10:25:29 -0600 Sat, 25 Feb 2012 10:25:29 -0600 0 1 <p>Keywords in ClojureScript are just JavaScript strings. If you mean that you're seeing this on the client, that is expected, are you saying that you're seeing this in the ClojureScript REPL?</p> <p>Yes, I know about the internal keyword representation, the result {"\uFFFD'status" "\uFFFD'ok"} is taken from (pr-str (reader/read-string "{:status :ok}")) put in the `alert' call, in other browsers it returns {:status :ok}, but in IE it returns the string above. Comparison of such keywords with hardcoded keywords returns nil, so most likely they are not interpreted as keywords (as you may notice, the special character code in malformed keyword differs from the character hardcoded in the clojurescript code of the `keyword' function (\uFDD0 vs \uFFFD). <br/> It's strange because it works perfectly in other browsers, and it's like that it's a some sort of endianness problem or something, but I don't know so much about IE internals and can't judje on this matter.<br/> I have tried to reproduce the problem on other machine with IE 9.0.8112.16421 64bit update 9.0.3 and it's still there.</p> <p>I just have read some of unicode specifications and found: "U+FFFD � replacement character used to replace an unknown or unprintable character", so it probably necessary to find point where the noncharacter replaced with this character, or may be the raw nonescaped noncharacter is replaced internally by \uFFFD and there is no distinction between keywords and other symbols in IE, obtained through read-string (it may process files correctly but replace noncharacters in constructed strings).</p> <p>Having people looking into the IE issues is fantastic - this is similar to another IE9 reader issue, do you have an approach that you think will solve the problem? Thanks.</p> <p>The only thing I can think up is to place \uFDD0 and \uFDD1 escaped literals instead of raw characters in compiled JavaScript output or some compiler hack which will place the escaped literals in `keyword' and `symbol' construction functions.</p> <p>And you're sure that you're setting the utf-8 meta tag in your HTML document?</p> <p>Same as <a href="http://dev.clojure.org/jira/browse/CLJS-139" title="Internet Explorer treats \uFDD0 up to \uFDEF as equal so some keyword and symbol related things do not work"><del>CLJS-139</del></a></p> <p>This ticket is different from <a href="http://dev.clojure.org/jira/browse/CLJS-139" title="Internet Explorer treats \uFDD0 up to \uFDEF as equal so some keyword and symbol related things do not work"><del>CLJS-139</del></a>, this is only about the reader.</p> <p>applying <a href="http://dev.clojure.org/jira/secure/attachment/10939/cljs-133_fix.patch">http://dev.clojure.org/jira/secure/attachment/10939/cljs-133_fix.patch</a> to the current HEAD makes read-string work as expected. This is because David's patch for cljs-139 (<a href="http://dev.clojure.org/jira/secure/attachment/10913/139_fix_unicode_emit.patch">http://dev.clojure.org/jira/secure/attachment/10913/139_fix_unicode_emit.patch</a>) does not address the "emit-constant" multimethod for String (only Character, clojure.lang.Keyword and clojure.lang.Symbol). Will will have to do the same replacement for String (each character) as David did for Character (maybe by utilizing clojure.string.replace) to make the 2 functions I patched in core.cljs work in the previous unpatched state (I hope someone can understand my gibberish <img class="emoticon" src="http://dev.clojure.org/jira/images/icons/emoticons/smile.gif" height="20" width="20" align="absmiddle" alt="" border="0"/></p> <p>!!! deleted referenced patch because it is now obsolete !!!</p> <p>I have attached a patch to <a href="http://dev.clojure.org/jira/browse/CLJS-139">CLJS-139</a> which fixes this related issue.</p> <p>I have just attached a <a href="http://dev.clojure.org/jira/secure/attachment/10949/general-escaping-emit-constant.patch">general non-ascii escape patch</a> to <a href="http://dev.clojure.org/jira/browse/CLJS-139">CLJS-139</a> which obsoletes my <a href="http://dev.clojure.org/jira/secure/attachment/10945/cljs-139%2B133_symbol%2Bkeyword-fix.patch">previous one</a>!</p> <p>Fixed, <a href="https://github.com/clojure/clojurescript/commit/965dc505229652558adcb526ecb5a9f91ce31ce2">https://github.com/clojure/clojurescript/commit/965dc505229652558adcb526ecb5a9f91ce31ce2</a></p> Global Rank