<div dir="ltr">The snapshot/<a href="http://source.st">source.st</a> does not contain a mix of ByteString and WideString because a single String is written during the process (all code is written into a String new writeStream which will make the String wide at first wide Character), so it should work.<br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/5/23 Henrik Sperre Johansen <span dir="ltr"><<a href="mailto:henrik.s.johansen@veloxit.no" target="_blank">henrik.s.johansen@veloxit.no</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 23.05.2013 00:06, Nicolas Cellier wrote:<br>
</div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
That sounds good. We could even try to fallback to UT-32 if we encounter zeros (but his should be very rare...).<br>
<br>
For write, ZipArchive are un-aware of any encoding... They use latin1.<br>
In Squeak, I could place some squeakToUTF8 sends in MCMczWriter, and equivalent UTF8TextConverter in Pharo #serializeDefinitions:, maybe this is needed in some other serialize* (version, dependencies who knows...)<br>
</blockquote></div>
That won't work, if the file contained sources for both widestring and bytestring sourced methods.<br>
In which case the file would contain code stored BOTH as latin1 bytes, and (same endianness as platform saved from) UTF32.<br>
Which means you'd have to detect and handle jumps back and forth in encoding when reading...<br>
IMHO, just consider those files lost beyond hope.<br>
<br>
Cheers,<br>
Henry<br>
<br>
</blockquote></div><br></div>