I deployed a .war file through IntelliJ Idea on a Tomcat server.
I noticed a character "ä" was not properly displayed while at other places the same character was displayed correctly. I found out that only the special characters that I hard-coded in my .js files were affected.
I tried to set all my .js files to UTF-8 in IntelliJ, I also changed all standard encoding settings to UTF-8 but the error didn't go away.
All my js files are mapped into one index.js file using webpack, but how exactly I don't know because this is a project initially set up by someone else.
I recently made a new interesting observation:
When I first open up a browser (tested with Firefox and Chrome) it's displayed incorrectly:
On regular reload (F5) nothing changes, but when reloading with CTRL + F5 it's suddenly correct:
This really confused me...does anyone have an idea what might be going on here?
I used to have the same problems with my Java files, but after changing the encoding in my gradle build file that worked.
Ultimately my question is:
What do you think should I change in order for the special characters to always be displayed correctly?
I add a similar problem after a tomcat update on a Windows server: the javascripts content corrupted characters at the browser side.
The http headers were corrects so I investigated a bit further.
On the server, the javascript files were saved in utf-8 without BOM.
With Wireshark, I saw that the character 'é' (C3-A9 in the file UTF-8 encoded ) was transmitted as (C3-83-C2-A9). It means that Tomcat was reading an ANSI file and gently converted it to UTF8!
So I just added the BOM to the saved the files and it fixed the bug. (REM: it is easy to add the BOM with notepad++).
But I didn't want to update all the server files, I wanted tomcat to read UTF-8 correctly.
The easy fix is to define the file encoding in the tomcat web.xml like this:
<servlet>
<servlet-name>default</servlet-name>
<servlet-class>org.apache.catalina.servlets.DefaultServlet</servlet-class>
<init-param>
<param-name>debug</param-name>
<param-value>0</param-value>
</init-param>
<init-param>
<param-name>listings</param-name>
<param-value>false</param-value>
</init-param>
<!------------------- add the settings here ------------->
<init-param>
<param-name>fileEncoding</param-name>
<param-value>utf-8</param-value>
</init-param>
<!------------------- end of the added settings ------------->
<load-on-startup>1</load-on-startup>
</servlet>
This really confused me...does anyone have an idea what might be going on here?
Caching. Ctrl+F5 tells the browser to reload the resource even if it has it cached. F5 will reuse the resource from cache if it's in cache.
What do you think should I change in order for the special characters to always be displayed correctly?
You may have already done it given the F5/Ctrl+F5 thing above.
Basically, ensure that:
The files (.js, .html, etc.) are stored in the correct encoding and, when viewed with that encoding, show the characters correctly. Strongly recommend using the same encoding for each type of file, although theoretically it's possible to use UTF-8 for JavaScript files and (say) Windows-1252 for HTML files. But that's just asking for complexity and hassle.
Ensure that every step in the pipeline correctly identifies the encoding being used for the files. That means (for instance) that Tomcat needs to include the header Content-Type: application/javascript; charset=utf-8 or similar for your .js files. (text/javascript; charset=utf-8 will also work, but is obsolete.) For HTML files, though, the W3C recommends including the meta header and omitting the charset from Content-Type.
Ensure that your HTML files identify the encoding in a meta tag near the top of head (within the first 1024 bytes) as well: <meta charset="UTF-8"> The W3C provide several reasons (same link as the bullet above) for doing this, such as saving the file locally and opening it (thus not having an HTTP header), making it clear to human and machine readers, etc.
Related
I am referencing two JS files in my map.HTML header. Chrome console gives
Uncaught SyntaxError: Unexpected token <
Here is why I'm confused. When I click on the Chrome Console error message, it takes me to the Sources tab. Under Sources, it puts me on the relative JS tab, and shows code starting with < !DOCTYPE html> then continues with a ton of code that is not in my map.html file or JS file. Presumably this is generated when the JS is read?
The two JS files are:
https://github.com/socib/Leaflet.TimeDimension/tree/master/dist
https://github.com/calvinmetcalf/leaflet-ajax/tree/gh-pages/dist
I am opening map.HTML locally with Chrome using a simple python server using a batch file (python.exe -m http.server).
I am sure this is very basic, but it's confusing me because I reference plenty of other JS files both online and locally and I don't get this error.
Thanks
If you try https://github.com/socib/Leaflet.TimeDimension/blob/master/dist/leaflet.timedimension.min.js in your browser, you will get an HTML page.
If you try https://raw.githubusercontent.com/socib/Leaflet.TimeDimension/master/dist/leaflet.timedimension.min.js you will get what seams a source javascript file. But your browser may also consider it text/html, because that's what github sends in content-type header.
You can use third party sites which will serve files with appropriate content-type header, (example: https://rawgit.com/socib/Leaflet.TimeDimension/master/dist/leaflet.timedimension.min.js ).
In the future, try to do more research before posting here, otherwise a lot of people are going to downvote your questions, and even insult you.
A simple Google search for the differences between html and javascript may be a good start. The first step would be to remove those doctype lines. They mean nothing in Javascript. Just like the word granola has no meaning in Japanese. Different languages.
However, looking at your code, I don't see any DOCTYPE text in your javascript. In order to really debug this, you're going to want to open your webpage (html) in a browser (I recommend Chrome) and press F12 to open the developer tools. Go to the console and trace the error back through all of the files to find the origin.
In order to check and make sure that you're trying to pull javascript files and not html, take all the src urls you're using and paste them in a browser. If you land on a webpage, that url will serve up html, not javascript like you want. If you get a wall of text, you're probably referencing it correctly.
Correct: https://api.mapbox.com/mapbox.js/v3.0.1/mapbox.js
Incorrect: https://github.com/socib/Leaflet.TimeDimension/blob/master/dist/leaflet.timedimension.min.js
Hopefully this helps before this question gets deleted or put on hold. Also notice that people are going to downvote me for actually answering and trying to help.
You can't directly reference code stored in a github repo like you're trying to.
The URLs you're listing aren't javascript files; they're github webpages. That's why they contain HTML doctypes and code you don't recognize -- it's the github website code.
You can get the URL for the actual javascript files by clicking the "raw" button at the top of any of those pages (after selecting a specific individual file -- the urls you gave were for directories, not individual files.) For example:
This is an HTML file: https://github.com/socib/Leaflet.TimeDimension/blob/master/dist/leaflet.timedimension.min.js
This is the raw javascript:
https://raw.githubusercontent.com/socib/Leaflet.TimeDimension/master/dist/leaflet.timedimension.min.js
(That said, I don't believe it's a good idea to treat github like a CDN; usually you would use that purely as a repository and host the actual files in use elsewhere.)
Can't parse any data from a txt file (not a csv for a reason) when it's uploaded to a server because all the newline characters a apparently gone. d3.js parser that I'm using parseRows does not work properly without them.
On a localserver everything seems to be fine.
d3.text('fileName.txt', 'text/plain', function(fileContent) {
console.log(/\n/.test(fileContent));
});
[localserver]: true
[onlineserver]: false
Using free hosting on Hostinger, Apache server according to Wappalyzer. Don't know much about it.
Tried different encodings. No luck.
Update:
I downloaded the txt back from the server and opened it in Sublime Text. No newline characters in it. The exact local copy is fine.
Solved by avoiding: Decided to save some time and nerve and uploaded my txts to Dropbox. In case someone has same problems, here is a little trick to get direct links to Dropbox files http://techapple.net/2014/04/trick-obtain-direct-download-links-dropbox-files-dropbox-direct-link-maker-tool-cloudlinker/
Also solved by berserking: Changing the extension of the file (to csv for example) also helps, lol
Your server is probably trying to sanitize the strings it receives from the UI in order to prevent things like cross-site attacks.
Trying to escape the string you send to the server with encodeUri(str) and if you need to decodeUri(decodedStr)
On my dev site the javascript for maps in the Venue section and the jQuery for the Nav scroll and scroll to top all work fine. http://yogadham.4pixels.co.uk
Upload all the same files to the actual server it's going to sit on and no javascript/jquery works!
http://yogadham.co.uk/xxindex.html
All links are to root so no problem there. I've checked permissions on the .js files. Is this a server issue? Both are Linux. Has anyone had similar issues?
Short Answer: Use Binary mode instead of Ascii mode when transferring files between Windows and Linux via FTP
Long Answer
It seems to be re-encoding your file (index.html) into a single line, probably upon the FTP upload and therefore the comments are causing section5 to break the JavaScript
//remove all comments (temporarily), and confirm if the website works
Edit: The FTP transfer is the issue: Reference
If you are transferring files from Windows to a Unix based server,
Ascii mode will strip out the CR (carriage return) characters found at
the end of each line. You may notice that the file you uploaded is
smaller than your local file. This is completely normal and is
nothing to worry about.
In your case, the CR's are causing the file to break.
Files are not the same. Take a look to the HTML generated by both. In production you don't have CR (carriage return) neither LF (line feed) characters :
https://www.diffchecker.com/pks371y6
First the environment: the client is a mobile Safari on iPhone, the server consists of a Tomcat 5.5 fronted by IIS.
I have a piece of javascript code that sends a single parameter to the server and gets back some response:
var url = "/abc/ABCServlet";
var paramsString = "name=SomeName"
xmlhttpobj = getXmlHttpObject(); //Browser specific object returned
xmlhttpobj.onreadystatechange = callbackFunction;
xmlhttpobj.open("GET", url + "?" + paramsString, true);
xmlhttpobj.send(null);
This works fine when the iPhone language/locale is EN/US; but when the locale/language is changed to Japanese the query parameter received by the server becomes "SomeName#" without the quotes. Somehow a # is getting appended at the end.
Any clues why?
Hopefully, all you need to do is add a meta tag to the top of your HTML page that specifies the correct character set (e.g. <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />) and match whatever encoding your datafiles are expecting.
If that doesn't work, ensure that you are using the same character encoding (preferably UTF-8) throughout your application. Your server-side scripts and any files that include text strings you will be adding directly to the response stream should be saved with that single encoding. It's a good idea to have your servers send a "Content-Type" HTTP header of the same encoding if possible (e.g. "text/html; charset=utf-8"). And you should ensure that the mobile safari page that's doing the displaying has the right Content-Type meta tag.
Japanese developers have a nasty habit of storing files in EUC or ISO-2022-JP, both of which often force the browser to use different fonts faces on some browsers and can seriously break your page if the browser is expecting a Roman charset. The good news is that if you're forced to use one of the Japanese encodings, that encoding will typically display right for most English text. It's the extended characters you need to look out for.
Now I may be wrong, but I THOUGHT that loading these files via AJAX was not a problem (I think the browser remaps the character data according to the character set for every text file it loads), but as you start mixing document encodings in a single file (and especially in your document body), bad things can happen. Maybe mobile safari requires the same encoding for both HTML files and AJAX files. I hope not. That would be ugly.
I would like to compress the CSS and JS files on my server to minimise load times, problem.
My hosting is with Streamline.net (big mistake, never go there) who will not activate mod_gzip and mod_deflate due to security issues.
Does anyone have another way to compress these types of files (and image files too if poss) without going the way of mod_gzip and mod_deflate.
Answers would be hugely welcome.
Yes, the answer is Minification.
Obviously, it will not compress as much as gzip or deflate. But it helps, and it is very easy to do with the right tools.
You can run your files through a script which would gzip them for you and add appropriate expiration headers.
Either set up an URL rewrite, or rewrite the URLs manually:
<script src="js/somescript.js"></script>
becomes
<script src="compress.php?somescript.js"></script>
and in compress.php, you can do something like
<?php
$file = 'js/' . basename($_SERVER['QUERY_STRING']);
if (file_exists($file)) {
header ('Last-Modified: ' . date('r',filemtime($file));
header ('Content-Type: text/javascript'); // otherwise PHP sends text/html, which could confuse browsers
ob_start('ob_gzhandler');
readfile($file);
} else {
header('HTTP/1.1 404 Not Found');
}
Obviously this can be extended to also provide HTTP caching, and/or on-the-fly minification, further speeding up your visitors' browsing.
Instead of getting mod_gzip to gzip your CSS and JavaScript files dynamically, you can gzip them yourself, then upload them.
This does introduce another step before you upload CSS and JavaScript, but it works, and maybe even saves a tiny bit of server processing time for each request compared to mod_gzip.
On Mac OS X, gzipping a file on the command line is as easy as, e.g.:
gzip -c styles.css > styles-gzip.css
Make sure these files get served with the right content-type header though.
Just as a sidenote: Compressing images would not be beneficial if these are already saved in a compressed format with the maximum compression that still looks good to the user.
Most programming languages support some data or file compression formats like ZLIB or GZIP. So you could use a programming language to compress your files with one of these formats.