reader/read-string produces malformed keywords in IE9


the following call: (reader/read-string "{:status :ok}") produces {"\uFFFD'status" "\uFFFD'ok"} which differs from expected {:status :ok}
the server inserts proper content-type (utf-8) header for all javascript files

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
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

currently I have no possibility to reproduce the problem on other system, so I'm not certain in all of the aspects


Windows 7 x86, MSIE 9, Jetty


Thomas Scheiblauer
February 23, 2012, 6:52 PM

I have just attached a general non-ascii escape patch to CLJS-139 which obsoletes my previous one!

Thomas Scheiblauer
February 23, 2012, 2:33 PM

I have attached a patch to CLJS-139 which fixes this related issue.

Thomas Scheiblauer
February 22, 2012, 5:09 PM

applying to the current HEAD makes read-string work as expected. This is because David's patch for cljs-139 ( 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

!!! deleted referenced patch because it is now obsolete !!!

David Nolen
February 22, 2012, 2:53 PM

This ticket is different from CLJS-139, this is only about the reader.

Your pinned fields
Click on the next to a field label to start pinning.