WebDialog encoding bug found!

driven

Cheers Steve,

I fixed it and re-ran on three SU versions...

now I have Three different results from the identical script...

go figure...

john

slbaumgartner

I managed to fire up SU8 and I also confirm your results there (given the correction to which value displays where). What is happening is that the action callback converts its values to ASCII-8BIT when sending them from javascript to Ruby. In SU8 (Ruby 1.8) this works because that's what Ruby 1.8 expects. In SU 2014, it causes an issue because Ruby 2.0 expects UTF-8 and receives ASCII-8BIT. You can print out the encodings for the values in 2.0 to confirm that is what is happening.

Steve

slbaumgartner

to further the analysis, get_element_value does not do any conversion. Since you loaded the javascript side on the mac with UTF-8, that makes 2014 happy but messes up SU8!

Juantxo

In Windows 7 p(params) returns non utf-8
"lid1,\xC3\xA9lan"
and console shows:
return using add_action_callback lid1 = élan
return using get_element_value => élan

driven

which one is affected appears to have changed between v8 and v2013, and it's a different charset

and now causes the encoding error message ONLY if you try and combine strings...

so v2014 can't print the last line the same as v2013

@Jauntxo does it through a coding error if you coment out

    #if (Sketchup.version.to_i > 13) && ( not param_val == elm_val)
   # @dlg2.execute_script("translation3.textContent='Error; #<Encoding;;CompatibilityError; incompatible character encodings; ASCII-8BIT and UTF-8>'")
   # else
    @dlg2.execute_script("translation3.textContent='#{param_val}' + ' == ' + '#{elm_val}'")
   # end

driven

@juantxo said:

In Windows 7 p(params) returns non utf-8
"lid1,\xC3\xA9lan"..

ON mac p(params)
"lid1,\xE2\x88\x9A\xC2\xA9lan"

why?

slbaumgartner

@driven said:

@juantxo said:

In Windows 7 p(params) returns non utf-8
"lid1,\xC3\xA9lan"..

ON mac p(params)
"lid1,\xE2\x88\x9A\xC2\xA9lan"

why?

We are seeing the raw 8-bit byte sequences of the string representations and the chaos that results when Ruby and SU try to convert character encodings without knowing for sure what they had.

Aerilius

I didn't know the ASCII-8BIT encoding issue before, but it's only the cherry on the cake.

Along with the issues we have found in the other webdialog discussions (url encoding, url length limit, dropped backslashes), I recommend not to transfer user input or arbitrary text through action callbacks, only simple method names/indentifiers with a limited character range. Then one can use get_element_value to fetch user input of any arbitrary character range.

driven

@aerilius said:

...Then one can use get_element_value to fetch user input of any arbitrary character range.

except, get_element_value fails pre v2013 and get_element_value works.

I got a few old scripts I was trying to update, and was unable to figure out the issue...

I think this shows it was broken to begin and got broken 'differently' with a fix...

I'm more inclined, to look at using 'unicodeEscape' in the js... before retrieving by either method...

john

slbaumgartner

@driven said:

@aerilius said:

...Then one can use get_element_value to fetch user input of any arbitrary character range.

except, get_element_value fails pre v2013 and get_element_value works.

I got a few old scripts I was trying to update, and was unable to figure out the issue...

I think this shows it was broken to begin and got broken 'differently' with a fix...

I'm more inclined, to look at using 'unicodeEscape' in the js... before retrieving by either method...

john

It's possible to get deeply confused trying to sort this out
Here's what I have observed:

The UTF-8 byte sequence for élan is \xC3\xA9lan (that is, UTF-8 encodes é as the two-byte sequence \xC3\xA9).

On Mac, get_element_value returns this byte sequence exactly in both SU8 and 2014. However, because Ruby 8 thinks it is a 5-character string in ASCII-8BIT, it treats \xC3 as Ã and \xA9 as , the extended ASCII interpretations of these bytes. Ruby 2.0 happily assumes it is UTF-8 and gets it correct.

