You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by "Rony G. Flatscher (Apache)" <ro...@apache.org> on 2014/06/17 21:10:42 UTC
Question ad encoding of "unoinfo java" return string value
According to some older infos about the encoding returned by "unoinfo[.exe] java" the resulting
string starts with an indicator byte, where '0' indicates an ASCII encoding (and the paths are
delimited with '\0'), whereas '1' indicates UTF-16LE (and the paths are delimited with "\0\0").
On German Windows (AOO 4.1) I see the encoding '1' (UTF-16LE), but the characters are not 16-bit
(UTF-16LE) encoded, but plain ASCII, however the paths get delimited with "\0\0". OOo (e.g. 3.4.1)
would return encoding '1' (UTF-16LE) where each ASCII character is preceded by '\0'.
Clearly, an installation routine dealing with the returned string value of AOO gets confused, if it
was written with UTF-16LE in mind, working correctly on earlier OOo.
If the current encoding returned by AOO 4.1 on Windows is wrong, I would file a bug. If it is
correct, where is this particular encoding in AOO stated?
---rony
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Question ad encoding of "unoinfo java" return string value
Posted by "Rony G. Flatscher (Apache)" <ro...@apache.org>.
Added bugzilla issue <https://issues.apache.org/ooo/show_bug.cgi?id=125115>, attached zip file with
three text files containing the result of "unoinfo java" on OOo 3.4, AOO 4.0.1, and AOO 4.0.
---rony
On 17.06.2014 21:10, Rony G. Flatscher (Apache) wrote:
> According to some older infos about the encoding returned by "unoinfo[.exe] java" the resulting
> string starts with an indicator byte, where '0' indicates an ASCII encoding (and the paths are
> delimited with '\0'), whereas '1' indicates UTF-16LE (and the paths are delimited with "\0\0").
>
> On German Windows (AOO 4.1) I see the encoding '1' (UTF-16LE), but the characters are not 16-bit
> (UTF-16LE) encoded, but plain ASCII, however the paths get delimited with "\0\0". OOo (e.g. 3.4.1)
> would return encoding '1' (UTF-16LE) where each ASCII character is preceded by '\0'.
>
> Clearly, an installation routine dealing with the returned string value of AOO gets confused, if it
> was written with UTF-16LE in mind, working correctly on earlier OOo.
>
> If the current encoding returned by AOO 4.1 on Windows is wrong, I would file a bug. If it is
> correct, where is this particular encoding in AOO stated?
>
> ---rony
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Question ad encoding of "unoinfo java" return string value
Posted by Herbert Duerr <hd...@apache.org>.
On 17.06.2014 21:10, Rony G. Flatscher (Apache) wrote:
> According to some older infos about the encoding returned by "unoinfo[.exe] java" the resulting
> string starts with an indicator byte, where '0' indicates an ASCII encoding (and the paths are
> delimited with '\0'), whereas '1' indicates UTF-16LE (and the paths are delimited with "\0\0").
>
> On German Windows (AOO 4.1) I see the encoding '1' (UTF-16LE), but the characters are not 16-bit
> (UTF-16LE) encoded, but plain ASCII, however the paths get delimited with "\0\0". OOo (e.g. 3.4.1)
> would return encoding '1' (UTF-16LE) where each ASCII character is preceded by '\0'.
>
> Clearly, an installation routine dealing with the returned string value of AOO gets confused, if it
> was written with UTF-16LE in mind, working correctly on earlier OOo.
I had a quick look at the problem. This is indeed a behavior change.
There was a suspicious line in the responsible code. When I cleaned it
up (#i125115#) on trunk the output is fine again. Is this something for
our bugfix release? Please lobby for it if see it that way and when you
verified the fix.
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org