I have a EDI file ...i want to test it ....so when I open it it opens in an EXCEL file,....there is some data I want to change....
BGS~EGI~PG~265\TIA~5008~~~16796~GA\BGS~EGI~PG~360\TIA~5008~~~22827~GA\BGS~EGI~PG~528\TIA~5008~~~18304~GA\
TO
BGS~EGI~PG~265\TIA~5008~~~0~GA\BGS~EGI~PG~360\TIA~5008~~~0~GA\BGS~EGI~PG~528\TIA~5008~~~0~GA\
Can it be done on EXCEL and the changes reflect in the EDI sheet?If do that in EXCEL and save ....how to save it?I did that but did not know which format to Save....xlt/xls/ etc. I save it as .xlt format.Is that the correct way?
Further the cursers just goes hay way when i click on a cell. How to control the cell?
pLEASE HELP
ATorras is on the right path. EDI is sort of a text format. I'd call it more of a binary format. (There's also XML EDI, but that's not what you're dealing with here.)
Depending on the size of the file, you may run into line limits in some editors. Others may be adding line breaks that may or may not cause issues with some EDI translators.
You can have EDI files with binary delimiters (such as segment terminators). This is not common, and it doesn't look like the case with your test data.
The file extension only matters to the translator or other software that's trying to find/send the EDI file. Basically you don't want to change the original extension.
I don't remember what the standards are for Unicode, etc., so that may be a concern in some cases. You'll want to preserve whatever encoding the original file uses.
Short version: Most of the time you can get away with using Notepad, vi, etc. Sometimes you can't. If you have access to dedicated EDI tools for parsing/editing/translating, use those. Never use Excel or Word. Always make a backup of your original first. Verify that your trading partner is getting what you expect.
Related
I am looking to speed up the reading of a data file which has been converted from binary (it is my understanding that "binary" can mean a lot of different things - I do not know what type of binary file I have, just that it's a binary file) to plaintext. I looked into reading files quickly awhile ago, and was informed that reading/parsing a binary file is faster than text. So, I would like to parse/read the binary file (that was converted to plaintext) in an effort to speed up the program.
I'm using Matlab for this project (I have a Matlab "program" that needs the data in the file). I guess I need some information on the different "types" of binary, but I really want information on how to read/parse said binary file (I know what I'm looking for in plaintext, so I imagine I'll need to convert that to binary, search the file, then pull the result out into plaintext). The file is a logfile, if that helps in any way.
Thanks.
There are several issues in what you are asking -- however, you need to know the format of the file you are reading. If you can say "At position xx, I can expect to find data yy", that's what you need to know. In you question/comments you talk about searching for strings. You can also do it (much like a text file) "when I find xxxx in the file, give me the following data up to nth character, or up to the next yyyy".
You want to look at the documentation for fread. In the documentation there are snippets of code that will get you started, but as I (and others) said you need to know the format of your binary files. You can use a hex editor to ascertain some information if you are desperate, but what should be quicker is the documentation for the program that outputs these files.
Regarding different "binary files", well, there is least significant byte first or LSB last. You really don't need to know about that for this work. There are also other platform-dependent issues which I am almost certain you don't need to know about (unless you are moving the binary files from Mac to PC to unix machines). If you read to almost the bottom of the fread documentation, there is a section entitled "Reading Files Created on Other Systems" which talks about the issues and how to deal with them.
Another comment that I have to make, you say that "reading/parsing a binary file is faster than text". This is not true (or even if it is, odds are you won't notice the performance gain). In terms of development time, however, reading/parsing a textfile will save you huge amounts of time.
The simple way to store data in a binary file is to use the 'save' command.
If you load from a saved variable it should be significantly faster than if you load from a text file.
I have an app (written in D2010) which is similar to a text retrieval app... It has a list of questions, with their corresponding answers. Most answers are strictly text, but some answers have graphics, and formatting. My dilemma has to do with the formatted answer. The user should be able to copy this answer (formatting and graphics) in order to paste it into another app. I have tried using a Word OCX. This is a little problematic. User has to have word, it gives random errors when using inside a virtual machine, etc. I am now playing with using a built in browser component, and viewing the data as a PDF. This is nice and easy, but when I copy and paste it, I loose all formatting, and the graphic shows up as a large totally black box.
I can store the data in whatever format I choose. It is stored as a BLOB in a DB file. I write it to a temp file and then I call some type of viewing routine, so I have flexibility there. My issue is really, what viewer mechanism is simple to implement, and allows copying/pasting, while maintaining text formatting (bullets, indents, etc) and graphics.
Thanks,
GS
The TRichEdit (or any of TRichEdit descendants or similar classes) will allow the users to visualize text formatting and images, and when the content is copied, the RTF representation of the data will be copied into the clipboard.
When the clipboard data is pasted into a RTF compatible text editor (like Wordpad and Word), all the formatting, bullets and images are preserved.
I need to create a .xls file from the Array data programmatically in iPhone. How can this be done?
Maybe you're in trouble, maybe not. The "old" xls format is a binary one and I am not aware of any free libraries which are able to read or write to that format. If this one is required, you're propably out of luck.
If however a more recent format will do you're back in business, because you can use xml (objc wrappers for lib2xml are readily available). Wikipedia features a short overwiev of the format which you might want to check out: Excel file formats on Wikipedia
How do the applications transfer the copied strings into each other? Is this a clipboard usage? If so, how can i access the clipboard in a program?
Edit: I'm interested in Windows systems, I know a bit of C#, and C++.
Yes, cut-and-paste is usually done using the system-wide clipboard.
In both Windows Forms and WPF applications, there are (different) classes called 'Clipboard', which contain the stuff you need to access the system clipboard.
Basically, the clipboard allows you to put pretty much anything on to it, along with markers that say what format the data is in. You can put the same data on in lots of different formats. That's how, for example, you can cut and paste a part of a spreadsheet in Excel into Notepad - Excel has put the data onto the clipboard in both a native Excel format and a plain text format.
I am trying to deserialize an old file format that was serialized in Delphi, it uses binary seralization. I know nothing about the structure of the file except some very high level records that are in it.
What steps would you take to solve this problem? Any tools etc?
A good hexeditor, and use the gray matter to identify structures.
If you get a hint what kind of file it is, you can search for more specialized tools.
Running the unix/Linux "file" command can be good too (*) See Barry's comment below for how it works. It can be a quick check for common filetypes like DBF,ZIP etc hidden by using a different extension.
(*) there are 3rd party builds for windows, but they might lag in versions. If you can do it on a recent *nix distro, it is advised to do so.
The serialization process simply loops over all published properties and streams their value to a text file. If you do not know the exact classes that were streamed to the file you will have a very hard time deserializing the file. (if not impossible)
A good hex editor is first. If the file is read without buffering (eg read directly from a TFileStream) you could gain some information when using ProcMon from SysInternals; You can see exactly what data is read in what chunks and thus determine more quickly where the boundaries are between the structures you already identified.