Am 02.04.2013 um 02:12 schrieb Garth Hjelte <[email protected]>: > Does running a Japanese version of Windows perhaps influence this type of > code? (Please don't judge it on why it's written this way, I'm only concerned > if it works.) > > ThisStr = FileStream.Read(AmtBytes) // I assume the encoding on ThisStr is > Nil?
yes. As you pass no encoding to Read function. > Buff = New MemoryBlock(Len(ThisStr)) // Len should work, since ThisStr should > be Nil For nil encoding strings, len and lenb are the same. > Buff.SetStringMBS(XStr, 0) // the memoryblock should be byte-byte > just like what was taken off of the file stream Yes. Why XStr and not ThisStr? Buff = XStr would do the same as those two lines above! > InputStr = BuffIn.GetStringMBS(0, AmtBytes) // InputStr should be byte-byte > just like ThisStr, and encoding=Nil yes. Why buffIn here and not Buff like above? InputStr = BuffIn would do the same. > // now I decompress this, it is designed to be decompressable > OutStr = DecompressZLibMBS(InputStr, AmtBytes * 60) // param 2 set very high > to handle the decompression, assume this is enough yes. Please check if OutStr.len = 0 > numBytes = Len(OutStr) // Len should work, since OutStr should be Nil Should work. > BuffOut = New MemoryBlock(numBytes) > BuffOut.SetStringMBS(OutStr, 0) Should also work. > This always works, but I'm suspicious that in dealing with these strings, the > encoding winds up somewhere in the process not Nil, because I want to deal > with straight data and unfortuantely the functions you provide for unzipping > deal with strings. Well, you could compare memory blocks and see if something is not as expected. Greetings Christian -- Read our blog about news on our plugins: http://www.mbsplugins.de/ _______________________________________________ Mbsplugins_monkeybreadsoftware.info mailing list [email protected] https://ml01.ispgateway.de/mailman/listinfo/mbsplugins_monkeybreadsoftware.info
