I have created a small test page using Sencha Touch, OpenLayers and I am recieving WMS/WFS data from a GeoServer.
I have set the encoding on my HTML page to UTF-8:
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
I pull some WFS data from my GeoServer using the following statement:
var post = new OpenLayers.Request.POST({
url: 'dataprovider.ashx',
data: ...,
headers: {
"Content-Type": "text/xml;charset=utf-8"
},
callback: function (response) {
...
},
});
Which I believe should give me the requested data encoded as UTF-8.
Using an IPhone 4 (IOS 4) and a Samsung Galaxy Tab 10.1 (Android 3.1) it works just fine.
My problem is: Using a device with Android 2.2, I get data back in a different encoding.
One of the words I expect to recieve is Høj, but I recieve Høj (ANSI).
Using FireFox and Chrome I know how to debug the response from the GeoServer, but I don't know how to debug the phones or tablets.
Why is the encoding wrong on Android 2.2?
UPDATED: The problem seems to be related to devices using Android 2.2. A HTC Legend, a Samsung Galaxy SII and a Samsung Galaxy Tab 7 is having the problem - all running Android 2.2.
I have faced exactly the same problem using GeoServer, openLayers, and Android browser (Android 2.2).
I made some research looking for place where the problem exist. All in all I went down to XMLHttpRequest.js. In this file openLayers is creating XMLHttpRequest object making request and receiving response. I have found also that in this stage already received data has encoding problem.
I have also sniffed communication using wireshark to assure that data I am sending is in correct encoding (utf-8). I dumped this data and figured out that it was correct utf-8 data.
But what was interesting that when I tried display my utf-8 data using iso-8859-1 I received exactly the same output as in Android browser.
My conclusion:
In android 2.2 web browser XMLHttpRequest object is always reading data assuming iso-8859-1 encoding.
My solution:
You have to fix string yourself. First you have to made map where you have to memorize that for instance "ø" is "ø". And then by examining character by character when you find "ø" sequence substitute it by "ø". This is example code:
goodString = "";
for( i = 0; i < wrongString.length; i++) {
var w = wrongString.charCodeAt(i);
var c = wrongString.charAt(i);
if(w == "Ã".charCodeAt(0) {
w2 = wrongString.charCodeAt(++i);
if(w2 == "¸".charCodeAt(0))
c = 'ø';
}
goodString += c;
}
Related
I'm trying to use the Flutter url_launcher package to create a feedback form template. It worked well so far but I recently did a major package versioning upgrade and now it seems like something is going wrong in the translation of the placeholders.
final Uri _emailLaunchUri = Uri(
scheme: 'mailto',
path: recipient,
queryParameters: {
'subject': subject,
'body': body,
},
);
var newurl = _emailLaunchUri.toString();
return newurl;
The upper is my chunk of code to generate the uri and eventually return the new launch url including some Device information. Printing it out leads to the following output in the console:
mailto:support#support.de?subject=Feedback%3A+App+Name%28Subtitle%29&body=Dear+developers%2C%0D%0A%0D%0AiOS+version%3A+14.6%0D%0Amodel%3A+iPhone11%2C8%0D%0A
So far so good I guess, but that's how it ends up to look in my app (tested on a physical iPhone):
Is there anything I miss or that Apple might have changed in the recent iOS versions? My iPhone is using version 14.6. I figured out to replace the "+" with a %20 instead (seems to be a package error), but I'm not sure how to convert the line breaks correctly.
Would appreciate any help.
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);
I recently got a NodeMCU toolchain working with https://github.com/slaff/esp8266.dev.box, but when I try to do a http.get, it immediately fails with the code -1, even though with the firmware from https://nodemcu-build.com/ it works fine. The heap space is approximately the same for both firmwares, and with both the custom built firmware and the cloud built one it works with a different URL.
The URL it is not working with is private, but overall it links to a google sheet and gets a CSV file. It still fails even when the CSV file is a single '0', and succeeds with a URL that links to a .txt file with around 20 characters.
Example url it doesn't work on:
https://docs.google.com/spreadsheets/d//pub?output=csv&gid=0&single=true&gridlines=false&chrome=false
My user_modules.h from when I build:
http://pastebin.com/1LbxmS2B
My user_config.h:
http://pastebin.com/qBixhqyC
My Lua code (runs after I've successfully connected to wifi):
http.get(url, nil, function(code, data)
print(code, data)
end)
Is there something that I am doing wrong when I build the firmware? Any help is greatly appreciated.
Your user_config.h doesn't enable SSL-support (line 67), it's off by default.
i have a problem to run flash file on android 4.0, I used intent but nothing happened and now i am using web view to run but only sound is coming and only white screen is on display.
please help me to solve my problem, i am stuck here and i am in big trouble. below is my code that i used.
webView = (WebView)findViewById(R.id.webView);
webView.getSettings().setJavaScriptEnabled(true);
webView.getSettings().setAllowFileAccess(true);
//webView.getSettings().setPluginsEnabled(true);
webView.getSettings().setPluginState(WebSettings.PluginState.ON);
String html = "<object width=\"550\" height=\"400\"> <param name=\"movie\" value=\"file:///sdcard/mainV7.swf\"> <embed src=\"file:///sdcard/mainV7.swf\" width=\"550\" height=\"400\"> </embed> </object>";
String mimeType = "text/html";
String encoding = "utf-8";
webView.loadDataWithBaseURL("null", html, mimeType, encoding, "");
Please check this link : Flash Support for Android
Also check whether your device supports flash file or not.
I am using ABCPDF to print a PDF file to a local printer via EMF file. I've based this very closely on ABC PDF's sample "ABCPDFView" project. My application worked fine on my Windows 7 and Windows XP dev boxes, but when I moved to a Windows 2003 test box, simple embedded fonts (like Times New Roman 12) rendered completely wrong (wrong spot, and short and squat, almost like the DPI's were crazily wrong).
Note that I've hardcoded the DPI to 240 here b/c I'm using a weird mainframe print driver that forces 240x240. I can discount that driver as the culprit as, if I save the EMF file locally during print, it shows the same layout problems. If I render to PNG or TIFF files, this looks just fine on all my servers using this same code (put .png in place of .emf). Finally, if I use the ABCPDFView project to manually add in a random text box to my PDF, that text also renders wrong in the EMF file. (Side note, if I print the PDF using Acrobat, the text renders just fine)
Update: I left out a useful point for anyone else having this problem. I can work around the problem by setting RenderTextAsText to "0" (see code below). This forces ABCPDF to render the text as polygons and makes the problem go away. This isn't a great solution though, as it greatly increases the size of my EMF files, and those polygons don't render nearly as cleanly in my final print document.
Anyone have any thoughts on the causes of this weird font problem?
private void DoPrintPage(object sender, PrintPageEventArgs e)
{
using (Graphics g = e.Graphics)
{
//... omitted code to determine the rect, used straight from ABC PDF sample
mDoc.Rendering.DotsPerInch = 240 ;
mDoc.Rendering.ColorSpace = "RGB";
mDoc.Rendering.BitsPerChannel = 8;
mDoc.SetInfo(0, "RenderTextAsText", "0");//the magic is right here
byte[] theData = mDoc.Rendering.GetData(".emf");
using (MemoryStream theStream = new MemoryStream(theData))
{
using (Metafile theEMF = new Metafile(theStream))
{
g.DrawImage(theEMF, theRect);
}
}
//... omitted code to move to the next page
}
Try upgrading to the new version of abcpdf 8, it has its own rendering engine based on Gecko and so you can bypass issues like this when abcpdf is using the inbuilt server version of IE for rendering.
I was originally RDPing in with 1920x1080 resolution, by switching to 1024x768 res for RDP, the problem went away. My main program runs as a service, and starting this service from an RDP session w/ 1024x768 fixes it.
I have an email out w/ ABC PDF to see if they can explain this and offer a more elegant solution, but for now this works.
Please note that this is ABC PDF 7, I have no idea if this issue applies to other versions.
Update: ABC PDF support confirmed that its possible the service is caching the display resolution from the person that started the process. They confirmed that they've seen some other weird issues with Remote Desktop and encouraged me to use this 1024x768 workaround and/or start the service remotely.