The action callback parameters are handled differently and inconsistently between Windows and Mac.

On the Mac, in SU8 the action callback also returns the original UTF-8 5-byte sequence, but somehow when Ruby prints it as a string, it gets it right Further, it believes this string and the one from get_element_value (that prints as Ãlan) are equal. This makes no sense to me...

But in 2014, the original 5-byte UTF-8 string is somehow transmuted into the 8-byte string \xE2\x88\x9A\xC2\xA9lan. Note that \xE2\x88\x9A is the UTF-8 for the square-root sign √ and \xC2\xA9 is UTF-8 for . So it appears the translation of the copyright is an attempt to handle misreading of the UTF-8 as ASCII-8BIT, but I don't know where that square root sign byte-sequence came from since as I mentioned above, \xC3 is Ã in ASCII-8BIT, which is \xC3\x83 in UTF-8. It's as if the callback processing code has an incorrect implementation of the transcoding.

And then, as juantx0 reports, SU8 on Windows 7 returns the 5 UTF-8 bytes unconverted yet again somehow manages to make sense of it in both cases .

driven

@slbaumgartner said:

... Further, it believes this string and the one from get_element_value (that prints as Ãlan) are equal. This makes no sense to me...

I create this confusion... I don't check for equality it's a 'puts', it should be

    @dlg2.execute_script("translation3.textContent='#{param_val}' + ' == ' + '#{elm_val}' + ' is ' + '#{param_val == elm_val}'")

which returns
√©lan == élan is false

sorry I'll get my coat...

john

Juantxo

Sorry, I didn't update my profile.
In Windows SketchUp 2013 p(params) returns
"lid1,élan"
so works fine. (I think in SU8 also)
Problem is in Windows SU2014 that returns non utf string.

driven

@juantxo said:

Sorry, I didn't update my profile.

I suspected that...

which locale do you use Sketchup.get_locale en-US?, it may have a bearing?

john

Juantxo

Yes, en-Us.

slbaumgartner

@driven said:

@slbaumgartner said:

... Further, it believes this string and the one from get_element_value (that prints as Ãlan) are equal. This makes no sense to me...

I create this confusion... I don't check for equality it's a 'puts', it should be

    @dlg2.execute_script("translation3.textContent='#{param_val}' + ' == ' + '#{elm_val}' + ' is ' + '#{param_val == elm_val}'")
>

which returns
√©lan == élan is false

sorry I'll get my coat...

john

Nah, I should know enough to check your code . With a real test, equality fails in all cases (as it should!).

driven

@slbaumgartner said:

Nah, I should know enough to check your code :oops: . With a real test, equality fails in all cases (as it should!).

it's the tangents that count...

now you can write a proper test...

john

Dan Rathbun

The text that displays in your test, says UFT-8 in many places. It is UTF-8.
(The word format is at the end, of Unicode Transformation Format.)

(nag, nag)

Dan Rathbun

@slbaumgartner said:

But in 2014, the original 5-byte UTF-8 string is somehow transmuted into the 8-byte string \xE2\x88\x9A\xC2\xA9lan. ... It's as if the callback processing code has an incorrect implementation of the transcoding.

YES, agree.

To me it looks like it IS UTF-8, but Ruby thinks it is some other encoding, and doubly transcodes* it into UTF-8 AGAIN.

P.S. - isn't transmute a math term ?

tt_su

@driven said:

except, get_element_value fails pre v2013 and get_element_value works.

? It does? Are you sure?

tt_su

@dan rathbun said:

To me it looks like it IS UTF-8, but Ruby thinks it is some other encoding, and doubly transcodes* it into UTF-8 AGAIN.

That's a similar problem we have with FILE $LOAD_PATH, $LOADED_FEATURES and ENV. UTF-8 byte sequences isn't labeled with the correct encoding.