I tried to download the file with the name "Test~123.xml" but when it downloaded it is removing the '~' tidle sign and replaced it with a hyphen sign like "Test_123.xml"
I had used encoding in my code but still, when using google chrome it was replaced. while firefox Mozilla working properly it downloads the file with tidle sign.
Please let me know if any tool or Js file is available for the above issue.
Related
I have filename in Cyrillic which can be downloaded in Chrome using same name and extension when I try to download them in Edge I get them converted in UTF8 without extension.
I have a WordPress site hosted with BlueHost. When I FTP on to the server, edit a WordPress theme file and re-upload, I get a white screen with the following error
Parse error: syntax error, unexpected '}' in
/home/challey3/public_html/wp-content/themes/challengers/page-invoice-payment.php
on line 1
The code is being downloaded directly to my hard drive and edited using PhpStorm, I've noticed then when I open the file in PhpStorm there is an additional blank line between each line of code, whereas the additional lines are not present when editing through Notepad.
The changes to the code were adding a jQuery snippet to the HTML and no modifications were made to the PHP itself. Undoing adding the snippet and re-uploading have the same effect, however, if I do a Git revert and re-upload the problem is resolved.
The only thing I can think is that the file is being encoded differently through PhpStorm/Windows and uploading it back to the server is somehow breaking things. The server is running Ubuntu.
PhpStorm does not modify the file during transfer (upload or download).. so it must be server-side (FTP) setting.
As per my knowledge it's about line ending used in that file + specific FTP server config.
My assumption (based on personal experience working with 2 such already "broken" sites + info from other users who faced the same) is that during upload FTP server reacts on CR (used as line ending symbol -- CRLF is what Windows uses) and tries to "fix" it by replacing it by LF.
The FTP server may simply be doing it wrong -- instead of replacing whole CRLF it just does it on CR only.. so you may simply ending up with LFLF (2 line endings in Unix style -- 2nd one makes that extra empty line).
If I'm correct -- try converting that file in IDE to use Unix style LF as line separators first (either via Status Bar (next to encoding) or File | Line Separators).
In any case: here is the ticket in PhpStorm's Issue Tracker -- maybe one day they can offer some better solution: https://youtrack.jetbrains.com/issue/WI-9103 -- watch it (star/vote/comment) to get notified on any progress.
This question is being asked as part of the CKEditor forum apparently now hosted on stackoverflow. I am treating this entry as a forum question. I hope it will appear in the correct place on the stackoverflow site. Please advise if it should be redirected.
I am using the filebrowserImageUploadUrl config setting in a ckeditor instance.
In Firefox or Chrome, when I click on the "Upload" tab to view images on the local device, select one, and click "Send it to Server," the value transferred to the server by ckeditor is simply the file name and extension. The url saved and returned is correct, and all works fine.
In IE11 (and earlier?) and the new MS Edge, the filename sent to the server is the full path name stripped of all "\" separators. So, for example, the file on a Windows PC named "C:\Users\username\Pictures\imagename.jpg" is sent as "C:UsersusernamePicturesimagename.jpg".
I verified this by simply returning the string "upload.FileName" in the ckeditor dialog callback, where "upload" is the first parameter in the transmitted transaction and is declared on the server in C# as a HttpPostedFileWrapper. The returned value in Firefox and Chrome are the filename.ext, while in IE and Edge, it was the stripped full path name described above.
Any ideas on why this might be the case? Is there a known process/protocol for detecting this difference and dealing with it?
I forgot to mention that I am using ckeditor 4.5.3 (latest as of this writing). The problem also occurs in release of 4.5.1 (earlier development).
The file name parameter sent to the server by ckeditor's upload (using various browsers for an MVC 5 website in Visual Studio 2015) turns out to be (1) only the filename.ext in Firefox, but (2) the full and correct file name in IE, including the "\" path separators.
So this is not a ckeditor issue. It is instead a choice in browser security settings and/or defaults. I am not sure what the IE default is (full path in my IE is disabled when I launch it directly, but is enabled when IE is used as the browser launched in Visual Studio). So, obviously, the file name has to be parsed out of the path on the server side if and when the full path is provided.
Here are the two operative lines of C# MVC code that solved the problem (surrounded by some write's). The controller does not assume what's coming. If only the filename.ext is transmitted, that's what ends up as the ImageName. If the full path, it parses it down to the filename.ext.
public ActionResult ControllerName(HttpPostedFileWrapper upload, string CKEditor, string CKEditorFuncNum, string langCode)
{
. . .
System.Diagnostics.Debug.WriteLine(upload.FileName);
string ImageName = upload.FileName;
System.Diagnostics.Debug.WriteLine(ImageName);
ImageName = System.IO.Path.GetFileName(ImageName);
System.Diagnostics.Debug.WriteLine(ImageName);
. . .
}
Using the writeline code, I was able to confirm the received value (either filename only or full path) and that the parse worked when needed but did not change the value when only the filename.ext was transmitted.
I hope this learning will be useful to others. Sorry for the false alert.
So for a while now almost every file I open (html/css/php) has two line-breaks instead of just one. I attached a screenshot of my Notepad++ where you can see what is happening. If I open these files in Notepad they show like they should. However Notepad++/Netbeans/Sublime all leave me hanging. Any ideas?
http://snag.gy/6aLrI.jpg
There are 3 types of line terminators for text files:
Carriage return (0x0D) + line-feed (0x0A) for DOS/Windows text files.
Only line-feed (LF) for UNIX text files.
Only carriage return (CR) for MAC text files (prior OS X).
See also Wikipedia article about newline.
The preferred line terminator type on UNIX web servers is LF only, but most text files for web sites are edited on Windows. Therefore all FTP clients have the option to transfer text files either as ASCII or as binary.
Option ASCII means the FTP client inserts CR before each LF in file on downloading a text file from server. And each CR before LF is removed on uploading a text file to the server. So a text file stored on UNIX web server with just LF is converted on download to DOS/Windows and converted back on upload to UNIX. The binary transfer mode results in downloading/uploading the files without any modification by the FTP client.
In your screenshot I see in status bar at bottom Macintosh which is an indication that the file is handled as a MAC text file. The reason is most likely that on server the *.php files are stored already with DOS/Windows line terminators (CR+LF) and on download nevertheless the ASCII transfer mode is used resulting in text files having CR+CR+LF. The text editors now do not know how to correct handle those text files - as MAC files with an invalid LF or as DOS files with an invalid CR. Your text editors interpret the files as MAC files with invalid LF and therefore a newline for first CR and another one for CR+LF.
Solutions:
Select binary transfer mode in your FTP client to download/upload the DOS/Windows text files without any further modification by FTP client, or
search for \r\r\n on downloaded files and replace all occurrences with \r\n to get finally DOS/Windows text files on local disc and UNIX files on web server after upload.
I am creating an online picture storage system that renames images using a 7 character alphanumeric code. These codes are then used in URLs. I would like to be able to double-click on these codes and copy them from a URL within Chrome's URL bar. I am finding that certain characters (- and ~, to name a few) cause double-click to only highlight part of the code.
Is there a list of characters that double-click will not include in its grouping?
Is this an OS or browser specific list?
I would like for my system to use the greatest variety of (URL safe) characters, while still allowing double click to work.
This is entirely browser specific. In IE, _ is "unsafe", while - is "safe". In Chrome, _ is "safe", - is "unsafe". In firefox both are "unsafe". I don't think browsers have any documentation on this. For open-source browsers you can look at the source to see which are save. I'd only use alphanumeric characters to be sure.