Issue 65372 - Protected macro: Unicode string would be destroyed when a macro be protected by password.
Summary: Protected macro: Unicode string would be destroyed when a macro be protected ...
Alias: None
Product: App Dev
Classification: Unclassified
Component: api (show other issues)
Version: 3.3.0 or older (OOo)
Hardware: All All
: P3 Trivial
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
: 120212 (view as issue list)
Depends on:
Reported: 2006-05-15 04:51 UTC by winwind
Modified: 2015-02-10 16:32 UTC (History)
5 users (show)

See Also:
Issue Type: PATCH
Latest Confirmation in: ---
Developer Difficulty: ---

document with protected macro (10.80 KB, application/vnd.oasis.opendocument.text)
2006-05-15 10:28 UTC, stephan.wunderlich
no flags Details
a testcase for a protected macro (16.68 KB, application/vnd.oasis.opendocument.spreadsheet)
2009-10-28 17:53 UTC, mwu4
no flags Details
Patch to change encoding to UTF-8 in code.bin file (3.76 KB, patch)
2012-01-19 09:30 UTC, hanya
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description winwind 2006-05-15 04:51:13 UTC
Try this code:

Sub test
  s = "一"   ' A Chinese UTF8 String
  Msgbox "一"
  Msgbox Asc(s)
End Sub

Normally, It will print "一", and then print this Chinese UTF8's Unicode: 19968

But when this Macro goes to be protected,
(yes gived it a password before protected)
and close all Openoffice's program and re-run the macro(function test)
It print "?", and then print this Chinese UTF8's Unicode: 63 ???

What's going wrong?

And I found another point,
that is When I put the string(Chinese UTF8 String) into awt's control's Model
Text like:
Label, EditLabel, Listbox...
These Model's Text Will be same when the macro is going to be protected!

Sorry to my English if somebody still don't understand what I said.
Comment 1 stephan.wunderlich 2006-05-15 10:28:58 UTC
Created attachment 36476 [details]
document with protected macro
Comment 2 stephan.wunderlich 2006-05-15 10:36:21 UTC
sw->ab: I've attached a document that contains the mentioned macro once in the
standard library where the method is called "test" and once in the library
"protected", where the method is called "test_protected". The password for the
latter is "secret" :-)

When you run the method "test" you will see a message-box showing the character
given in the macro followed by a message box showing a 19968.
If you now run the method "test_protected" you will see a message-box showing a
"?" and then one displaying a 63.
Comment 3 stephan.wunderlich 2006-05-15 10:37:11 UTC
Changing owner
Comment 4 ab 2006-05-17 11:27:57 UTC
Comment 5 ab 2006-08-21 09:09:46 UTC
-> OOo 2.1, could probably be handled together with i64377 as binary
format has to change there anyway.
Comment 6 ab 2006-10-12 13:38:35 UTC
Too late for i64377, probably requires binary format change -> 2.2
Comment 7 ab 2007-01-02 14:14:28 UTC
2.x due to limited resources.
Has to be evaluated and targeted together with all other 2.x tasks.
Comment 8 Martin Hollmichel 2007-11-09 17:27:38 UTC
set target from 2.x to 3.x according to
Comment 9 mwu4 2009-10-28 17:50:59 UTC
    Besides the Chinese message will get garbled if the macro is protected with
a password, the protected macro also fails to work with the Chinese sheetname (
please refer to the attachment ). If we unlock the protected macro with the
password, everything will become normal again. However, a protected macro should
run normally even the macro is locked with the password. Please help to check
what the problem is and thank you for your assistance in advance.
Comment 10 mwu4 2009-10-28 17:53:32 UTC
Created attachment 65712 [details]
a testcase for a protected macro
Comment 11 mwu4 2009-10-28 17:58:26 UTC
    One more thing to add on, the testcase has been tested with OOo 3.1 English
version and Traditional Chinese version, Windows XP and Fedora 10. Thank you.
Comment 12 hanya 2012-01-10 18:27:42 UTC
The problem is in basic/source/classes/image.cxx.
In SbiImage::Save method, GetSOStoreTextEncoding returns MS 1252 encoding which does not allow multi byte characters and some characters illegally encoded in contractor of ByteString. To change this encoding to static one like UTF-8 would be solve this problem.
Comment 13 hanya 2012-01-19 09:30:45 UTC
Created attachment 77149 [details]
Patch to change encoding to UTF-8 in code.bin file

This patch change to use fixed encoding UTF-8 as save encoding and loading is done by UTF-8 encoding when the encoding flag is UTF-8 in code.bin file. Therefore code.bin file created by current build should be opened correctly.

But the multi-byte strings stored in code.bin which created by the current build are shown like "????". They are failed to encode to output encoding and converted to strings with "?" character. The code.bin file created by current build keeps broken strings in executable files by users without password input, which needs re-save with patched build to store correct strings into code.bin file.

Non-ASCII characters would be incompatible with this patch. If there is a way to check the encoding to the specific encoding is finished without any error, it could be keep compatibility on the code.bin encoded with non-ascii encoding.
Comment 14 mroe 2012-07-07 16:34:41 UTC
*** Issue 120212 has been marked as a duplicate of this issue. ***
Comment 15 Rob Weir 2013-03-11 14:58:22 UTC
I'm adding this comment to all open issues with Issue Type == PATCH.  We have 220 such issues, many of them quite old.  I apologize for that.  

We need your help in prioritizing which patches should be integrated into our next release, Apache OpenOffice 4.0.

If you have submitted a patch and think it is applicable for AOO 4.0, please respond with a comment to let us know.

On the other hand, if the patch is no longer relevant, please let us know that as well.

If you have any general questions or want to discuss this further, please send a note to our dev mailing list:


Comment 16 hanya 2015-02-10 16:32:04 UTC
Comment on attachment 77149 [details]
Patch to change encoding to UTF-8 in code.bin file

This patch is not enough to solve this problem.