The slash character collides with Cloudinary's functionality, as specifically slashes in Cloudinary URLs are used for separating between different chained transformations (e.g., w_100/r_20).
So if the regular slash (or even its %2F escaped version) is used, Cloudinary will think that the next chained transformation is entered rather than the rest of the text string.
Therefore, you can either double escape the slash character (e.g., %252F):
Alternatively, you can use a special encoding of a different type of the slash character (%E2%88%95):
http://res.cloudinary.com/demo/image/upload/w_300,o_30/l_text:Arial_20_bold:www.cloudinary.com%E2%88%95console/couple.jpg
Generally it would be a good practice to double-escape the entire overlaid text, e.g.:
https://res.cloudinary.com/demo/image/upload/w_300,o_30/l_text:arial_30:%252C%2520-%2520comma%250A%2520%253F%2520-%2520question%2520mark%250A%2520%252F%2520%255C%2520-%2520both%2520slashes%250A%2523%2520-%2520hash./couple.jpg
Comments
7 comments
That took some finding ...
when I double escape the following string and send it over
"The arrangement covers the movie studio 20th Century Fox, the company’s TV production arm 20th Century Fox Television, Fox-owned cable networks (including FX and National Geographic), and the company’s stakes in international networks like Star TV and Sky (which Fox is planning to acquire full ownership of before"
I'm receiving the following image with encoding characters
Hi Salil,
In order to get a valid URL, please use encodeURIComponent instead of escape, like this:
overlayText = encodeURIComponent(encodeURIComponent(text));
You can read more about the difference between the two methods here:
http://xkr.us/articles/javascript/encode-compare/
hello, how about % character, I tried double-escape for that, but the node js library state that it's failing to decode URI malformed
Hi Lowell,
Can you please share with us your implementation?
This is a super helpful article that is unnecessarily hard to find relative to the text overlay docs, which lead the reader in a totally different direction, which only mentions single encoding rather than double encoding:
?with%3Fand using%20for spacing between words). This encoding is done automatically when embedding images using the Cloudinary SDK helper methods and only needs to be done when manually adding the image delivery URL.Why don't the SDKs automatically do this double-encoding if it's so critical? The node.js SDK doesn't seem to mind accepting a string with special characters in it, and without validation it generates invalid cloudinary URLs (single-escaped only, per the above note). To get the SDK to work, I currently manually double-escape strings, run the SDK with a placeholder token, and then manipulate the resulting SDK-generated URL with a token substitution.
How come Cloudinary's router/url parser can't keep track of escape depth instead of pushing this burden onto the developer?
Ughhh.
Hi Ritchie, we appreciate your feedback! I will share your inputs internally and will update on any improvements made based on that. Thanks again!
Please sign in to leave a comment.