Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 1 year ago.
Improve this question
I'm interested in an online application like the tool that comes with XCode, that shows the keys and values as rows, in an editable manner and handles xml plists (I don't care if it handles binary ones as well).
So, I was wondering the exact same thing, and when I saw this question and its answer, I said "Screw it, I'm making one!" And so I did. Two days later, here's my answer to you:
http://tustin2121.github.io/jsPlistor/
jsPListor (version 1 as of Aug 8th, 2013) will allow you to paste in the contents of an xml plist into it (via the Import button) and edit it with drag and drop and the like. When you're done, hit Export and it will package it all up into a valid plist for you to copy and paste back into the file.
There's still some bugs and glaring vacancies (like the Data Editing Dialog), but it functions. Future versions will attempt to allow saving via html5 download, and loading of files into data rows.
Feel free to examine, contribute, and submit bugs at the github repo: https://github.com/tustin2121/jsPlistor
I have resigned myself to the fact that there probably isn't one I will ever find. What I have found, however, is that JSON format and text PList format are very similar, and there are plenty of JSON editors available online and for windows and mac both. It may not be suitable for your needs, but it suited my needs just fine. By using nothing more than a couple of find & replaces in Notepad you can get 90% of the way to a plist file. The only big issue is semicolons vs. commas.
If you're working on a small enough file, that could be done manually. With larger files, a simple utility app to convert JSON to PList files would probably be pretty simple to whip up if you've got the urge.
Again, this all applies only to text formatted plist files. Most plist editors on mac at least can save a plist in text format.
There's Plistinator - its a native C++/Qt app for Mac, Windows and Linux desktop. So not an online tool, but it is at least portable and runs cross-platform (in case that is what the request for a web-based editor was about).
I'm not sure if the JS version handles binary files (Plistinator does). If you have a Mac you could edit them via the JS editor if you convert binary to XML via
plutil -convert xml myfile.plist
Note that will over-write myfile.plist with the XML version, which may not represent all the same information that the binary version can.
Full-disclosure: I am the author of Plistinator and the $12.99 goes to pay for my ramen & rent.
I don't think there are any plist editors online, at least not as functional as Plist Editor with Xcode.
You could use an online XML-editor, like Xmlia2.0, and code it yourself.
Why would you ever want an online tool for editing XML-files when you've got Plist Editor from xcode?
I wrote one once back in the day (for the old non-XML plist files). The structure is very regular, so it's not hard to create something that looks and acts more or less like the XCode plist editor.
I don't know off-hand of any online XML editors, but they must exist. Given a DTD-savvy XML editor, you ought to be able to edit plist files pretty easily.
Any web app that accepts .txt documents will edit plists just fine. Likewise for .xml
Related
My default file format is RTF because I mostly use Word 2013 to write diary entries. I thought RTF would be a format that should be readable by most computers for years to come. Can the same be said about the native Word DOCX format? I was thinking of switching to DOCX as my native format because it gets rid of “[Compatibility Mode]” warnings in the title bar and taskbar and the files are smaller. Maybe there are other advantages too.
I imagine TXT files would be the most universal file format for a diary, but I use basic formatting and tables in my entries. I worry that 20 years in the future I'll be importing my diary in whatever word processor exists then and I won't be able to read them.
Your worry is quite well-founded, and actually has a name: digital rot. It applies to file formats, but just as much to storage media and other things. My Master's thesis is now inaccessible to me because I only have it on floppy disk, and also because the programming language I used is no longer available.
On the other hand, IF I really needed access to it, I probably could (buying a floppy drive off eBay, finding an emulator for the ancient computer it was created for, finding the programming language, and reading the data are likely all still doable today).
As for your specific question: RTF may not be your best choice, because it, too, is a proprietary format with many different, and sometimes incompatible, flavors - and on top of that, it is outdated and no longer supported.
My personal favorite format for this type of storage is either TXT if formatting does not matter, HTML if formatting does matter, and PDF if HTML's formatting is not enough.
TXT is likely going to be with us for a very long time - probably for at least your and my lifetime. There just is too much software source code written in it for it to go away.
HTML is also going to be with us for a very long time, although incompatibilities will develop as older features are being dropped.
PDF is a proprietary format and could disappear, although the installed base means that it probably will remain readable for decades. The main advantage of PDF is that it makes it easy to print to paper - or, with the appropriate printer driver, print to whatever file format will take its place.
DOCX is likely going to be Microsoft's last Word file format, and will be around at least as long as Microsoft offers word.
Bottom line: your concern is justified, but in the end, you do have a number of options.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
So I recently changed jobs and I brought a bunch of files with me off my OS X 10.7 system. I had way too many files than could fit on the external drive I had, so I had tried dragging select files onto the drive, which gave me eventual repeated errors, so instead I used:
tar -zcvf whatever.tar.gz my_files
and then dragged the gzipped tarball onto the drive and that worked just fine. Now however, on my new Mavericks 10.9 system, I just tried to open a rich text file (that I'd created in Text Edit on 10.7) and I get the error:
'The document "_lab_notebook_2.rtf" could not be opened.'
I called Apple about this and they claimed that gzip was adding "the command line" to the metadata of the file (I assume the rich text file - though I could be wrong) and that metadata chunk is incompatible with Text Edit in Mavericks. They said that they have a request in with the gzip developers to address this issue (by stripping out the added metadata at some point along the way). Eventually, they say once that is updated, it will be in a new system update.
In the meantime, I'm stuck with a file that Text Edit can't open. I can open the file in other text editors, but I really would rather use Apple's Text Edit, hence this post. I tried opening a copy of the file with Rezilla and I can see the metadata in coded form, but nothing's jumping out at me as the offending data. I even tried removing each resource 1 by 1 and trying to open the file after each removal, but it still would not open.
Does anyone have any hints as to how to strip out whatever it is that gzip added? Am I even working from the correct starting point? They said that the data was added during the zip-up of the file, and I no longer have access to the original. Should I be working with the .tar.gz file or the .rtf file that was contained there-in?
Thanks,
Rob
The file you are trying to open, _lab_notebook_2.rtf might not be the file. (Are you sure it doesn't have a dot before the underscore, i.e. ._lab_notebook_2.rtf?) It may be the resource fork of the actual file, where the actual file would be named lab_notebook_2.rtf.
I don't know who you talked to at Apple, but gzip doesn't add anything to anything. It is simply a lossless compression and decompression utility. They certainly haven't contacted me about it (I am one of the gzip developers). Please look up my contact information, e.g on zlib.net, and copy that email to me. Thanks.
tar on the other hand may not be preserving all of the information that was on the original file system, or storing resource forks as ._ files, depending on what you asked it to do. It would have been better if you had used the Finder File:Compress operation, which preserves all of that information. (Or on the command line, the ditto utility with the options noted in its man page to duplicate what Finder does.)
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I am working on a project that will involve file upload to a server. I am interested in understanding what kinds of files virus writers currently tend to target. I am aware of the following threads:
How would you programmatically test a file for viruses ?
ensuring uploaded files are safe
How can I determine a file’s true extension/type programatically?
Server side virus scanning
But am interested in general in finding out about common attack vectors.
All of them. There aren't any "safe" file types when a JPG image can infect you with a virus and you can even trick the browser to execute JavaScript in any file no matter its declared type.
But the biggest and most widespread danger doesn't even involve uploaded files - ANY text that is entered by users and displayed on your page is a potential vector of Cross-Site-Scripting attacks.
I ran an "upload file" form for a little while and a few things I found:
All sorts of PHP scripts (shells, redirects, various "owned by $LAMER", you name it)
I think I had a few browser exploits (.html, .jpgs)
A bunch of files with the wrong extensions (ie, PHP scripts with the extension .rar, hoping that the server's mime-type guesser did the wrong thing)
Zip files full of all of the above
Anyway, those are just a few things I found. Hope they are helpful.
.exe and .scr are most common filetypes. Also, there are "tricks" with double extensions like readme.txt.scr or readme.doc.exe
exe is probably the most common
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
Businesses Analyst from my team keeps sending us the updated Requirements documents often and I end up hunting the recent changes by comparing the old version. Is their a good way of comparing the Word documents?
Note: We have the track changes option ON, but now the documents looks like a blood bath, complicating it much more :(
Use this option in Word 2003:
Tools | Compare and Merge Documents
Or this in Word 2007:
Review | Compare
It prompts you for a file with which to compare the file you're editing.
I use TortoiseMerge with the xdocdiff plugin to compare Word, Excel, PowerPoint and PDF versioned files
If you have Beyond Compare, you can diff two word documents with the help of some rules that you have to download from the developer's site and plugin. It'll then give you a text-only (without formatting) view (with some word format-gibberish that you can ignore. The differences will be highlighted and easy to find.
I made a note on how to do it here. It talks about Excel but there is a rule for Word in the same place.
If you don't have Beyond Compare... buy it! Highly recommended.. I'd struggle without it.
Codejacked covers three different methods on how to compare word documents.
You're using the wrong tools. Through the course of my last major project, we managed to convince the entire team to move to a Wiki scheme. Not only did it make tracking changes faster and easier, but it helped organize the information better. Rather than having to keep track of arbitrary indexes in a large text document, hyperlinks were available between documents.
This meant that the documents could naturally flow from high-level to specifics. Implementation of such specs was incredibly easy in comparison to Word docs. Also, the fact that the docs were in a central location ensured that no one was still working from an out of date copy they saved to their hard drive.
I know there can be some internal resistance to moving in new directions. But if you can convince your colleagues that they should be forward thinking and always challenging themselves, they'll give it a shot and become true believers in no time flat. :-)
Near the "track changes" stuff there is also an option to compare documents, I believe.
Attorneys use programs such as Comparewrite and DeltaView as we are comparing documents daily. We call it "blacklining" a document because the differences show up in bold underline for additions and black strike-through for deletions.
Open any of the documents and use the Review>Compare tab.
I don't know how to compare the files individually, since they are binary, but how about making a program that talks to MS Word, copying the contents of the files to a pure-text file? Then you could compare the plain-text files.
If the formatting is basic, one option is to use a tool that dumps the doc to a plain text file, and then use diff as you would on any other.
Versionate might do the trick.
The document comparison features in Word 2003 are extremely poor, and often results in the user removing parts of documents they did not want too
The only rational choice is to use other software. There are a multitude of text comparing software in the marketplace, but to do this within Word, the simplest answer is to upgrade to Word 2007 or later versions
From Word version 2007 the ribbon command "Review" and "Compare" are easy to find, and operate reasonably obviously. And they have a nice clear layout of merged changes, and the before and after docs
The small cost of the upgrade will be well worth considering the time you will waste in 2003 compare, and the potential damage to your documents it could cause
Any suggestions by others that you can use the compare features in 2003 is mischievous, and has not well thought through given the long term consequences of parts of your documents being silently deleted
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
If you have two versions of the same report (.rpt) and you want to establish what the exact differences are, what is the best way to go about this? I've seen some commercial tools to do this, but I'm not too interested in forking out cash for something that should be relatively straight forward. Can I hook into the Crystal API and simply list all of the properties of every field or something? Please someone tell me that there's an Open Source project somewhere that does this... #:-)
#Kogus, wouldn't diffing the outputs as text hide any formatting differences?
#ladoucep, I don't seem to be able to export the report without data.
Can I hook into the Crystal API and
simply list all of the properties of
every field or something? Please
someone tell me that there's an Open
Source project somewhere that does
this... #:-)
There is in fact, such an API. I wrote a VB6 application to do just what you asked and more. I think I even migrated it to VB.Net. As it was for my own use, I didn't spend much time making it 'polished'. I've been intending to release it, but I haven't had the time...
Another approach that I've used in the past is to create an Access application to help manage large, report-development projects. One of it's many features includes the ability to extract the tables that are used by the report, and the SQL statements used by its Commands and SQL Expressions. It's intent is to give one a global perspective of which reports use which tables. I probably still have it somewhere...
** edit 1 **
BusinessObjects Enterprise XI (R?) has a feature named 'Meta Manager'. It will periodically examine the contents of the Repository and save the results to a database. It uses the Report-Application Service (RAS) to generate the meta data. It's an additional, 5-figure license, of course.
** edit 2 **
Consider using PowerShell to do the work: PsCrystal.
One helpful technique is to output both versions of the report to plain text, then diff those outputs.
You could write something using the crystal report component to describe every property of the report, like you described. Then you could output that to text, and diff those. I'm not aware of any open source tool that does it for you, but it would not be terribly hard to write it.
#question in the post:
Diffing the outputs would only show formatting changes if the relative positions had changed. For example, if i had this:
before:
First name, last name, addresss
after:
Last Name, First Name, Address
Then that would show up as a difference.
But if I had just bumped the address column over a few pixels, or changed it from plain text to bold, then you are right, that would not show up.
One technique I have used to great effect in the past is to print out reports from both versions based on the same data. I then take the first page from each version, lay one on top of the other (it is important not to mix them up) and hold them up to a window. It is generally quite easy to see any differences, and these differences can be manually annotated with a suitable writing instrument such as a pencil. Repeat for each page in the report.
Admittedly, for large reports this can be quite time consuming and error prone, but these limitataions can be overcome with patience and care.