Encrypt 1MB text file

[Robert_Livingston]

Well, as you all have speculated, my (secondary) problem was with the EOL character.

I have a text file on the Mac which has lines separated by carriage returns. I originally brought this information into Xojo with

[quote] Const NAME_DATA_FILE = “TA_Data.txt”
Dim tisTA_Data As Xojo.IO.TextInputStream

Dim cxj_fiTA_Data As New FolderItem(GetFolderItem(NAME_DATA_FILE)) // will look in the folder with the app
Dim fiTA_Data As New Xojo.IO.FolderItem(cxj_fiTA_Data.NativePath.ToText) // Convert to Xojo.IO folderItem (cxj → classic Xojo)

If fiTA_Data <> Nil Then
If fiTA_Data.Exists Then

    tisTA_Data = Xojo.IO.TextInputStream.Open(fiTA_Data, Xojo.Core.TextEncoding.UTF8)
    Self.xInfo = tisTA_Data.ReadAll
    tisTA_Data.Close

End If

End If[/quote]

So the contents of the text file on disk, ended up in the text property of the window: Self.xInfo

CR in my app is a constant equal to Chr(13) or &u0d – i.e. the return character. The following line of code “worked”

axOneLine = Self.xInfo.Split(CR)

*    *    *    *    *    *    *    *    *    *    *    *

Then I tried an alternative approach. In the IDE, I simply pasted the text file into a Constant (Self.TA_INFO)
In the code, the loading of the information from the disk into Self.xInfo seen above was replaced by simply assigning the Self.xInfo property.

Self.xInfo=Self.TA_INFO

At this point

axOneLine = Self.xInfo.Split(CR)

would no longer work properly. The reason was that apparently pasting the text into the Constant resulted in all the carriage returns – &u0d – being replaced by line feeds – &u0a –

axOneLine = Self.xInfo.Split(&u0a)

works just fine.

Probably for clarity, if nothing else, I will adapt the equivalent of the Palardy suggestion

axOneLine = ReplaceLineEndings(Self.xInfo, EndOfLine).Split(EndOfLine)

*    *    *    *    *    *    *    *    *    *    *    *

But for me, it was somewhat curious that pasting the original text file full of carriage returns into the Constant resulted in those carriage returns being converted into linefeeds.

Once you are aware that this happens, it is easy to deal with.

[Michel_Bujardet]

You could paste the file after encoding it Base64.

[Robert_Livingston]

Couple of things

1. axOneLine = Self.TA_INFO.Split(EndOfLine) (Palardy)

This was suggested but in fact will not work: You cannot pass EndOfLine as a parameter to Split because it requires TEXT and EndOfLine is returning a STRING. You have to take the extra step of somehow converting EndOfLine to text. (By the way EndOfLine.ToText is not an acceptable way of doing this)

2. It was suggested that a low level of security could be attained by encoding the document as Base64.Encoded. (Tekinay) Perhaps I am wrong, but I think that Base64.Encoded assumes that the text you are encoding is in the ASCII range and is not suitable for things like Japanese characters. The obfuscate Algorithm presented in the recent edition of xDev seems also to use Base64.Encoded (Zeedar)

[Tim_Hare]

You have that backwards. Base64 encodes raw byte values and renders them in the ASCII range. Base64 works on bytes, not characters, so it isn’t affected by encoding or language.

[Kem_Tekinay]

You can use &uA, the unicode representation of a linefeed, the default EOL of a constant. “&u” tells Xojo that a unicode code point is following, and “A” is hex value for “10”, and code point 10 is a linefeed.

If you want to make sure, either use ReplaceLineEndings to convert the constant to a String with known EOL (EndOfLine will work there) first, or see my post here.

(&uD is a code point 13, the Return character.)

[Robert_Livingston]

You can use &uA, the unicode representation of a linefeed, the default EOL of a constant.

This seems to be the case. I did not find where documented but was true for my constant.

You have that backwards. Base64 encodes raw byte values and renders them in the ASCII range. Base64 works on bytes, not characters, so it isn’t affected by encoding or language.

Thanks for heads up. I’ll have to look into this more.

[Robert_Livingston]

@264118:@Tim Hare

You have that backwards. Base64 encodes raw byte values and renders them in the ASCII range. Base64 works on bytes, not characters, so it isn’t affected by encoding or language.

From the Xojo Documentation:

The following example decodes a string back into ASCII.

Dim s as string s = EncodeBase64("How now Brown cow",0) s = DecodeBase64(s) MsgBox s

This example works just fine.

BUT
I do not have luck taking Japanese characters and encoding them to Base64 and then decoding them back into Japanese characters.

This sentence [quote]The following example decodes a string back into ASCII.[/quote] seems to imply that when you decode you are going to ASCII not to UTF8 which could deal with something like Japanese.

Try another example modeled after what is in the documentation.

Dim s As String s = EncodeBase64("Vertical ??", 0) s = DecodeBase64(s) MsgBox (s)

[quote]Vertical ???[/quote] is what shows up in the Message Box.

The “obvious way” of encoding to BASE64 and the decoding back to Text, as in the example above, does not work for me when I am dealing with Japanese characters.

[Tim_Hare]

The string you get back from DecodeBase64 doesn’t know what kind of characters are in it. Use DefineEncoding to tell it how to interpret the data. Assuming the original string was UTF8

Dim s As String
s = EncodeBase64("Vertical    ??", 0)
s = DecodeBase64(s)
s = DefineEncoding(s, Encodings.UTF8)
MsgBox (s)

[Robert_Livingston]

@264301:@Tim Hare

Use DefineEncoding to tell it how to interpret the data.

I am glad I posted this in Getting Started. Makes my stumbling around more excusable.

Meanwhile, you never sleep. Thanks. It works.