Original Windows Phone 7.5/8.0/8.1 WebBrowser Rendering exception and how to solve it
Recently in the development of hamster client and laughter, have encountered in different versions of the simulator or the real-time browser rendering Web page effects vary, such as the situation:
From left to right respectively for the WP7, WP8.0 and WP8.1 simulator effect, you can see the left Figure page rendering, but Chinese garbled, the page is not rendered at all, the right picture is very firm and perfect. This article will discuss how to solve these problems in one by one.
Let's start by explaining my lab environment and scenario, which is a WP7 Silverlight App that uses a WebBrowser control to display a Web page that doesn't jump with the usual navigate method, Instead, download the source page and use the Navigatetostring method to display it.
The following is the full source of this page
<! DOCTYPE html>Attentive readers will be able to notice from the content of this page two points, first, this page is UTF8 encoded, second, the content of this page contains Chinese.
From the above three cases, one is the Chinese garbled problem, one is that the Web page did not render successfully just display the HTML tag. In the light of the above, it can be concluded that:
1) Because the problem of parsing the encoding is garbled in Chinese, this situation will only appear in the WP7 browser (in fact, the second picture of the garbled is not caused by this)
2) Because of the WP8 browser's own defects, resulting in navigatetostring when rendering failed, only loaded the source of the Web page (because the equivalent of plain text display, so there is a figure in the Chinese garbled)
3) WP8.1 Browser does not appear at all with these problems
Then we'll solve these problems individually.
1) for WP7 browser
This is caused by WP7 browser design flaws, as long as the UTF-8 encoding, contains non-generic English characters will be garbled problems, including Chinese, Japanese, Arabic, Korean, Russian and so on. We know that ASCII code is defined with a 7-bit binary number, the maximum encoding is defined only to 127, a total of 128 universal characters, and does not contain other foreign characters. Since 128-255 is an extension of the encoding, it is not used as a display, and our browser is hard to ask for these characters as display characters, obviously rendering is not out, and thus garbled, then the solution is to convert more than 127 characters into extended ASCII code.
Although the standard ASCII code is 7-bit encoded, because the computer's basic processing unit is bytes (1byte = 8bit), it is generally still a byte to hold an ASCII character. The extra one (highest bit) in each byte is usually maintained at 0 (used as a parity bit in data transfer). Due to the limited number of characters in the standard ASCII character set, the requirements are often not met in practical applications. To this end, the International Organization for Standardization has also developed the ISO2022 Standard, which provides a unified method of extending the ASCII character set to 8-bit code while maintaining compatibility with ISO646. ISO has developed a batch of extended ASCII character sets for different regions, each of which can be expanded to 128 characters, each of which is encoded as a high-level 1 8-bit code (that is, decimal number 128~255), called extended ASCII code. Extended ASCII characters satisfy the need for more characters. The extended ASCII contains 128 characters already in ASCII and 128 characters in total, 256.
Let's take a look at the Extended ASCII code table
and ASCII table
With these background knowledge, we understand that the ASCII code is &#+ corresponding to the decimal code, so we in the program, will be greater than 127th characters to convert, in your program to add the following method for processing
public static string Convertextendedascii (string html) { string retVal = ""; if (string. IsNullOrEmpty (HTML)) { return retVal; } Char[] s = HTML. ToCharArray (); foreach (char c in s) { if (Convert.ToInt32 (c) > 127) RetVal + = "" "+ Convert.ToInt32 (c) +"; " else retVal + = c; } return retVal;}
Add this process and then use navigatetostring, you can see the WP7 browser has been able to display the page is normal:
Why is the same problem not appearing in WP8 and WP8.1? Because WP8 and WP8.1 have used the extended ASCII code in the beginning, there is no garbled problem when rendering.
2) for WP8.0 browser
In the experiment, I was surprised to find that the original source of this page contains two meta tags, and I just remove any one of them, the content of the page is normal display, but the actual production needs are not guaranteed to contain only a meta tag. After the comparison with WP7 and WP8.1 browser in the same situation, I found that this problem will only appear in the WP8.0 browser navigatetostring method, if I directly nagivate a page URI is no problem. So this should be the WP8.0 WebBrowser in the navigatetostring parsing the bug that appears ... System problem Pit Daddy.
Here is the solution, for WP8.0, do not use navigatetostring, or use the Navigate method, but this page content is text ah, how to jump to a URI ah?
WP powerful independent storage advantages are reflected here, remember how to store the independent storage of the file how to access it, yes, through an isolated storage uri! Then we will temporarily store the text content of the Web page in isolated storage, get a URI, let WebBrowser jump to this URI can be. The code is as follows:
using (System.IO.IsolatedStorage.IsolatedStorageFile file = System.IO.IsolatedStorage.IsolatedStorageFile.GetUserStoreForApplication ()) { if (!file). DirectoryExists ("temp")) { file. CreateDirectory ("temp"); } using (System.IO.IsolatedStorage.IsolatedStorageFileStream fs = new System.IO.IsolatedStorage.IsolatedStorageFileStream ("temp\\review.html", System.IO.FileMode.Create, file)) { byte[] bytes = System.Text.Encoding.UTF8.GetBytes (gift. ContentText); Fs. Write (bytes, 0, bytes. Length);} } _webbrowser.navigate (New Uri ("temp\\review.html", urikind.relative));
As a result, the WP8 browser will display the results correctly: