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.
Related
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?
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.
Perhaps I'm over thinking this but I don't seem to be able to find a simple, trivial way to edit a file inline on a webpage.
I need to allow users to edit files stored on the system (linux router). One page per file is totally acceptable to me.
This page would load the content of a text file in a text area, where at the bottom a Save button saves the content of the text into the file.
That's all. No security needed, no multi user, no login what so ever.
All the inline editor I can find out there are rich-text or WYSIWYG which I don't need and they actually might mess up the file content with unwanted tags.
Can anybody please point me in the right direction on how to implement such an editor? No ajax or funky things needed really, just a text area and a save button.
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.
I would like my Web page
http://www.gmarks.org/math_in_e-mail.txt
on my Apache 2.2.14 server to display correctly in all browsers on all platforms (or something approaching this). I have included the line
AddDefaultCharset utf-8
in the appropriate .htaccess file. I find, however, that on my own machine, running Ubuntu 10.04, the page displays exactly as I would like only in the Google Chrome browser. Problems in other browsers: in Opera the last two lines do not display, in Firefox the subscripted aleph’s are too small, in rekonq the last two lines display incorrectly with various Fraktur characters repeated and others not displayed, in Midori the Opera and Firefox problems both occur, in Arora the Firefox and rekonq problems both occur, in Epiphany the Opera problem occurs.
Is there something else I could put in my .htaccess file, or some other configuration I might set up, to get that Web page to display correctly everywhere? I suppose I must rely on the font set each user has installed on his or her computer (obviously it defeats the purpose of the Web page to use something like GIF images). I find the differences among the browsers strange: does each browser include its own set of fonts in some configuration file, or do they access some directory containing fonts for the entire computer? (And is the answer to the last question OS-dependent?)
Further questions: would I do better to change the line in my .htaccess file to
AddCharset UTF-8 .txt
and is there a way I can make the .txt file display by default with an increased font size?
A browser will not know the text is UTF-8 encoded unless the text starts with a UTF-8 BOM (assuming the browser even looks for that) or the HTTP Content-Type header specifies UTF-8 as the Charset, ie: Content-Type: text/plain; charset=utf-8. If AddCharset tells Apache to generate that attribute for .txt files, then great.
There is no way to specify a font for a .txt file by itself. You have to use HTML for that. To specify a font for a .txt file, you would have to write a server-side script that outputs an HTML wrapper around the .txt file content and then sets the HTTP Content-Type header to specify text/html instead of text/plain as the data type.