-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
astral character support in chrome and IE #142
Comments
@uzulla It looks like the original sushi issue stems from this. |
I reproduced the issue. On Firefox and Nodejs, the utf8 encoding is correct because we use a |
@dduponchel while you are at it, can you rework the crc32 table so that the values are 32 bit integers? https://github.com/dduponchel/jszip/blob/async_methods_generated_files/dist/jszip.js#L226-L291 For example, the third element of the table is pako explicitly computes the table in a way that ensures the results are 32 bit integers. If you don't want to compute the table, the simplest solution may be to append |
@dduponchel http://sheetjsdev.github.io/js-xlsx-demo/ works in Chrome, FF, and IE. |
@SheetJSDev nice ! |
@dduponchel based on some performance tests, https://github.com/SheetJS/js-crc32 is at least 8x faster than pako's CRC32 |
8x faster ? I get the same speed when I test the two implementations with benchmark.js. |
@dduponchel @Stuk At the callsite, crc32 is sometimes called as string and sometimes called with a buffer/array (to verify, insert If you generate a text file and pass it into jszip, which is what happens in the overwhelming majority of cases with js-xlsx, jszip would have to convert the utf8 string to a buffer in order to proceed with pako. On the other hand, js-crc32 provides specialized functions for these cases (binary string / unicode characters / array+buffer). Here is the most frequently access callsite and string generation location. For some real-life perspective, the median file size is 550 characters (there are very small files like The numbers look a little bit different in 0.11.13, but the overall performance is absolutely horrendous. For example, take the case of 255 characters:
P.S.: I think the 0.11.13 regression is related to nodejs/node-v0.x-archive#7633. |
The character codes in the string are
In firefox, the string is properly written. The equivalent code in nodejs 0.10 is correct. However, in chrome, the content is not correct.
The text was updated successfully, but these errors were encountered: