When logging out or sending (to a web service using RestKit) specifically the subThoroughfare property of CLPlacemark strange characters appear where I would expect a hyphen to be.
Logging:
NSLog(#"%#", placemark.subThoroughfare);
Results in:
12-
Where I would expect 12-15. The 15 is missing.
Also, when sending the subThoroughfare string to a JSON service I see the following in the request:
12â??15
The 15 is present, however the hyphen is replaced by strange characters.
Have not been able to find a solution via Google/SO, and any help would be appreciated.
Edit:
A fuller example of an address logged to the console is:
Placemark Address: 34–36 Friars Way, Eaton, Engla
Note the last 2 characters are also missing (should read 'England'), when the – replaces the hyphen (-). I am looking into encoding, however not getting far.
Turns out that the strange characters are due to the LLDB debugger not being able to show Unicode characters correctly...switching to GDB showed the characters correctly.
Related
I have the following segment of comment in my code file (the last line is intentionally missing the slash characters - that the error):
// * Cube Back Text from Méi guī
// 一颗 心 怕 摔倒 打破
//"yī kē xīn pà shuāi dǎo dǎ pò"
// "It's the heart afraid of breaking"
// 不敢 起舞 欢 歌
// "bù gǎn qǐwǔ huāngē"
// "that never learns to dance."
不敢起舞欢歌 (dance)
But the red error dot appears on the second character of the second line (second slash of the line "// * Cube Back Text from Méi guī".
Stranger, if I remove various quotes in the comment, the character that is hilited changes.
I assume this has something to do with a recursive structure somewhere in the parser that is continuing to parse the quotes inside the comment itself and ultimately figures out where to signal the error.
I suppose this is a bug ("semi-bug") that I should post to the GitHub list - to completely ignore anything past the second slash on a commented line, or some other change so that the error tag shows up on the line where the error actually is?
As it is, I futzed around about 10 minutes wondering if OpenSCAD just didn't like files longer than 575 lines.
I get the same problem when I try your example or modify it slightly but it worked perfectly when I replaced everything with random Latin characters so I think the bug has a lot to do with the Chinese ideographs you used.
In any case, I only copied the small sample you gave so it probably have nothing to do with the length of the file.
trying to hit a public endpoint that works in the browser(gives json response), But does not in curl.
curl https://yts.lt/api/v2/list_movies.json?query_term=tt11296058
It gives the following message
no matches found: https://yts.lt/api/v2/list_movies.json?query_term=tt11296058
Not sure what could be the issue here, any input would be appreciated.
It may be due to do with what shell you are using. Try wrapping the URL in single or double quotes as suggested here.
Here is the quote from the above link discussing ZSH.
You need to escape the question mark, otherwise zsh thinks it is a globbing or wildcard character and tries to find files that match it (that's why it says no matches found).
I'm using a manual verification point - it works well - but when it appears in the log its name -or title- appears empty, what should i do to make the manual VP's title appears in the log, thanks in advance
Abed.
The syntax is
vpManual("Your VP name here", expectedData, actualData).performTest();
The VP name should not contain spaces, dots or other "strange" characters, keep on letters, digits and underscore _
If you use a string variable for the name, check it is not null or empty.
Also note the name must be unique in the script. If you provide a little example of your problem I can try answering with more details.
Take a look at the RFT docs
I am encoding white spaces in a string using
[#"iPhone Content.doc" stringByAddingPercentEscapesUsingEncoding:NSUTF8StringEncoding]
in SKPSMTP message sending. But while receiving mail at attachments place I am getting the name iPhone%20Content.doc - instead of a space it shows %20. How can this be avoided / correctly encoded?
If you're doing stringByAddingPercentEscapesUsingEncoding then you're going to get percent signs in your result string... You can either use something different, or go back through and remove the percent signs later.
From the doc:
stringByAddingPercentEscapesUsingEncoding: Returns a representation of
the receiver using a given encoding to determine the percent escapes
necessary to convert the receiver into a legal URL string.
aka, "this method adds percent signs". If you want to reverse this process, use stringByReplacingPercentEscapesUsingEncoding
Just a side note, %20 is there because the hex representation of the space character is 20 and the % sign is an escape. You only need to do this for URLs, as they disallow the use of whitespace characters.
I got solution for my question. Actually am missed to set the "" to a string.
Of course the remote receiver can not accept the url with whitespace, so we must convert the URL address using the stringByAddingPercentEscapesUsingEncoding function.
This function replaces spaces in the URL expression with %20. It is especially useful when the URL contains non-ascii characters - you have use the function to percent-escape the URL so that the remote server can accept your request.
I am trying to create NMEA-compatible proprietary sentences, which may contain arbitrary strings.
The usual format for an NMEA sentence with checksum is:
$GPxxx,val1,val2,...,valn*ck<cr><lf>
where * marks the start of a 2-digit checksum.
My question is: Can any of the value fields contain a * character themselves?
It would seem possible for a parser to wait for the final <cr><lf>, then to look back at the previous 3 characters to find the checksum if present (rather than just waiting for the first * in the sentence). However I don't know if the standard allows it.
Are there other characters which may cause problems?
The two ASCII characters to be careful with are $, which has to be at the start, and * which precedes the checksum. Anyone else parsing your custom NMEA wouldn't expect to find either of those characters anywhere else. Some parsers, when they hit a $ assume that a new line has started. With serial port communication sometimes characters get lost in transit, and that's why there's a $ start of sentence marker.
If you're going to make your own NMEA commands it is customary to start them with P followed by a 3 character code indicating the manufacturer or company creating the proprietary message, so you could use $PSQU. Note that although it is recommended that NMEA commands are 5 characters long, there are proprietary messages out there by various hardware and software manufacturers that are anywhere from 4 characters to 7 characters long.
Obviously if you're writing your own parser you can do what you like.
This website is rather useful:
http://www.gpsinformation.org/dale/nmea.htm
If you're extending the protocol yourself (based on "proprietary") - then sure, you can put in anything you like. I would stick to ASCII, but go wild within those bounds. (Obviously, you need to come up with your own $GPxxx so as not to clash with existing messages. Perhaps a new header $SQUEL, ...)
By definition, a proprietary message will not be NMEA-compatible.
A standard parser listening to an NMEA stream should ignore anything that doesn't match what it thinks is 'good' data. That means a checksum error, or any massively corrupted message like it would think your new message is with some random *s thrown in.
If you are merely writing an existing message, then a * doesn't make sense, and should be ignored, but you run the risk of major issues if the checksum is correct, and the parser doesn't understand the payload.