Percentage sign ('%') is getting interpreted as ('0') when inputting URL into address bar from Blue Prism for a SharePoint website
Issue is to do with the % symbol being interpreted as a command. You need to use curly brackets for it to be used successfully.
Something like this should do it
Replace(Replace("https://health.sharepoint.com/sites/in/Standard/Forms/My%20Claims.aspx","%","{%}"),")","{%}")
While Eoin2111's answer is correct, generally speaking when editing URL, you should make sure to encode it (remove spaces, special characters etc.).
One of the ways to encode URL is HttpUtility.UrlEncode(). The usage of this and some other useful methods is very well described in here.
Related
I have a .html file that is working perfectly fine but for some reason Sublime 3 decides that it has invalid code, check the image below:
Any idea why that's happening and how to fix it without having to modify the code?
The HTML5 spec states (my emphasis):
Comments must start with the four character sequence U+003C LESS-THAN SIGN, U+0021 EXCLAMATION MARK, U+002D HYPHEN-MINUS, U+002D HYPHEN-MINUS (<!--). Following this sequence, the comment may have text, with the additional restriction that the text must not start with a single > (U+003E) character, nor start with a U+002D HYPHEN-MINUS character (-) followed by a > (U+003E) character,
nor contain two consecutive U+002D HYPHEN-MINUS characters (--),
nor end with a U+002D HYPHEN-MINUS character (-). Finally, the comment must be ended by the three character sequence U+002D HYPHEN-MINUS, U+002D HYPHEN-MINUS, U+003E GREATER-THAN SIGN (-->).
So that's why it's complaining. As to how to fix it without changing the code, that's trickier.
Your contention that it works is no different really to C developers wondering why they need to worry about undefined behaviour because the code they wrote works fine. The fact that it works fine in one particular implementation is not relevant to portable code.
My advice is to actually change the code. It's not valid, after all, and any browser (current or future) would be well within its rights to simply reject it.
As an aside after some historical digging, it appears this is not allowed because SGML, on which HTML was based, had slightly different rules regarding comment.
On sensing the <!-- token, the parser was switched to a comment mode where > characters were actually allowed within the comment. If the -- sequence was encountered, it changed to a different mode where the > would end the comment.
In fact, it appears to have been a toggle switch between those two modes, so something like <!-- >>>>> -- xyzzy -- >>>>> --> was possible, but putting a > where the xyzzy would end the comment.
XML, for one, didn't adopt this behaviour and HTML has now modified it to follow the "don't use -- within comments at all" rule, the reason being that hardly anyone knew that the comments behaved in the SGML way, causing some pain :-)
I have imported images to my own server. One of the many filenames has %20 in them, e.g. 50128%202789%20001V%20500.jpg. However the browser sees it as 50128 2789 001V 500.jpg, so it won't display the image.
What solution can I use, to display the image properly?
"%20" is a percent-encoding for a space, and has special meaning in a URL. Basically, you can't use spaces in a URI or URL, and have to replace them with a code to comply with the rules. Things that read URLs (the server for example) translate them back.
Unfortunately, that means if you have a filename containing this sequence, it will be mistaken for a percent-encoded space, as you're seeing.
The solution is to also percent-encode the '%'. The percent-encoding for a '%' character is "%25".
In your example, the name "50128%202789%20001V%20500.jpg" has to be encoded to "50128%25202789%2520001V%2520500.jpg" so that those '%' characters are not mistaken for spaces.
There are of course other things that get encoded. The rules are defined in the URI specification.
I was (re)reading Joel's great article on Unicode and came across this paragraph, which I didn't quite understand:
For example, you could encode the Unicode string for Hello (U+0048
U+0065 U+006C U+006C U+006F) in ASCII, or the old OEM Greek Encoding,
or the Hebrew ANSI Encoding, or any of several hundred encodings that
have been invented so far, with one catch: some of the letters might
not show up! If there's no equivalent for the Unicode code point
you're trying to represent in the encoding you're trying to represent
it in, you usually get a little question mark: ? or, if you're really
good, a box. Which did you get? -> �
Why is there a question mark, and what does he mean by "or, if you're really good, a box"? And what character is he trying to display?
There is a question mark because the encoding process recognizes that the encoding can't support the character, and substitutes a question mark instead. By "if you're really good," he means, "if you have a newer browser and proper font support," you'll get a fancier substitution character, a box.
In Joel's case, he isn't trying to display a real character, he literally included the Unicode replacement character, U+FFFD REPLACEMENT CHARACTER.
It’s a rather confusing paragraph, and I don’t really know what the author is trying to say. Anyway, different browsers (and other programs) have different ways of handling problems with characters. A question mark “?” may appear in place of a character for which there is no glyph in the font(s) being used, so that it effectively says “I cannot display the character.” Browsers may alternatively use a small rectangle, or some other indicator, for the same purpose.
But the “�” symbol is REPLACEMENT CHARACTER that is normally used to indicate data error, e.g. when character data has been converted from some encoding to Unicode and it has contained some character that cannot be represented in Unicode. Browsers often use “�” in display for a related purpose: to indicate that character data is malformed, containing bytes that do not constitute a character, in the character encoding being applied. This often happens when data in some encoding is being handled as if it were in some other encoding.
So “�” does not really mean “unknown character”, still less “undisplayable character”. Rather, it means “not a character”.
A question mark appears when a byte sequence in the raw data does not match the data's character set so it cannot be decoded properly. That happens if the data is malformed, if the data's charset is explicitally stated incorrectly in the HTTP headers or the HTML itself, the charset is guessed incorrectly by the browser when other information is missing, or the user's browser settings override the data's charset with an incompatible charset.
A box appears when a decoded character does not exist in the font that is being used to display the data.
Just what it says - some browsers show "a weird character" or a question mark for characters outside of the current known character set. It's their "hey, I don't know what this is" character. Get an old version of Netscape, paste some text form Microsoft Word which is using smart quotes, and you'll get question marks.
http://blog.salientdigital.com/2009/06/06/special-characters-showing-up-as-a-question-mark-inside-of-a-black-diamond/ has a decent explanation.
Was hoping someone could help me with an issue I am having with escape characters in Cucumber/Watir.
I have automated tests setup. When I perform a search, 1 of the assertions I use to verify that the search has returned the correct result is to check the page for text. So my code looks like this:
Then /^I should see the following text: "([^"]*)"$/ do |str|
assert #browser.text.include?(str)
end
Here I pass in the text to search for in the string variable. e.g nike, reebok etc
So in my feature file the step is like this:
Then I should see the following text "search results for nike"
This works fine apart from 1 issue. 1 of the sites I am testing has decided to put the search term in double quotes i.e - search results for "nike"
As a result this screws up my test as I need to include the quotes as part of the search term. Therefore I need to put the word nike in escape quotes or else cucumber will recognise the first quotation around the word nike as a closing quotation. (as there is already a double quotes before it)
I have tried various different escape characters but nothing seems to work. For example I have tried the following:
\" – double quote
\\ – single backslash
Has anyone experienced similar problems and if so, how did you overcome the problem?
Thanks!
You need to change the regex rather than the string.
Problem: Your current regex says "([^"]*)", which says to match all characters between the quotations that are not quotations. This is not good given that you want to include quotations.
Solution: Change the step to the following:
Then /^I should see the following text: "(.*?)"$/ do |str|
assert #browser.text.include?(str)
end
The .* says to match all characters between the quotations. The ? makes the search lazy (instead of greedy). The ? is optional in this case, but would be important if there were additional parameters being captured. A good explanation of the greedy vs lazy can be seen at http://www.regular-expressions.info/repeat.html.
Using vim 7.2.330 on a Ubuntu host from an XP host, I'm stuck at how to type/paste the following line in a text file:
include_once(‘/full/path/to/app’);
The document says it's important to use ASCII 145 and 146, but vim turns them into "<92><93>", and Nano turns them into �.
Note that I'm using a European keyboard layout, not the US layout.
Does someone know how to solve this?
Thank you.
Er, you should not be using the 2 types of special quotes for string quoting in PHP.
You should be typing
include_once('/full/path/to/app');
( That's ASCII character 39 )
This is not what it says at the end of
this document:
www.wpbbpthemes.org/integration/
"beware some pasting of this code make
the ‘ character change, make sure it’s
the button left of the enter key on
your [US] keyboard"
No, you are misinterpreting it. Lots of software in windows, and varying keyboards, erroneously do "smart quotes". Word and Internet Explorer are such examples. As a result, copy-pasting from these applications results in the wrong type of character in your source code, often conflicting with the content-encoding the document is served as, which renders on the displaying browser as a silly Ä or similar character.
Do not use characters 145 and 146 in your PHP source, it is not necessary, and it won't work.
Also, Important to note, the authors of that page have USED THE WRONG QUOTES IN THEIR EXAMPLES and as such, WILL NOT WORK AS STATED.
Their statement with regard to "beware some pasting will make the character change" is bogusly incorrect, they have the incorrect character in their source, and as such, copy-pasting it at any time will not work.