I do an HTTP GET request for a page using the following URL in Safari:
mysite.com/page.aspx?param=v%e5r
The page contains a form which posts back to itself.
The HTML form tag looks like this when output by asp.net:
<form method="post" action="page.aspx?param=v%u00e5r" id="aspnetForm" >
When Safari POSTs this back it somehow converts this URL to:
page.aspx?param=v%25u00e5r, i.e. it URL encodes the already URL encoded string, which is then double encoded and the output generated by this parameter is garbled (vår). I am able to get around this some places by URL decoding the parameter before printing it.
Firefox and even IE8 handles this fine. Is this a bug in WebKit or am I doing something wrong?
To summarise:
GET mysite.com/page.aspx?param=v%e5r
HTML: <form method="post" action="page.aspx?param=v%u00e5r" id="aspnetForm" >
POST mysite.com/page.aspx?param=v%25u00e5r
HTML: <form method="post" action="page.aspx?param=v%25u00e5r" id="aspnetForm" >
mysite.com/page.aspx?param=v%e5r
Whilst you can use encodings other than UTF-8 in the query part of a URL, it's inadvisable and will generally confuse a variety of scripts that assume UTF-8.
You really want to be producing forms in pages marked as being UTF-8, then accepting UTF-8 in your application and encoding the string vår (assuming that's what you mean) as param=v%C3%A5r.
page.aspx?param=v%u00e5r
Oh dear! That's very much wrong. %uXXXX is a JavaScript-escape()-style sequence only; it is wholly invalid to put in a URL. Safari is presumably trying to fix up the mistake by encoding the % that isn't followed by a two-digit hex sequence with a %25.
Is ASP.NET generating this? If so, that's highly disappointing. How are you creating the <form> tag? If you're encoding the parameter manually, maybe you need to specify an Encoding argument to HttpUtility.UrlEncode? ie. an Encoding.UTF8, or, if you really must have v%e5r, new Encoding(1252) (Windows code page 1252, Western European).
Related
The macro scheduler I am using is the product offered at https://www.mjtnet.com/
My ultimate goal is to have a macro that will send emails with images embedded into it. To do this, I want to be able to convert image files into Base64 strings so that they can be embedded with HTML. The problem that I'm running into is that I cannot figure out how to properly access the data for the image files within Macro Scheduler. I've tried using the file location of the image as an input for the Base64 function, but that only returns the encoded version of the location string. I've also tried using the ReadFile function, but that returns an empty string as it's use is for text files.
Currently my program looks like this:
Let>SENDMAIL_STATUS=1
Let>SMTP_HTMLBODY=1
Let>image=C:\Users\xyz\Documents\image.png
Base64>image,ENCODE,embedded
Let>body=<html> <head> </head> <body> <img src="data:image/png;base64,%embedded%"> </body> </html>
SMTPSendMail>...,...,...,...,...,body,image
The email sends without issue, but the body of it only shows an empty image icon.
So with all this in mind, how do I encode an image file into a base64 string?
Is there any <!doctype> for "HTML 4.01 Strict Markup + ARIA"?
Also am currently having HTML 4.01 Strict <!DOCTYPE>, I obviously get an error while validating my page with the W3C Validator.
Is there any solution to this problem?
Also when I use the Accessibilty Toolbar, I get the following error pointing to the line after the closing HTML tag:
Line 256, Column 1: character data is not allowed here
Content-Disposition: form-data; name="charset"
You have used character data somewhere it is not permitted to appear.
Mistakes that can cause this error include:
putting text directly in the body of the document without wrapping it in a container element (such as a <p>aragraph</p>), or
forgetting to quote an attribute value (where characters such as "%" and "/" are common, but cannot appear without surrounding quotes), or
using XHTML-style self-closing tags (such as <meta ... />) in HTML 4.01 or earlier. To fix, remove the extra slash ('/') character. For more information about the reasons for this, see Empty elements in SGML, HTML, XML, and XHTML.
There is no published DTD for HTML 4.01 + ARIA. It would be possible to write one, if only there were a stable, exact document that specifies the allowed ARIA attributes and the HTML 4.01 elements on which they may be used. Using WAI-ARIA in HTML is still a WD only, and calls itself “a practical guide”. And I’m not sure how it should be interpreted. I guess the simplest, and possibly the only realistic, approach would be to write a DTD that allows all ARIA attributes on all elements, with the same set of values for all elements, even thoughh this would violate many of the recommendations.
The other question seems to be unrelated, and should probably be asked as a separate question. And you should probably explain what accessibility toolbar you are referring to and what your HTML document contains.
I've been a longtime user of XHTML 1.0 Strict, and I'm now trying to switch to XHTML5 in my new projects.
I'm confused that <?xml version='1.0' encoding='utf-8'?> is no longer considered valid, for HTML5, by http://validator.w3.org/. Why is that? Isn't that what all xml documents are supposed to start with?
And when I remove the standard <?xml…, my document still doesn't validate: now it's missing the encoding. I don't like those meta tags, but are they now effectively mandatory, to specify the encoding, in order to be valid (X)HTML5?
An XML declaration is valid and validates in XHTML serialization of HTML5. The following rather minimal document validates:
<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head><title></title></head>
<body></body>
</html>
However, this only applies to XHTML serialization (XHTML syntax) of HTML5. In HTML serialization, it is not allowed. If you write the above document in a file and store it in a server that will send it with Content-Type: text/html (which normally happens if the filename ends with “.html”), then you get an error message:
Saw <?. Probable cause: Attempt to use an XML processing instruction in HTML.
(XML processing instructions are not supported in HTML.)
Here “HTML” means HTML serialization only.
Browsers do not care about an XML declaration in either syntax. In HTML syntax, it is just ignored, as a recoverable syntax error. In XHTML syntax, it does not matter, except for the encoding part.
Although XML 1.0 specification recommends (but does not require) an XML declaration, it would in practice matter (apart from the significance of encoding) only to software that is capable of processing different versions of XML. Browsers aren’t. And in addition to XML 1.0, there’s just XML 1.1, which is not used much. Besides, HTML5 is defined so that the XML version used in XHTML syntax is XML 1.0.
The encoding part may matter, but utf-8 is the default anyway for XML. If you use another encoding for some reason, then an XML declaration may be useful to prevent any conflicts. HTML5 CR says this in it discussion of encodings: “In XHTML, the XML declaration should be used for inline character encoding information, if necessary.” A meta tag cannot really help in XHTML when served with an XML content type, since the encoding has already been decided (by defaulting to UTF-8 or otherwise) when the tag is seen.
For HTML syntax, the <meta charset=...> tag may be used, but it is not needed for validity, and the encoding can be specified in HTTP headers (which override any meta tags). Using a meta tag may however be helpful, since a page might be saved locally, and then there won’t be any HTTP headers available when it is opened.
I have a JSP page in which I have JavaScript function that will be called when a link is clicked. Now, when the value reaches the JavaScript function, the apostrophe is encoded.
Example:
Name#039;s
Before # there is &, which originally should be:
Name's
I have used the unescape() decode function, but nothing seems to work. In the end, I had to delete the characters and add the apostrophe. Does anyone know a fix for this? Is it that JSP doesn't support encoding for &? When I was writing the same encode value in this page, it changed the symbol to the apostrophe, which is what I wanted in my code.
Built-in Javascript function such as unescape(), decodeURIComponent() has nothing to do with the string you are working on, because the one you are looking to decode are HTML entites.
There are no HTML entites decoder available in Javascript, but since you are working with a browser, if the string is considered safe, you may do the following (in JQuery, for example)
var str = $('<p />').html(str).text();
It bascially insert the string as HTML to a <p> element and then extract the text within.
Edit: I just realize the JSP output you posted is not real HTML entities; To process the example given you should use the following, add & before every #1234; and make it Ӓ:
var str = $('<p />').html(str.replace(/\#(\d+)\;/g '&#$1;')).text();
I am working in a template in Moveable Type and would like to do the following:
Twitter
It all works but I'm worried that the current link or at some point even if I use a title mt tag that it might not be right for the browser address bar. I thought you could use encode_url="1" but it doesn't appear to encode my titles or links. For example: I have a title with spaces in it and the resulting code still has the spaces in it. Also for the example above shouldn't the http:// be encoded in a special way? Because it doesn't do it.
Am I doing something wrong here?
I just checked this code and it is outputting properly for me. I am using MT 4.34. I used the following template code in an index templated:
<mt:Var name="url" value="http://google.com/hello I have spaces">
<mt:Entries lastn="1">
Permalink: <mt:EntryPermalink encode_url="1"><br />
Fake URL: <mt:Var name="url" encode_url="1">
</mt:Entries>
And I got the following output:
Permalink: http%3A%2F%2Fwww.capndesign.com%2Farchives%2F2010%2F09%2Fthe_big_picture_scenes_from_china.php
Fake URL: http%3A%2F%2Fgoogle.com%2Fhello%20I%20have%20spaces
So I would confirm that you're using a current version of MT (4.34 or 5.x) that supports this modifier, because the spaces and special characters should definitely be getting replaced with HTML entities. I'd also try the code I provided above to see if you get the same output (except your permalink will obviously be different).