define a long complex literal string - objective-c

I have a string that is quite long and complicated, with special characters inside. I want to define this string as a variable, but don't want to escape each of them (because there are so many). I remember that in XML they have a special syntax for that, is there something similar for Objective-C?
Edit: I know I can save the thing in a file and load it easily, but is it possible to do so without a new file? I'm having quite some of them...

No, you have to escape the characters (though you only have to escape ", \, and control characters... is the string mostly control characters and quotes?)
A better idea might be to put the string in a file. Load it using +[NSString stringWithContentsOfFile:encoding:error:].

Related

Multi-line text in a .env file

In vue, is there a way to have a value span multiple lines in an .env file. Ex:
Instead of:
someValue=[{"someValue":"Here is a really really long piece which should be split into multiple lines"}]
I want to do something like:
someValue=`[{"someValue":"Here is a really
really long piece which
should be split into multiple lines"}]`
Doing the latter gives me a JSON parsing error if I try to do JSON.parse(someValue) in my code
I don't know if this will work, but I can't format a comment appropriately enough to get the point across so see if this will work:
someValue=[{"someValue":"Here is a really\
really long piece which\
should be split into multiple lines"}]
Where "\" should escape the newline similar to how you can write long bash commands while escaping the newline. I'm not certain the .env interpreter will support it though.
EDIT
Looks like this won't work. This syntax was actually proposed, but I don't think it was incorporated. See motdotla/dotenv#333 (which is what Vue uses to parse .env).
Like #zero298 said, this isn't possible. Likely you could delimit the entry with a character that wouldn't show up normally in the text (^ is a good candidate), then parse it within the application using string.replace('^', '\n');

How to use escape character for a big string?

I have a big string, precisely - an XSLT code - that I would like to hardcode in my VB.net program. I tried with putting " before every quotation mark, but it still didn't work out, and it's pretty mocking to place it 100 times. Using Chr(34) is also not the best solution.
Is there some way, like to put # (or another character) before the string itself that will define and work for all the characters in the string that need to be escaped ?
If it is a large string. Why not save it to file and then read the file into memory before you want to use it. That way you don't have to do any escaping and it will be easy to modify if you decide to change it.

Code for converting long string to pass in URL

I am trying to take a string like "Hello my name is Nick" and transform it to "Hello+my+name+is+Nick" to be passed through a URL. This would be easily done by replacing all the spaces with a + char however I also need to replace all special characters (. , ! &) with their ASCII values. I have searched the net but cannot find anything. I wonder if anyone knows of existing code to do this as its a fairly common task?
I think you're looking for this: HttpUtility.UrlEncode Method (String)
Handles non-URL compliant characters and spaces.

Approximate search with openldap

I am trying to write a search that queries our directory server running openldap.
The users are going to be searching using the first or last name of the person they're interested in.
I found a problem with accented characters (like áéíóú), because first and last names are written in Spanish, so while the proper way is Pérez it can be written for the sake of the search as Perez, without the accent.
If I use '(cn=*Perez*)' I get only the non-accented results.
If I use '(cn=*Pérez*)' I get only accented results.
If I use '(cn=~Perez)' I get weird results (or at least nothing I can use, because while the results contain both Perez and Pérez ocurrences, I also get some results that apparently have nothing to do with the query...
In Spanish this happens quite a lot... be it lazyness, be it whatever you want to call it, the fact is that for this kind of thing people tend NOT to write the accents because it's assumend all these searches work with both options (I guess since Google allowes it, everybody assumes it's supposed to work that way).
Other than updating the database and removing all accents and trimming them on the query... can you think of another solution?
You have your ~ and = swapped above. It should be (cn~=Perez). I still don't know how well that will work. Soundex has always been strange. Since many attributes are multi-valued including cn you could store a second value on the attribute that has the extended characters converted to their base versions. You would at least have the original value to still go off of when you needed it. You could also get real fancy and prefix the converted value with something and use the valuesReturnFilter to filter it out from your results.
#Sample object
dn:cn=Pérez,ou=x,dc=y
cn:Pérez
cn:{stripped}Perez
sn:Pérez
#etc.
Then modify your query to use an or expression.
(|(cn=Pérez)(cn={stripped}Perez))
And you would include a valuesReturnFilter that looked like
(!(cn={stripped}*))
See RFC3876 http://www.networksorcery.com/enp/rfc/rfc3876.txt for details. The method for adding a request control varies by what platform/library you are using to access the directory.
Search filters ("queries") are specified by RFC2254.
Encoding:
RFC2254
actually requires filters (indirectly defined) to be an
OCTET STRING, i.e. ASCII 8-byte String:
AttributeValue is OCTET STRING,
MatchingRuleId
and AttributeDescription
are LDAPString, LDAPString is an OCTET STRING.
The standard on escaping: Use "<ASCII HEX NUMBER>" to replace special characters
(https://www.rfc-editor.org/rfc/rfc4515#page-4, examples https://www.rfc-editor.org/rfc/rfc4515#page-5).
Quote:
The <valueencoding> rule ensures that the entire filter string is a
valid UTF-8 string and provides that the octets that represent the
ASCII characters "*" (ASCII 0x2a), "(" (ASCII 0x28), ")" (ASCII
0x29), "\" (ASCII 0x5c), and NUL (ASCII 0x00) are
represented as a backslash "\" (ASCII 0x5c) followed by the two hexadecimal digits
representing the value of the encoded octet.
Additionally, you should probably replace all characters that semantically modify the filter (RFC 4515's grammar gives a list), and do a Regex replace of non-ASCII characters with wildcards (*) to be sure. This will also help you with characters like "é".

Deleting comments from a string using NSScanner?

I've a string that may or may not include C++ comments on it (multi-lin and single line) and I need to strip those comments out before being able to use that string. My current idea is to use an NSScanner to do that - find the position of opening and closing multi-line comments and delete that portion of the string and find the position of opening one line comments and EOL characters and also delete that portion of the string.
Would you do it differently? What would be your approach? If it matters, the string can be several megabytes in size so performance is an issue.
From this thread, I thought the best suggestion was to run the string through the C++ preprocessor.
Don't forget to keep track of quote marks, too. Test cases:
"/*Ceci n'est pas une commentaire*/"
'/**/' (Mac OS/Mac OS X OSType literal)
'//!\n'
"This string does not contain a // comment"
In all of these cases, you should not detect a comment.
The converse is also true:
//Ceci n'est pas une "string"
/*This comment does not contain an OS'Type' literal*/
My solution:
Go through the string using NSScanner and mark the position of each multi-line and single comment and all strings (anything between single and double quotes). Store the positions in an array of NSValues that represent the ranges of each item.
Then iterate through the array of comments, making sure that each comment is not inside a string. The way to check for this is to make sure that the location of each comment is not bigger than the location of each string and the location of the comment does not fall into location + length of each string.
And voila. Anything that doesn't fall into can be safely deleted as it is a valid comment.