Sample data and required excel image:
Also, Read Time section as shown in file, and populate excel file with the data in a column with the header name Time as shown above. Likewise, read the message value as shown in the .asc file and populate in excel file by converting the numbers from hexadecimal to decimal in columns named Data1, Data2, Data3,…
If your '.asc' file consists of tab delimited ASCII text then Excel will allow you to import it into an Excel worksheet.
The following explainer comes from Microsoft's Office support site:
There are two ways to import data from a text file by using Microsoft
Excel: You can open the text file in Excel, or you can import the text
file as an external data range. To export data from Excel to a text
file, use the Save As command.
There are two commonly used text file formats:
Delimited text files (.txt), in which the TAB character (ASCII
character code 009) typically separates each field of text.
Comma separated values text files (.csv), in which the comma character
(,) typically separates each field of text.
You can change the separator character that is used in both delimited
and .csv text files. This may be necessary to make sure that the
import or export operation works the way that you want it to.
If neither of those methods work for you and your '.asc' was generated by MATLAB then you may be able to use MATLAB to export directly to an Excel worksheet. MATLAB has a function xlswrite that you can use to write directly to a Microsoft Excel spreadsheet.
Another option, if you're comfortable writing some VBA code in Excel, is to use the textscan function to parse your '.asc' file.
Related
When I try to use the COPY command with HEADER option and format text to export a table in postgreSQL, I get the following error:
COPY HEADER available only in CSV mode
I understand that we can use format CSV with a different delimiter than , to generate a different file format, but I am wondering why the use of HEADER with text format is prohibited?
The default text format of COPY is proprietary to PostgreSQL and not very useful for data exchange with other software. For example, a NULL value is represented as \N.
Since nobody saw a need for having header data in this format, it didn't get implemented.
Use the csv format for data exchange.
I have some dates in Text format and some other in Date format.
I tried so many things to reconvert them in proper format. DD/MM/YYYY
16/10/2022
05/12/2023
24/05/2023
I still cant figure out. They all looks in Date format but some are not. How i can re-format properly. There is sample of my dates.
https://docs.google.com/spreadsheets/d/1aNsoqXnpNkQs7LloFuHVObARqI2QEh5X8ClCu42ICyQ/edit?usp=sharing
How i can fix this?
Here's what happened :
you had a bunch of dates formatted as DD/MM/YYYY and pasted them and they were automatically parsed in the format MM/DD/YYYY leading some of them being recognized as proper dates (but not the ones you intend to have), and some of them being leaved as text.
To solve this you can copy paste the column in a text file, then import this file; when you import the data in excel, use the "text to columns" to choose the date format.
You can also change your locale date settings.
Last solution that does not involve creating a new file : copy paste your dates in a text file, add a ' in front of each line which ensures the cell content is not automatically interpreted, then parse the date from this text using the formula :
=date(right(H2,4),mid(H2,4,2),left(H2,2))
(if your text is in h2)
One last thing : some of your data in the left column is not in the correct format. You probably have a formatting problem / data quality problem in the source data you copy/pasted from.
save file in CSV or convert to csv
Open as text
Use the Text import wizard from paste
My nattable looks like the one below.
When I copy the cells and paste in excel the cells look distorted as below.
The line break is not captured properly in the process.
The bit of code referred for copying is the same as that in the Nattable example
Is this a bug and solved in the next versions or am I missing on something.
I would not say that this is a bug in NatTable. Pasting a line break into Excel inside a cell is not that simple. You can search for this topic and see the real issue. When you copy content from NatTable, the content includes the line breaks of your cell data. The paste operation in Excel takes those line breaks and interpretes them as new row and not new line inside a cell.
You can of course implement and register a custom CopyDataCommandHandler that performs special operations to replace a line breaks in NatTable content with something that Excel handles as line breaks inside a cell.
The solution as of now is as follows :-
In Excel if the content that is sent to the Clipboard is present in double quotes and the \n is included in the double quotes Excel interprets this as a single cell content and adds the line break in the cell
Alternatively since this is a table while copying content to the clipboard we can convert it to html tags appropriately and convert it to html format which excel reads and converts appropriately.
Refer below image
However while copying between cells from Nattable to Nattable this is taken care of.
My matlab code for dataimport is giving me different results for what appear to be similar text files as input. Input1 gives me a normal cell with all lines from the text file as entries in the cell which i can reference using {i}.
Input2 gives me a scalar data structure where all numeric entries in my text file are converted to the input.data structure. I want all files to be converted to regular cell entries and I do not understand why for some files they are converted to scalar data structures.
Code: input = importdata(strcat(direct,'\',filename));
Input1 example: Correctly working dataimport, with text file on the right
File link: https://drive.google.com/open?id=1aHK4xivqEqJEmaA8Dv8Y0uW5giG-Bbip
Input2 example: Incorrectly working data import, with text file on the right FIle link: https://drive.google.com/open?id=1nzUj_wR1bNXFcGaSLGva6uVsxrk-R5vA
UTSL!
I'm guessing you are using GNU Octave although you are writing "Matlab" as topic of your question.
In importdata.m around line 178, the code tries to automatically detect the delimiter for your data:
delim = regexpi (row, '[-+\d.e*ij ]+([^-+\de.ij])[-+\de*.ij ]','tokens', 'once');
If you run this against W40A0060; you get A as delimiter because there is basically a number before and after it.
If you run this against W39E0016; you get {} as delimiter(empty) because the E could be part of a number in scientific notation and is therefore excluded.
Solution:
you really should add the correct delimiter to the importdata call and not trust that it's magically detected.
And if you just want the lines in a cell, use
strsplit (fileread ("W39E0016_Input2.txt"), "\n")
Analysis
This looks indeed strange!
EDIT: The cause for this strange looking behaviour has been deciphered by #Andy (See his solution).
When you use all outputs of importdata() function you can see what happens when reading the data:
[dat1,del1,headerrows1]=importdata('Input1.txt')
[dat2,del2,headerrows2]=importdata('Input2.txt')
For your first file it recognizes 69 header riws and no delimiter:
del1 = []
headerrows1 = 69
while in your second file only two header rows and a comma , delimiter is recognized
del2 = ','
headerrows2 = 2
I can not find an obvious reason in your files causing this different interpretation of data.
Suggestion
Your data format is rather complex. It is not a simple table like produced from excel. It has multiple lines with a different number of fields per line and varying data types. importdata() is not designed for this type of data. I suggest to write a specific import function for this kind of file. Have a look at textread() for a first guess. You can use it to read the lines of the files as text and later interpret it with sscanf() or use strsplit() to split the line contents into fields.
I am exporting some Access tables to txt files and there are a lot of problems with the txt file. One of those problems being line breaks not visible in the txt file itself. If I copy a line with a line break into Notepad++ from Notepad, it'll break into 2 lines.
So I believe this may be a code format problem, but I can't find the proper one to resolve this. I'm currently exporting to the default Western European, but should I export tot UTF, Unicode, ASCII or something else?
When exporting from MS Access (or VB/VBA in general), make sure you're using vbCrLf constant (Carriage Return plus Line Feed) for line breaks. That constant corresponds to HEX values 0D 0A.
In Windows, it is a convention to use the above 2 characters together as line breaks, while in many other platforms, such as Unix/Linux/MacOS/etc. typically just 0A is used.
That brings up an issue: Notepad, the standard Windows text file viewer, cannot deal with 0A alone and does not treat such symbols as line breaks. More advanced editors, such as Notepad++ or UltraEdit, display such files correctly, though.
The CSV export function in Microsoft Office applications (Excel, Access) terminate a data row with CR+LF and write for a line break within a data value (multi-line string) just LF into the file. (I think just CR was written into the CSV file for a line break in older versions of Office before Office 2007.)
Most text editors detect those LF without CR (respectively CR without LF) and convert them to CR+LF on loading the CSV file which results on viewing of the CSV file in text editor in supposed wrong CSV lines as number of data values is not correct on data rows with data values containing a line break.
However, newline characters within a double quoted value in a CSV file are correct according to CSV specification as described in Wikipedia article about Comma-separated values.
But most applications with support on import from CSV file do not support CSV files with newline characters within a double quoted value and therefore some data values are imported wrong. Also regular expression replaces can't be done on a CSV file with newline characters within a data value because the number of separator character is not constant on all lines.
UltraEdit has for editing such CSV files with only LF (or CR) for a line break within a data value a special configuration setting. At Advanced - Configuration - File Handling - DOS/Unix/Mac Handling the option Never prompt to convert files to DOS format or Prompt to convert if file is not DOS format with clicking on button No if this prompt is displayed must be selected and additionally Only recognize DOS terminated lines (CR/LF) as new lines for editing must be enabled.
The CSV file with CR+LF for end of data row and only LF (or CR) for a line-break within a data value is loaded with those settings in UltraEdit with number of lines equal the number of data rows. And the line-feeds without carriage return (respectively the carriage returns without line-feed) in the CSV file are displayed as character in the lines with a small rectangle as no font has a glyph for a carriage return or line-feed defined because they are whitespace characters with no width. A Perl regular expression find searching for \r(?!\n)|\n(?<!\r) can be used now to find those line breaks within data values and replace them with something different like a space character or remove them.
Which character encoding (ASCII, ANSI, Unicode (UTF-16), UTF-8) to use on export depends on which characters can exist in string values. A Unicode encoding is necessary if string values can have also characters not included in local code page.