Looks like the problem has persisted since 2012 based on users' agony.
I'm trying to spool CSV data into client Chrome browsers, which turn it into one long line, stripping all LF and CR characters.
Tried all combos: \n, \r\n, \\n - strips consistently regardless of content-type or content-disposition.
So it's more of a two-part question:
a) does anyone know how to prevent/trick Chrome browsers from doing this?
b) is there a way to break the record in CSV without using the ASCII(10) character
I'm streaming data from the application web server to clients. All browsers are fine saving CSV or loading the doc straight into Excel, except Chrome.
The only solution that finally worked was the generation of a chr(10)-delimited CSV file on the server and execution of the following JS expression upon pressing the "export" button:
location.href="http://$server_name/$CSV_name";
In such case, records rendered correctly and were loaded in Excel as expected. Any attempts to generate an inline or an attached document via manipulation of server headers or document types/extensions ended in '\n' (or '\r\n') stripping in Chrome, as opposed to other browsers.
Hope this helps.
Related
I have an Excel VBA Script that I originally wrote for Windows (where it works fine) and now had to port to Mac OS. I don't think that it matters but the script is calling cURL to get a JSON Response from a web API which is then parsed, edited and inserted into the spreadsheet.
Some of the fields in the parsed JSON contain special characters like Ä, Ü, Ö (German characters). The script can handle these just fine on Windows but on Mac instead of ÖÜÄ I get other symbols. This breaks the tool as it depends on some vlookup-functions where the values are written by hand (with the correct symbols).
I tried lots of googling but was not able to find anything.
One thing that might be interesting is that the code itself changes on Mac as well! I have some statements printed to the console and even the hardcoded strings that contain a special character are broken as soon as I open the script on a Mac.
The question is for Mac VBA. This is a pain. The only solution I have is to send the curl output to a file, then open that file with workbooks.opentext and Origin:=65001 and all the response is in cell A1, correctly encoded.
I have asked my own question on that, to see if any one has a more recent answer.
How to read UTF8 data output from cURL in popen/fread in VBA on Mac?
I'm having an issue in a .NET application where pages served by local IIS display random characters (mostly black diamonds with white question marks in them). This happens in Chrome, Firefox, and Edge. IE displays the pages correctly for some reason.
The same pages in production and in lower pre-prod environments work in all my browsers. This is strictly a local issue.
Here's what I've tried:
Deleted code and re-cloned (also tried switching branches)
Disabled all browser extensions
Ran in incognito mode
Rebooted (you never know)
Deleted temporary ASP.NET files
Looked for corrupt fonts on machine but didn't find any
Other Information:
Running IIS 10.0.17134.1
.NET MVC application with Knockout
I realize there are several other posts regarding black diamonds with question marks, but none of them seem to address my issue.
Please let me know if you need more information.
Thanks for your help!
You are in luck. The explicit purpose of � is to indicate that character encodings are being misused. When users see that, they'll know that we've messed up and lost some of their text data, and we'll know that, at one or more points, our processing and/or configuration is wrong.
(Fonts are not at issue [unless there as no font available to render �]. When there is no font available for a character, it's usually rendered as a white-filled rectangle.)
Character encoding fundamentals are simple: use a sufficient character set (say Unicode), pick an appropriate encoding (say UTF-8), encode text with it to obtain bytes, tell every program and person that gets the bytes that they represent text and which encoding is used. The encoding might be understood from a standard, convention, or specification.
Your editor does the actual encoding.
If the file is part of a project or similar system, a project file might store the intended encoding for all or each text file in the project. If your editor is an IDE, it should understand how the project does that.
Your compiler needs the know the encoding of each text file you give it. A project system would communicate what it knows.
HTML provides an optional way to communicate the encoding. Example: <meta charset="utf-8">. An HTML-aware editor should not allow this indicator to be different than the encoding it uses when saving the file. An HTML-aware editor might discover this indicator when opening the file and use the specified encoding to read the file.
HTTP uses another optional way: Content-Type response header. The web server emits this either statically or in conjunction with code that it runs, such as ASP.NET.
Web browsers use the HTTP way if given.
XHR (AJAX, etc) uses HTTP along with JavaScript processing. If needed the JavaScript processing should apply the HTTP and HTML rules, as appropriate. Note: If the content is JSON, the current RFC requires the encoding to be UTF-8.
No one or thing should have to guess.
Diagnostics
Which character encoding did you intend to use? This century, UTF-8 is so much the norm that if you choose to use a different one, you should have a good reason and document it (for others and your future self).
Compare the bytes in the file with the text you expect it to represent. Does it use the entended encoding? Use an editor or tool that shows bytes in hex.
As suggested by #snakecharmerb, what does the server send? Use a web browser's F12 network tab.
What does the HTTP response header say, if anything?
What does the HTML meta tag say, if anything?
What is the HTML doctype, if any?
When I create a document with MS Word and upload it to an html server it it correctly displayed when it is a windows server, but not when it is a linux server.
I tried this with both IE and Firefox.
The meta tag in the source says charset=windows-1252
Displaying the source code in the browser shows exactly the same source as I uploaded, so the server is not changing that. Nevertheless are characters like accented e displayed as silly characters when obtained from the linux server.
So somewhere in the tcp/http/??? records that the server sends to the browser makes the browser interpret the characters different from what is ment.
What could that be?
When you create a document in MS Word, there are a lot of characters that you can't see that are actually in the file, such as end of line markers, page breaks, etc. which you will not notice until after you upload the file to the server.
You should always use a plain text editor such as Notepad++, or even bluefish to create these files. Sometimes you can get MSWord to do the trick if you make sure to save the file as a web document(htm or html), but the special characters will usually begin to cause problems depending on your goal.
Since a while, when I open a plain text file with long lines, the lines will break.
See this example: https://oeis.org/A195665/a195665_4.txt
In Firebug I can see, that the text is in <pre> tags in an html structure.
To avoid the line breaks, I have to click on "View Page Source".
Is there any server side way to prevent that?
I do not think the browser is at fault. I believe it is the web server's job to serve it up differently. You should google how to do that for your particular web server.
This works in Firefox and Chrome:
view-source:http://oeis.org/A195665/a195665_4.txt
But not in IE. However, IE doesn't break the lines in the first place.
Background:
We have a web application where the user can export orders in csv-format. For users with Microsoft Excel installed it's the default program. They simply click 'Open' after the file is downloaded. Users mainly use Internet Explorer, Firefox and Chrome. No difference in behaviour.
The problem:
If the user just open the csv-file (from browser or explorer) the file is opened by Excel and data is loaded automagically. But sometimes rows are just missing. Gone. No exception, no message, nothing.
The data is there, if you open the file with notepad you'll see it.
(I suspect it has something to do with special chars, quotes, commas etc but I can't find a root cause for this)
How to make it work:
If you save the file to disk, open excel and selects File -> Open -> Format: Textfiles (*.prn, *.txt, *.csv, *.skv) -> Open excel will launch a import wizard and everything will work perfectly.
Is there anything I can do with the export-file to either force the Import Wizard or just tell Excel not to exclude our critical order information without warning?
I think I've found the cause of this. It seems to be due to regional settings as described in this post and sugesstions from superuser.com
I solved it by wrapping all fields except numbers with quotes and now it works just fine.
Make sure that you use a consistent delimiter scheme across all lines in the file. For example, check if you have both \n and \r\n sequences as line delimiters.