Is there a way to say (programmatically, I mean their API) the Google URL shortener not to produce short URL with characters like:
0 O
1 l
Because people often make mistake when reading those characters from displays and typing them elsewhere.
You cannot request the API to use a custom charset, so no.
Not a proper solution, but you could check the url for unwanted characters and request another short URL for the same long URL until you get one you like. Google URL shortner issues a unique short URL for an already shortned URL if you provide an OAuth token with the request. However I am not sure if a user is limited to one unique short URL per a specific long URL in which case this won't work either.
Since you're doing it programmatically, you could swap out those chars for their ascii value, '%6F' for the letter o, for instance. In this case, just warn the users that in doubt, it's a numeral.
Alternatively, use a font that distinguishes ambiguous chars, or better yet, color-code them (or underline numerals, or whatever visual mark)
Related
Due to some odd circumstances I have the necessity to use uriQuery() in a Power Automate flow in order to extract the query string from an url.
This works as expected in most circumstances, except when the url contains special characters like accented letters, for example
http://www.example.com/peppers/Jalapeño/recipe #1.docx
In such cases the call triggers an error and the exception message shows a (partially) encoded version of my url (why?).
The template language function 'uriQuery' expects its parameter to be a well-formed absolute URI. The provided value was '......'
Obviously the url was indeed a well-formed, absolute URI.
Since the error only triggers when the url contains special characters I assumed that I had to encode the value before calling uriQuery(), yet nothing I tried seems to work (for example encodeUriComponent() ). And as expected nothing I could find on the web mentioned a similar issue.
As a last attempt I am asking here - does uriQuery() support this use-case? And if it does... how?
Every time I get an error when validating:
<iframe class="forecast" src="http://forecast.io/embed/#lat=-26.201560&lon=28.038995&name=Johannesburg,%20ZA&text-color=#ffffff&color=#ffffff&font=Helvetica&units=ca"></iframe>
Error (screenshot):
http://postimg.org/image/5h1kvzzuh/
I escaped the characters, but it didn't works.
Thanks.
W3C validator maintainer here. Short answer is, use instead the following:
<iframe class="forecast" src="http://forecast.io/embed/%23lat=-26.201560&lon=28.038995&name=Johannesburg,%20ZA&text-color=#ffffff&color=%23ffffff&font=Helvetica&units=ca"></iframe>
That is, the fix is just to replace # with %23 (the percent-encoding of the # character).
Explanation
The specific problem in that URL is the # character references it contains.
# is # (the “number-sign” or “hash” character), which is not a valid URL code point per the URL Standard, and so it’s not allowed in a URL.
The # character is only ever allowed in an absolute URL with fragment or relative URL with fragment—and then, explicitly allowed only after the part the URL spec defines as the actual URL.
And for the purposes of URLs, # and # are exactly the same.
Hence, you must use it as %23 (that is, percent-encoded).
P.S. I plan to get the URL checker in the validator updated to actually report the particular illegal characters it finds in URLs but it will be a while yet before I can get that refinement made.
I'm looking over Section 3.4 of RFC 3986 trying to understand what constitutes a valid URI query parameter key, but I'm not seeing a clear answer.
The reason I'm asking is because I'm writing a Ruby class that composes a URI with query parameters. When a new parameter is added I want to validate the key. Based on experience, it seems like the key will be invalid if it requires any escaping.
I should also say that I plan to validate the key. I'm not sure how to go about validating this data either, but I do know that in all cases I should escape this value.
Advice is appreciated. Advice in the context of how validation might already be possible through say a Ruby Gem would also be a plus.
I could well be wrong, but that spec seems to say that anything following '?' or '#' is valid as long. I wonder if you should be looking more at the spec for 'application/x-www-form-urlencoded' (ie. the key/value pairs we're all used to)?
http://www.w3.org/TR/html401/interact/forms.html#h-17.13.4.1
This is the default content type. Forms submitted with this content
type must be encoded as follows:
Control names and values are escaped. Space characters are replaced by +', and then reserved characters are escaped as described in [RFC1738], section 2.2: Non-alphanumeric characters are replaced by %HH', a percent sign and two hexadecimal digits representing the ASCII code of the character. Line breaks are represented as "CR LF" pairs (i.e., `%0D%0A').
The control names/values are listed in the order they appear in the document. The name is separated from the value by =' and name/value pairs are separated from each other by &'.
I don't believe key=value is part of the RFC, it's a convention that has emerged. Wikipedia suggests this is an 'W3C recommendation'.
Seems like some good stuff to be found searching on the application/x-www-form-urlencoded content type.
http://www.w3.org/TR/REC-html40/interact/forms.html#form-data-set
This is my first question... I hope my problem doesn't look stupid...
html (any symbols are allowed) ---> javascript event ---> javascript function sends text to .php file using ajax method.
Here is a problem:
when I use
xmlhttp.open("GET","proceed.php?q="+encodeURIComponent(str),false);
it works great for small texts (less than 1500 symbols)....
If I use
xmlhttp.open("GET","proceed.php?q="+str,false);
then it works for any length, but I have to be careful with special characters.
Why doesn't encodeURIComponent work for a bigger amount of text (over ~1500 even just simple alphanumeric symbols)?
Any ideas?
So, the problem is in this string (I've tested all the rest).
BTW, it was tested on bulgarian cyrillic letters...
With a text over 1500 symbols there is no action at all (no viewable mistake, no nothing, just nothing happens).
Thank you.
There are a number of limits which you can hit with the length of a URL. In IE, the total length of the URL, including a GET query string, must not exceed 2,083 characters. The server might impose a limit, too.
So apparently it's not encodeURIComponent itself which has a problem with long strings. Rather, the encoded result is longer than the unencoded string, and that seems to be enough to make you hit one of the limits I mentioned above.
I've got an app that receives urls after the # sign and responds to them with a History ValueChangeHandler. Serious problem: the urls are escaped differently on different browsers.
For example, when I go to #riley%2Blark%40gmail.com, Chrome sends my ValueChangeHandler riley%2Blark%40gmail.com while FireFox sends riley+lark#gmail.com. This is a terrible difference if I want to run URL.decodeQueryString on them because I'll end up with an extra space in Firefox.
How can I handle this, short of writing separate implementations for different browsers?
I can think of two possible solutions:
U could try adding another parameter
to the token so that the token was
of the for
#riley%2Blark%40gmail.com/%2B-a-space
on receiving the token, check the
second part of the token. If the
second part contains a %2B,
urldecode the token. else replace '+' with
You can also try using Location.hash
through JSNI. I reckon the results
ought to be uniform.