when hyperlink is sent in an email, the hyperlink works fine as long as it doesn't end with an "=" character. e.g
<code>
http://example.com/my-service?access-token=abcd1219191=
</code>
When seen in Microsoft Outlook on Windows the = character at the end of hyperlink is no longer a part of the hyperlink i.e
<code>
<http://example.com/my-service?access-token=abcd1219191>=
</code>
only the part between <> remains a hyperlink , this causes link to not work as expected.
Any clues to get around this problem??
Note : The above thing works perfectly fine on Microsoft Outlook for Mac.
Here is a workaround to solve the above problem
just replace any trailing equals sign with the encoded version i.e %3D , the hyperlink would work perfectly alright.
e.g replace http://example.com/service/access=12snssamhsdh= with
http://example.com/service/access=12snssamhsdh%3D
Send Your Hyperlink with Double quotes appended at the Front and Back of the link
For Example:
send it as
"http://example.com/my-service?access-token=abcd1219191="
and not
http://example.com/my-service?access-token=abcd1219191=
Related
Something that drives me nuts in the developper tools of Chrome (106) and Firefox (105) is the fact that whenever some text logged to the console via console.log(text) happens to contain a hyperlink, this link is not only turned clickable (I can live with it even when I usually prefer to have just plain text) but is abbreviated, if it is a long link. So when I want to control what precise link is in some variable, I cannot just write e.g. console.log(img.src), because some of the interesting information of the link is hidden.
You can try yourself with
var href = 'https://stackoverflow.com/search?q=%5Bgoogle-chrome-devtools%5D+%5Bconsole.log%5D+%5Bfirefox-developer-tools%5D+%5Bhyperlink%5D+automatic+detection&someMoreStuffTomakeTheLinkLonger';
console.log(href);
In both, Firefox and Chrome, the output for me contains some '...', e.g. in Firefox I obtain as output:
https://stackoverflow.com/search?q=%5Bgoogle-chrome-devtools…link%5D+automatic+detection&someMoreStuffTomakeTheLinkLonger
thus hiding the part after "-devtools". (Chrome hides a slightly different part). The console is mostly a debugging tool. I log things because I want to see them, not hide them. I always need to either hover with the mouse and wait for the tooltip (doesn't allow me to copy fractions of the link) or to right click copy the link and paste it somewhere where I can see it completely. Or take a substring to remove the "https://" in the front. But note that the variable isn't necessarily a single hyperlink, but can be any text containing several such hyperlinks. I didn't find a way to force console.log to just print plain text all content. Did anybody meet this problem as well and find a workaround?
I made this a community wiki answer, because the main insight is not from myself but from the comments. Feel free to improve.
The console.log() function allows several arguments, which allows also a formatted output similar to printf in some languages. The possibilities of formatting can be found in the documentation of console.log() on MDN. In any case, this formatted output provides a solution at least for Chrome, as #wOxxOm pointed out in the comments:
console.log('%O', href) // works in Chrome
This is rather surprising, because %O is described at MDN as
"Outputs a JavaScript object. Clicking the object name opens more information about it in the inspector".
It seems there is no 'clicking' in Chrome when the object is a string.
There is also %s for string output, but this just gives the standard behavior of replacing links in both browsers. And for Firefox none of the above two formatting options works. There one really has to replace the protocol "https://" by something that is not recognized as link. A space behind ':' seems enough, so "https: //". It turns out, that one can also insert a formatting string "https:%c//", which can even be empty, and thus yield an output which is the complete link and can be copied as well:
console.log(href.replace(/(https?:)/, "$1%c"), ""); // works in Firefox
In particular the FF solution is cumbersome, and there might also be several links within one console-output. So it is useful to define one's own log-function (or if one prefers, redefine console.log, but note the remark at the end)
function isChrome() {...} // use your favorite Chrome detection here
function isFirefox() {...} // use your favorite Firefox detection here
function plainLog() {
const msg = arguments[0];
if (isChrome() && arguments.length == 1 && typeof msg == "string") {
return console.log("%O", msg);
}
if (isFirefox() && arguments.length == 1 && typeof msg == "string") {
const emptyStyle = ""; // serves only as a separator, such that FF doesn't recognize the link anymore
const reg = /(https?:)\/\//g;
const emptyStyles = []; // we need to insert one empty Style for every found link
const matches = msg.matchAll(reg);
for (let match of matches) {
emptyStyles.push(emptyStyle);
}
return console.log(msg.replace(reg, '$1%c//'), ...emptyStyles);
}
return console.log(...arguments);
}
For browser detection isChrome() and isFirefox() see e.g. here on SO.
One can of course extend the redefinition also to the other console functions (console.info, console.warn, etc.)
The downside of the redefinition of console.log is that usually every output of the console shows also the last entry of the call stack as a practical link to the source of the logging. But due to the redefintion, this link is now always to the same place, namely the file and line number where plainLog() is defined and calls console.log(), instead of the place where the new log command plainLog() was called. This new problem is described on SO here, but the solution (see comment) is again a bit involved and also not completely satisfying to serve as a replacement for the built-in console.log . So if links appear only rarely in the logging, it's probably better to switch to the redefined plainLog() only for these links.
We have a Slash command integration and discovered that the text passed to the slash command is encoded differently if it comes from the (iOS) mobile app compared to the Desktop app.
For the command "/whereis #xsd" on the MacOS Desktop app, the text element in the body is encoded as: text=%3C%23C02MKG1LH%7Cxsd%3E
For the command "/whereis #xsd" on the iOS app the text element in the body is encoded as: text=%26lt%3B%23C02MKG1LH%7Cxsd%26gt%3B
The iOS app is incorrect.
Did anyone else experience this? Any solutions?
(I have posted this question to Slack, they confirmed the behavior a while back but no solution from them so far).
This is not a bug. Both are valid HTML encodings. You can verify this by decoding them on this website.
The difference is that the string from IOS also includes an encoding of HTML special characters (like <) but the desktop string does not. To address this your app has to first do a URL decoding of the input string and then decode special HTML chars.
The results are:
Desktop: <#C02MKG1LH|xsd>
IOS: <#C02MKG1LH|xsd>
Here is a sample code that will decode both strings correctly in PHP:
<?php
function decodeInputString($input)
{
return htmlspecialchars_decode(urldecode($input));
}
$desktop = "%3C%23C02MKG1LH%7Cxsd%3E";
$ios = "%26lt%3B%23C02MKG1LH%7Cxsd%26gt%3B";
$desktop_plain = decodeInputString($desktop);
$ios_plain = decodeInputString($ios);
var_dump($desktop_plain);
var_dump($ios_plain);
Is it possible to provide spaces or new line or line breaks on gmail compose on URL schemes. I tried both /n or stringByAddingPercentEscapesUsingEncoding, but space or lines breaks are not reflecting.
googlegmail:///co?subject=subject&body= "\n\n\n textfirstname"
This is not an issue with iOS or url-scheme. You need to use html tag to set new line. For HTML there are <br/> or <br /> which are used to break line. Use this tag instead of \n.
As per you code it should looks like this:
Whatever<br/>text<br/>you<br/>want
I hope this will be useful to you.
I am facing problem when passing value for url through data field.
I am passing value in goto url like this
="javascript:void(window.open('file:" &Fields!url.Value &"','_blank'))"
url value = /servername/foldername/FormuláriodeCalibração.xls
After report deployed and opened in internet explorer and clicked on the url. It is changing the url like this
/servername/foldername/FormuláriodeCalibração.xls
because of which I am unable to open the file.
Please help me in this.
Finally we come up with a solution of replacing non ASCII characters of Portuguese with HTML ASCII Codes.
For e.g. this is the actual file name of the attachment
TE-5180FormuláriodeCalibração(modelo)1271440308393(2)1338379011084.xls
We replaced the Portuguese characters with HTML ASCII Codes.
TE-5180FormuláriodeCalibração(modelo)1271440308393(2)1338379011084.xls
After these changes the above modified URL is passed in the place of actual URL and when it hits the server it was decoded properly and worked as expected.
I have a simple div with onclick attribute. The attribute contains a mailto achor tag so if the visitor click on the div his/her mail client pops up with a new mail window.
My problem is that I have a sample tag in the mail body with line breaks. In OS X Mail.app, Windows' Outlook, Gmail and even in my Windows Phone 7.5 default mail client it works perfectly but on my iPhone or iPad there are no line-breaks.
For line-breaks I use the following code: \u2029.
I copy the whole code so you can understand my problem:
<?php
$linebreak = '\u2029';
$signup_email = 'hello#company.com';
$signup_subject = 'Signup';
$signup_body = 'Dear Company,'. $linebreak . $linebreak .'I would like to signup as the following'. $linebreak .'My name: '. $linebreak .'My e-mail: '. $linebreak . $linebreak . $linebreak .'Best regards, '. $linebreak;
?>
<div id="signup" class="left" onclick="location.href='mailto:<?=$signup_email;?>?subject=<?=$signup_subject;?>&body=<?=$signup_body;?>';">Signup</div>
The sample text is just a sample text, I don't want to make a signup form like this (it would be so lame (: )
OK, I just figured it out.
In this post the author says you should use %0D%0A squence to break lines. And it works! I tried in Gmail, OS X default Mail.app, MS Outlook and Thunderbird on Windows XP/7, Windows Phone 7.5, iOS 5.1 and iOS 4.2.1.