base64EncodedStringWithOptions

asobjc

(Luc Naets) #1

Hi everybody,

to use a restAPI I need to create a base64 encoded string from a login/password phrase.
I have found the objC command on the developer website but I don’t get it to work for me from within a applescript. I got this far…

use AppleScript version "2.4"
use framework "Foundation"
property NSData : a reference to current application's NSData
property NSDataBase64EncodingOptions : a reference to current application's NSDataBase64EncodingOptions
set mText to NSData's base64EncodedStringWithOptions:"login:passwd" options:(NSDataBase64EncodingOptions's NSDataBase64Encoding64CharacterLineLength)

running this in SD gives me the error: +[NSData base64EncodedStringWithOptions:options:]: unrecognized selector sent to class 0x7fff75d8aad8

Help wanted… I’m still strungling with the translations from the ObjC dev pages towards ApplescriptObjC despite Shane’s efforts :-):wink:

Luc


(Shane Stanley) #2

Here are handlers for encoding and decoding:

use AppleScript version "2.4" -- Yosemite (10.10) or later
use framework "Foundation"
use scripting additions

set theValue to "6f0491fb94314482b9fbd874b3b83799:555de1baa87d4154b4d1a6a53dc788fb"
set encodedValue to my encodeBase64:theValue
set decodedValue to my decodeBase64:encodedValue

on encodeBase64:theString
	set theString to current application's NSString's stringWithString:theString
	set theData to theString's dataUsingEncoding:(current application's NSUTF8StringEncoding)
	return (theData's base64EncodedStringWithOptions:0) as text
end encodeBase64:

on decodeBase64:theString
	set theData to current application's NSData's alloc()'s initWithBase64EncodedString:theString options:(current application's NSDataBase64DecodingIgnoreUnknownCharacters)
	return (current application's NSString's alloc()'s initWithData:theData encoding:(current application's NSUTF8StringEncoding)) as text
end decodeBase64:

You can change the encoding options if you want line-breaking.


(Luc Naets) #3

Thanks Shane!
That’s what I needed. It always looks so simple but I can’t still figure it out from the developer pages.


(CK) #4

The page I link to below was quite helpful to me in the beginning. Now I find the developer pages really quite an excellent resource, but it took some getting used to. I think Objective-C has quite a steep learning curve (not that I’m an expert at it by any means), and it’s syntax, whilst logical, is very heavily laden.

One thing I started doing more of with plain AppleScript was to use the interleaved parameter-syntax for handlers, which very closely mirrors the ObjC style.


Objective-C to AppleScript Quick Translation Guide


(Luc Naets) #5

CK Thx for the tip and the link…


(Shane Stanley) #6

It’s worth noting that it’s aimed at using AppleScriptObjc in Xcode, and the stuff about script objects as classes is mostly irrelevant outside that context.

It also has a couple of things I personally find questionable, or at least lacking further explanation. In particular, the use of properties without parentheses, and using me or my instead of current application. Unless you’re aware of all the subtleties, these can both cause more than their share of debugging grief.

And the last I was told by someone on the AppleScript team was that the preferred way of referring to classes outside Xcode is using an identifier — current application's NSString — rather than the class-by-string approach — class "NSString".


(CK) #7

Thanks for this @ShaneStanley. I must admit, some of these oddities had niggled with me at the back of my mind, so it’s good to have this highlighted and at least partially explained now.

For some unqualifiable reason, using my in place of current application in these contexts just never sat very well with me; likewise with class "NSWhatever" vs current application's NSWhatever. I’m glad you’re able to ratify this, although it’s probably from following your teachings and viewing your code that has subconsciously influenced my own syntactical and coding style preferences.

Although, I do find it helpful and useful to think of script objects as an analogue to classes. I find it helps create more structured code for complex tasks and helps the mind approach things in an organised way for problem solving. Though I had this debate with someone else recently who disagrees, and finds my fondness for employing script objects to be unnecessarily over complicating things.


(Shane Stanley) #8

Personally, I have a love-hate relationship with them. It generally takes me much longer to understand code that uses them, and I confess to getting a bit annoyed at that when I don’t see any obvious benefit. But that’s probably just my impatience.

They can, however, present problems when they contain Cocoa objects. it makes debugging in Script Debugger difficult, and sometimes impossible, and I’ve recently discovered they can cause problems should code using them be called from JXA.