Feature request #1022
delimited text layer plugin: robustness
Status: | Closed | ||
---|---|---|---|
Priority: | Low | ||
Assignee: | Magnus Homann | ||
Category: | C++ Plugins | ||
Pull Request or Patch supplied: | Resolution: | fixed | |
Easy fix?: | No | Copied to github as #: | 11082 |
Description
Hi,
It seems MS Office for OSX lives in the past: When you save a .csv spreadsheet it saves it using Mac OS9 newlines, i.e. \
not \
.
Using the QGIS 0.9.2rc1 Mac binaries the delimited text layer plugin fails to parse these files correctly, it seems to get the top line column names ok, but then considers all other data lines as more top line column names.
Using nedit under X11 (I hear BBedit and a tiny drag-n-drop app called ConvertNewlines* can do it too), we resaved the file in UNIX/OSX newline format (\
) and then it worked fine.
[*] http://lionel.kr.fh-niederrhein.de/~dalitz/data/software/macosx/#tools
It sure would be nice if the delimited text layer plugin could be modified to handle that case. It is a strange and magical thing to try and explain newlines to a Mac using biologist, and who knows when MS will get with the program.
Radim wrote a fgets() replacement for GRASS which will handle all UNIX, Mac OS9, and DOS newline styles, G_getl2():
http://trac.osgeo.org/grass/browser/grass/trunk/lib/gis/getl.c
thanks, Hamish
Associated revisions
fix #1022
git-svn-id: http://svn.osgeo.org/qgis/trunk/qgis@14448 c8812cc2-4d05-0410-92ff-de0c093fc19c
fix #1022
git-svn-id: http://svn.osgeo.org/qgis/trunk@14448 c8812cc2-4d05-0410-92ff-de0c093fc19c
History
#1 Updated by Magnus Homann almost 16 years ago
- Status changed from Open to In Progress
Is the newline just '\
', not '\
\
' ?
Trying to think of the downsiode with this approach...
#2 Updated by hamish - almost 16 years ago
Replying to [comment:2 homann]:
Is the newline just '\
', not '\
\
' ?
Yes, the MacOS9 newline is just '\
'.
Hamish
#3 Updated by Jürgen Fischer almost 14 years ago
- Resolution set to fixed
- Status changed from In Progress to Closed
fixed in 4afb7293 (SVN r14449)
#4 Updated by Magnus Homann almost 14 years ago
I have recollections of that the fix was not as simple as I first thought. Have you tested it with umlauts and utf-8?
Maybe it was me being lazy... :-)