If a binary file uploaded using JSP, the binary data may contain some bytes that have special meaning to some network devices and will cause problems when passing through these devices, if I upload a file like a image, do I need to encode the file with Base64 or some other encodings?
If you are using form in jsp i.e
<form enctype="multipart/form-data">
Then no need of encoding.It will be send to server as Multipart file.
And it depends on your other technique what are you using to upload your file.
There is no need to encode the file. When you send data using some network protocol for example TCP the data is enclosed into protocol envelope. The envelope fields may be used by network hardware for example fields like IP address could be analyzed. But you data payload is not analyzed and therefore could not have any special meaning to routers, gateways etc.
Related
I need to write REST resource that should receive a file and save it to the disk.
The files will be sent from jersey client.
For now, I see two options:
1. Using multipart
2. Just reading the inputstream as a string and saving it to a file.
What are the pros of using multipart? is it related to file size? or anything else?
Thanks
If you use Jersey server side, using multipart you gain
disk buffering (surely you don't want to retain huge files in memory)
automatic base64/binary stream conversion
If you choose the String option these benefits are unavailable.
See also my answer to the question JAX-RS Accept Images as input, there is a sample implementation of the multipart option
I am using a java library (edtftpj) to FTP a file from a web app hosted of a tomcat server to an MVS system.
The FTP transfer mode is ASCII and transfer is done using FTP streams. The data from a String variable is stored into an MVS dataset.
The problem is all the ampersand characters get converted to & . I have tried various escape characters including \& , ^& and X'50' (hex value), but none of it helped.
Anyone has any idea how to escape the ampersands please?
Nothing in the FTP protocol would cause this encoding behavior.
Representing & as & is an XML based escaping representation. Other systems might use the same scheme, but as a standard, this is an XML standard encoding.
Something in the reading of the data and writing of the data thinks it should be escaping this information and is doing the encoding.
If anything on the MVS system is using Java it is probably communicating via SOAP with some other connector, which implies XML, which could be causing the escape sequence to be happening.
Either way, the FTP protocol itself part is not part of the problem, ASCII transfer should only encode things like line endings, & is already a valid ASCII character and would not be affected. It is the MVS system that is doing this escaping if anything.
Binary transfer is preferred in almost every case, since it doesn't do any interpretation or encoding of the raw bytes.
Using FTP in ASCII-mode to/from a MVS (z/OS) will always perform code page conversions (i.e ASCII <-> EBCDIC) for the data connection. Thus it's very important to setup the connection with the appropriate parameters depending on dataset type and page codes. Example:
site SBD=(IBM-037,ISO8859-1)
site TRAck
site RECfm=FB
site LRECL=80
site PRImary=5
site SECondary=5
site BLKsize=6233
site Directory=50
As alternative, use BINARY mode and manually perform the conversions with some of the standard tools or libraries on the receiving end.
Ref links:
1. Preset commands to tackle codepage problem.
2. Coverting ASCII to EBCDIC via FTP on MVS Host.
3. Transferring Files to and from MVS.
4. FTP code page conversion.
5. FTP File Transfer Protocol and Z/OS (pdf).
Does anyone have an example of how to send both binary (image) and text-based data in a single servlet response? An example is returning an image and image-map all generated on the server. I was also not able to find a mixed-mode mime type to use to be able to perform this operation.
Thoughts?
Browser support for multipart responses is still pretty dicey (read here). But if you are planning to parse the response on the client side yourself there are some pretty good examples out there. The mime-type you are looking for is multipart/mixed.
You can use Data URI to embed binary objects into generated HTML.
E.g.
<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUAAAAFCAYAAACNbyblAAAAHElEQVQI12P4/8/w38GIAXDIBKE0DHxgljNBAAO9TXL0Y4OHwAAAABJRU5ErkJggg==" alt="Red dot">
See also: https://serverfault.com/questions/241218/why-do-http-servers-not-send-a-single-file-back-when-possible#241224
This is not how HTTP and HTML work. A first request is made to load HTML code. This HTML code contains <img src="..."/> tags, which point to the URL of the image. A second request is then made by the browser to load the image. You can't download the HTML and the image in a single request.
Many WAP browsers supports multi-part responses, but I don't think "regular" browsers do.
Also see Browser support of multipart responses
I need to send X number of files to my servlet from an applet, which is the best way to do this?
And I need to send before the files, a java object populated.
I need to do it all in a single connection.
I'll upload my applet 3 ~ 10mb to my servlet.
I currently use FileInput together with the OutputStream and BufferedOutputStream to send a file, causing the buffer size is 8K.
First time I'll try to zip all the files to upload a zip file to the servlet, but I know it's not a good solution.
In the Applet side, send it as a normal multipart/form-data request by either URLConnection or HttpClient. In the Servlet side, use either HttpServletRequest#getParts() or Commons FileUpload to extract the parts from the request. This way the applet and servlet are not tight coupled to each other, but just reuseable on different servers (e.g. PHP) and/or clients (e.g. a simple HTML page).
Whether or not to zip the individual files into a single zip file is a decision you'd need to make yourself based on coding and performance impact.
I am trying to send an email with Java, I am using apache commons email library.
I cannot achieve to send an email with a body as HTML and an attachment as PDF (or any file type)
If I use EmailAttachment() and add it to an HtmlEmail object, my mail looks like with two attachment. First one is for HTML, second is for PDF.
Is there any way to do that?
Thank you very much!
It sounds like relatively normal behaviour for a message that's being sent as both text and HTML, and/or a mail client (at the receiving end) that prefers text emails. I suspect that this is due to the behaviour of the client, which you won't be able to change (but on the plus side all HTML emails would appear like this).
The thing is, an HTML email (with a textual component) really is a multipart message, with the HTML content as one of the "extra" parts. All you're actually sending in the email from the server side is a bunch of text, and it's up to the receiving mail client to decide how to display it. In that respect, it is not wrong for the client to display your HTML as an attachment - just like it is not wrong for a smart client to infer that the HTML isn't a "real" attachment and activate some kind of toggle between text and HTML (rather than displaying it as an attachment).
If you're convinced that the client would normally treat HTML in this smart way, then:
You'll have to mention which client you're using to check, because this isn't really an issue with the sending per se; and
You might want to take a look at the raw source of email that "works", and your email that doesn't, in order to determine what the critical differences are that trigger the different rendering modes. Depending on the client software, this could be just about anything - but I'd pay particular attention to part MIME types and charsets.
I tried apache commons mail v1.2 instead of 1.1.
It works!?
Andrej, by the way many thanks for your kindly help.