Creating MAC CSVs in windows for testing - windows

I have a PHP program that uploads a CSV file and reads through it.
We only have PC's in the office, but sometimes our clients have Macs. Is there a way to create a Mac CSV in Windows for testing purposes?

Since CSV is a text-based format, the only difference between a Mac and a PC CSV file would be the line endings. Windows typically use CR+LF for line endings, whereas Mac OS X and *nix typically use just LF.
It really depends on the software that will be reading the CSV file. There is a good chance that a well-designed reader (on either Mac or PC) would gracefully / automatically handle either LF or CR+LF endings. However, there is (naturally) no shortage of not-so-well-written software out there. Do you have more info on what software they will be using?
If you want to explicitly create a CSV file in "Mac-friendly" mode, you could open the file in binary mode, and explicitly use "\n" (rather than "\r\n") at the end of each line. This will likely open / view fine on most apps within windows. (Though Notepad won't like it, Excel probably will.) This file should then be "optimized" for Mac output. Though, as above, it might not matter at all, if the client's software is "tolerant" of different endings.
EDIT: Prior to OS X, Mac used CR (\r) for line endings. For OS X, they switched to LF (\n). Most likely, your clients are using OS X, so \n is likely the ending you want.

There's no such thing as a 'Mac CSV'. A CSV is a document with values that are comma-separated (that's why they call it a "Coma-Separated Values file). In other words, it's plain text.
The only edge cases I could see are line endings (which is likely to be \n but could also be \r) and encoding (which is very likely to be UTF-8 but could somehow be Mac Roman) if your clients use non-ASCII characters.

Related

How do I check out files with special characters in the file name (e.g. ?) on Windows in Git while keeping the original name in the repo?

I have a bunch of files in a Git repo which works okay on macOS and Linux, but will fail on Windows because the file name contains ?
I was wondering how do I configure Git only on my local Windows machine so that I can check it out and have it auto convert the file to something Windows will allow and push it back preserving the file name?
The best way to do this is to use the Windows Subsystem for Linux. It has a fully POSIX-compatible file system and is fully capable of storing arbitrary byte values (with the normal exceptions).
It is almost certainly not going to be possible to use Git for Windows on a native Windows file system, although if you happened to format an external hard disk as UDF (which, I believe, requires the full disk, not just a partition, to be formatted that way on Windows), then you could probably check it out there. UDF is at least capable of handling these characters on Unix.

What is line endings in Sublime Text? [duplicate]

This question already has answers here:
Difference between \n and \r?
(11 answers)
Closed 6 years ago.
I am new to Sublime Text and I saw there's a setting of Line Endings which allows me to change it to 'windows','UNIX' and 'mac os'. Can someone explain to me?
Thx~
Before there was computers, people wrote text on a typewriters.
To get to a new line on your paper, you need to feed a line (scroll the paper one line up) and do a carriage return (put the pointer on the beginning of the line).
New technologies adapted these techniques. On UNIX-like systems, native editors will not set a carriage-return (CR) flag, but only a line-feed (LF). In Windows, line endings are denoted with both CR and LF. The Mac OS setting refers to the classic Mac OS (pre-OS X), which used only CR. Modern Mac OS (OS X and macOS) uses LF, as it is UNIX-based. The Wikipedia article on Newline has a good overview.
If you are working with Windows only, leave it as it is. If you need to swap files between UNIX-like and Windows systems, set the editor on Windows to use UTF-8 encoding for files and line_ending to LF only. That way you will circumvent many problems with encoding on linux/mac machines.

newlines when displayed in Windows

open OUT, ">output.txt";
print OUT "Hello\nWorld";
When I run the above perl code in a Unix system and then transfer output.txt to Windows and open it in Notepad it shows as:
HelloWorld
What do I need to do to get the newlines displaying properly in Windows?
Text file line endings are platform-specific. If you're creating a file intended for the Windows platform then you should use
open OUT, '>:crlf', 'output.txt' or die $!;
Then you can just
print OUT "Hello\nworld!\n";
as normal
The :crlf PerlIO layer is the default for Perl executables built for Windows, so you don't need to add it to code that will create files for its intended platform. For portable software you can check the host system by examining the built-in variable $^O
Windows uses carriage-return + linefeed:
print OUT "Hello\r\nWorld";
I wrote the File::Edit::Portable module that eliminates these problems. Although you can use it to write (along with many other things), you only need the read() functionality in this case.
Install the module, and at the top of your script, add:
use File::Edit::Portable;
When opening/reading the file, you can just do:
my $rw = File::Edit::Portable->new;
my $fh = $rw->read('file.txt');
No matter what the line endings are or what platform you're on, it does all of the cross-platform work in the background so you don't have to. That way, you can open the file on any system, regardless of what line endings you've decided to use, and it just works.
Newline handling is editor specific (there are a number of answers that claim it is OS specific, but that is, in real life, not true in general). However, it is true that on DOSish systems, longstanding convention is to use CRLF to indicate EOL (see also Why is fwrite writing more than I tell it to?)
If you try to open this file in any other editor than Notepad, you will notice that the text is properly displayed on two lines, with an indicator in a status bar or some other place that the file is opened in Unix mode or LF mode.
Unless you intend your file solely for viewing with Notepad, you don't have anything to worry about. Every other tool on Windows will deal fine with it.
However, Notepad does expect a CRLF sequence to mark the end of each line. If you do want to cater for it, then you can just output "\r\n" as #kizeloo suggests. I do prefer to use output layers when they are necessary.
Note that if you try to view such a file using an editor that requires a single LF to signify EOL, you may see ^Ms or other characters denoting the CR.

How to set Emacs to use standard LF line breaks, rather than CR

I am very new to Emacs, using Aquamacs on a Mac running OS 10.10. I'm creating and editing files that end up on a BSD system, so they need to conform to *nix standards. Apparently, the files I'm creating have carriage return line feeds, which my supervisor is understandably getting annoyed with having to strip out. I don't understand why this is the case, because my understanding is that the Mac hasn't used CR line breaks since they moved to OS 10. How can I fix this? Obviously, I'm not looking for a solution that has to be implemented for each new buffer I open, but rather a solution that will be the default for all new buffers.

QtQuick 2 file size of download differ on windows

I wrote a small download script in the C++ part of my QtQuick2 app. This works just perfectly fine when I'm building the app for Mac OS 10.9.
For testing I download this file and when it's done I verify it against the given md5 check sum b3215c06647bc550406a9c8ccc378756
Only when I build the app on a windows PC the verification fails. On the second look I recognise that the size of the downloaded file differ with each downlaod, while the "size on disk" stays every time the same.
Do you have any idea what might trigger the strange behaviour in windows os?
Thanks in advance.
If it helps to solve the problem, I will show you my download script, but it's a pretty simple "read-all-write-to-file" script which runs every two seconds.
Could binary/text writing mode affects the result?
UPD: If you use QFile with QIODevice::Text it may behave differently depending on platform.
When reading, the end-of-line terminators are translated to '\n'. When writing, the end-of-line terminators are translated to the local encoding, for example '\r\n' for Win32.

Resources