uploadpolicy.java

[linux.rar] - 嵌入式linux开发教程

 * readme.txt file. With <I>ftpCreateDirectoryStructure</I> to false (or
 * default value), the readme.txt is uploaded in the postURL directory. If set
 * to true, the test/ folder is created in the postURL directory, and the
 * readme.txt is uploaded in this subfolder.<BR>
 * Note: in HTTP upload, the pathinfo and relpathinfo allows the server side
 * script to manage this directory structure. </td>
 * </tr>
 * <tr>
 * <td>ftpTransfertBinary</td>
 * <td><i>true</i><br>
 * since 4.1.0<br>
 * {@link wjhk.jupload2.policies.UploadPolicy}</td>
 * <td>This parameter allows to control whether the upload should be done in
 * binary or ascii mode. Default is to upload in binary mode.</td>
 * </tr>
 * <tr>
 * <td>ftpTransfertPassive</td>
 * <td><i>true</i><br>
 * since 4.1.0<br>
 * {@link wjhk.jupload2.policies.UploadPolicy}</td>
 * <td>This parameter allows to control whether the upload should be done in
 * FTP passive mode, or in active mode (where tehe FTP server opens a connexion
 * to the client, to do the upload). Default passive mode.</td>
 * </tr>
 * <tr>
 * <td>highQualityPreview</td>
 * <td>false<br>
 * <br>
 * {@link wjhk.jupload2.policies.DefaultUploadPolicy}</td>
 * <td>If this parameter is set to <i>true</i>, the applet will call the
 * BufferedImage.getScaledInstance(), instead of doing a basic scale
 * transformation. This consume more CPU: on a PII 500MHz, the full screen go
 * from around 5 seconds to between 12 and 20 seconds, for a picture created by
 * my EOS20D (8,5M pixels). The standard preview (above the file list) seem to
 * be displayed at the same speed, whatever is the value of this parameter. <br>
 * Note: when resizing is done before upload, the
 * BufferedImage.getScaledInstance() is always called, so that the uploaded
 * picture is of the best available quality. </td>
 * </tr>
 * <tr>
 * <td>lang</td>
 * <td>Navigator language <br>
 * <br>
 * {@link wjhk.jupload2.policies.DefaultUploadPolicy}</td>
 * <td>Should be something like <i>en</i>, <i>fr</i>... Currently only french
 * and english are known from the applet. If anyone want to add another language
 * ... Please translate the wjhk.jupload2.lang.lang_en, and send it back to
 * <mailto:[e-mail]">. </td>
 * </tr>
 * <tr>
 * <td>lookAndFeel <br>
 * since 2.5</td>
 * <td><i>empty</i><br>
 * <br>
 * {@link wjhk.jupload2.policies.DefaultUploadPolicy}</td>
 * <td>This allows to control the look &amp; feel of the applet. The authorized
 * values are:
 * <ul>
 * <li><i>empty</i>: uses the default look &amp; feel. This is the same as
 * java.
 * <li>java: uses the java default look &amp; feel. Same as <i>empty</i>.
 * <li>system: uses the current system look and feel. The call will be : <br>
 * UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
 * <li>Any valid String argument for UIManager.setLookAndFeel(String).
 * </ul>
 * </td>
 * </tr>
 * <tr>
 * <td>maxChunkSize<br>
 * Since 2.7.1</td>
 * <td>0<br>
 * <i>Long.MAX_VALUE</i><br>
 * <br>
 * {@link wjhk.jupload2.policies.DefaultUploadPolicy}</td>
 * <td>This parameters defines the maximum size of an upload.
 * <ul>
 * <li>If not set, or set to a value of 0 or less, the chunk mode is disabled.
 * That is: each file will be uploaded within being splitted in pieces.
 * <li>If set to a value of 1 or more, the upload size will be never be more
 * than maxChunkSize. A file bigger will be split in several part of
 * <i>maxChunkSize</i> size, then the last part will contain the remaining, and
 * will probably be smaller than <i>maxChunkSize</i>.
 * </ul>
 * <br>
 * <b>How to build the server part:</b> the server will have to 'guess' that
 * the file is splitted, and then it will have to reconstruct the uploaded file.
 * Here are the necessary informations:
 * <ul>
 * <li>When a file is chunked, the <i>jupart</i> and <i>jufinal</i> parameter
 * are given in the URL (get parameters). This identify a chunk upload. If these
 * parameters are not given, the file(s) is(are) uploaded in one piece.
 * <li><i>jupart</i> identify the part number: from 1 to N for a file being
 * plitted in N pieces. The N-1 chunks should be <i>maxChunkSize</i> bytes
 * long. The last one contains the remaining of the file.
 * <li><i>jufinal</i> is set to 0 for chunks from 1 to N-1. It is is set to 1
 * only for the last chunk (N, in this 'example').
 * <li>The uploaded filename is not modified when the upload is chunked.
 * Example: upload of the file <i>bigPicture.jpeg</i>, of 4,5 Mb, with chunk of
 * 2Mb. The upload is splitted in three chunk. Chunk 1 and 2 are 2Mb long. The
 * third one is 0,5Mb long. The uploaded filename for these three uploads is
 * <i>bigPicture.jpeg</i>. It's up to the server part to read the <i>jupart</i>
 * and <i>jufinal</i> get parameters, to understand that the upload is chunked.
 * <li><b>Important:</b> The server script <u>must</u> check the resulting
 * filesize. If not, the client can send a file of any size, and fill the server
 * hard drive.
 * <li>The wwwroot/pages/parseRequest.jsp is a java example of a server page
 * that can receive chunk upload. It stores each chunk is <i>filename.partN</i>
 * (where N is the chunk number), then construct the final file, by
 * concatenating all parts together.
 * </ul>
 * <b>Note: </b> If nbFilesPerRequest is different than 1, the applet will try
 * to upload the files until the sum of their content length is less than
 * maxChunkSize. The upload is triggered just before the sum of their content
 * length is bigger then maxChunkSize.<br>
 * If one file is bigger than <i>maxChunkSize</i>, all previous files are
 * uploaded (at once or not, depending on nbFilesPerRequest). Then the 'big'
 * file is uploaded alone, splitted in chunk. Then upload goes on, file by file
 * or not, depending on <i>nbFilesPerRequest</i>. </td>
 * </tr>
 * <tr>
 * <td>maxFileSize<br>
 * Since 2.7.1</td>
 * <td>0<br>
 * <i>Long.MAX_VALUE</i><br>
 * <br>
 * {@link wjhk.jupload2.policies.DefaultUploadPolicy}</td>
 * <td>This parameter identify the maximum size that an uploaded file may have.
 * It prevent the user to upload too big files. It is especially important when
 * chunk upload is activated (see below <i>maxChunkSize</i>).
 * <ul>
 * <li>If <i>maxChunkSize</i> is not set, negative or 0, <i>maxFileSize</i>
 * should be the maximum upload size of the server. In this case, it is useful
 * only to display a message when the user select a file that will be refused by
 * the server.
 * <li>If chunk upload is activated, this parameter becomes really important:
 * in this case the maximum file size of an uploaded file is ... the available
 * space on the server hard drive! (see below, <i>maxChunkSize</i>).
 * </ul>
 * </td>
 * </tr>
 * <tr>
 * <td>maxPicHeight</td>
 * <td>Since 3.3.0: Integer.MAX_VALUE<BR>
 * (was -1)<br>
 * <br>
 * {@link wjhk.jupload2.policies.PictureUploadPolicy}</td>
 * <td>This parameters allows the HTML page to control the maximum height for
 * pictures. If a picture is to be download, and its height is bigger, the
 * picture will be resized. The proportion between width and height of the
 * resized picture are the same as those of the original picture. If both
 * maxPicHeight and maxPicWidth are given, it can happen that the resized
 * picture has a height lesser than maxPicHeight, so that width is no more than
 * maxPicWidth. <br>
 * <b>Precisions:</b> <br>
 * If this parameter value is negative or 0, then no control is done on the
 * picture height. <br>
 * If the original picture is smaller than the maximum size, the picture is not
 * enlarged. <br>
 * If the picture is resized, its other characteristics are kept (number of
 * colors, ColorModel...). The picture format is ketp, if targetPictureFormat is
 * empty. If the picture format is a destructive (like jpeg), the maximum
 * available quality is choosed. <br>
 * <i>See also maxPicWidth, realMaxPicHeight</i> </td>
 * </tr>
 * <tr>
 * <td>maxPicWidth</td>
 * <td>Since 3.3.0: Integer.MAX_VALUE<BR>
 * (was -1)<br>
 * <br>
 * {@link wjhk.jupload2.policies.PictureUploadPolicy}</td>
 * <td>Same as maxPicHeight, but for the maximum width of the uploaded picture.
 * <br>
 * <i>See also maxPicHeight, realMaxPicWidth</i> </td>
 * </tr>
 * <tr>
 * <td>nbFilesPerRequest</td>
 * <td>-1 <br>
 * <br>
 * {@link wjhk.jupload2.policies.DefaultUploadPolicy}</td>
 * <td>This allows the control of the maximal number of files that are uploaded
 * in one HTTP upload to the server. <br>
 * If set to -1, there is no maximum. This means that all files are uploaded in
 * the same HTTP request. <br>
 * If set to 5, for instance, and there are 6 files to upload, there will be two
 * HTTP upload request to the server : 5 files in the first one, and that last
 * file in a second HTTP request. </td>
 * </tr>
 * <tr>
 * <td>pictureCompressionQuality</td>
 * <td><i>0.8</i><br>
 * since 3.1.0<br>
 * {@link wjhk.jupload2.policies.PictureUploadPolicy}</td>
 * <td>This parameter controls the picture compression quality, when writing
 * the picture file. 1 means high quality picture, but big files. 0 means poor
 * quality pictures, but small files. 0.8 is a good compromise for the web.<br>
 * It is different from the highQualityPreview, which controls the way picture
 * are resized in memory.<br>
 * This parameter is currently applied only to jpg (and jpeg) pictures.</td>
 * </tr>
 * <tr>
 * <td>pictureTransmitMetadata</td>
 * <td><i>false since 3.3.0<br>
 * (was true before)</i><br>
 * since 3.2.0<br>
 * {@link wjhk.jupload2.policies.PictureUploadPolicy}</td>
 * <td>This parameter controls whether the applet transmit metadata of the
 * original picture. This may prevent personal information to be thrown on the
 * net.<br>
 * Note 1: This parameter is especially important for picture coming from the
 * Canon EOS 20D, 30D and 40D: pictures shooted in portrait mode contain
 * metadata that are incompatible with Java 1.6.0_3! The colors of transformed
 * pictures become strange... <B>Since 3.3.0: default to false</B>, to avoid
 * this annonying (and currently not explained) problem.<br>
 * Note 2: <Caution> As of 3.2.0, this parameter blocks metadata only for
 * pictures that are updated by the applet. Metadata from picture transmitted
 * 'as is' are not removed. This is corrected in 3.3.0.</td>
 * </tr>
 * <tr>
 * <td>postURL</td>
 * <td>null since 1.9.2rc4, (was <i>Mandatory</i> before)<br>
 * <br>
 * {@link wjhk.jupload2.policies.DefaultUploadPolicy}</td>
 * <td>This parameter specifies the target URL toward which the files should be
 * uploaded. Since version 1.9.2rc4 this parameter is not mandatory anymore.
 * Instead, if omitted or a <i>relative</i> URL is given, the resulting URL is
 * constructed from the applet's DocumentBaseURL. This means, that if the applet
 * tag is dynamically constructed from a PHP script without specifying
 * <code>postURL</code>, the <i>same</i> same script receives the subsequent
 * POST request(s). If this URL may change during the applet execution time, you
 * can call the setProperty applet method from javascript, or create a new
 * UploadPolicy class and either :
 * <ul>
 * <li>Override the {@link wjhk.jupload2.policies.UploadPolicy#getPostURL()}
 * method, to make the postURL totaly dynamic.
 * <li>Override the
 * {@link wjhk.jupload2.policies.UploadPolicy#setPostURL(String)} method, to
 * modify the postURL on the fly, when it is changed.
 * <li>Override the
 * {@link wjhk.jupload2.policies.UploadPolicy#setProperty(String, String)}
 * method. The {@link wjhk.jupload2.policies.CoppermineUploadPolicy} changes the
 * postURL when the albumID property changes.
 * <li>Find another solution ...
 * </ul>
 * <u>Note 1:</u> in HTTP, the upload is done in the same user session, as the
 * applet uses the cookies from the navigator. This allows right management
 * during upload, on the server side.<br>
 * <u>Note 2:</u> FTP URL should looks like:
 * ftp://username:[e-mail]:21/directory<br>
 * <u>Note 3:</u> in FTP, you'll have to add the jakarta-commons-oro.jar and
 * jakarta-commons-net.jar jar files in the applet ARCHIVE tag attribute. See
 * the 'advanced_js_demo.html page for a sample. You'll have to put the two
 * files coming from the JUpload distribution in the same directory as the
 * wjhk.jupload.jar.</td>
 * </tr>
 * <tr>
 * <td>realMaxPicHeight</td>
 * <td>Since 3.3.0: Integer.MAX_VALUE<BR>
 * (was -1)<br>
 * <br>
 * {@link wjhk.jupload2.policies.PictureUploadPolicy}<br>
 * <i>Since v2.8.1</i></td>
 * <td>This parameters is about the same as maxPicHeight. It overrides it for
 * pictures that must be transformed (currentlty only when the picture is
 * rotated). <br>
 * The aim of this parameter, is to prevent the applet to resize picture, and
 * let the server do it: it will be much quicker. <br>
 * This allows you to:
 * <ul>
 * <li>Put a 'big' <i>maxPicHeight</i> (or don't provide the parameter in the
 * APPLET tag), and let the server resize the picture according to the real
 * maxPicHeight. The <i>maxPicHeight</i> will be used when the picture is not
 * tranformed by the user.
 * <li>Put this realMaxHeight to the real configured maxPicHeight. The applet
 * will then directly produce the final file, when it has to tranform the
 * picture (picture rotation, for instance).
 * </ul>
 * <br>
 * <i>See also maxPicHeight, realMaxPicWidth, maxChunkSize (to override any
 * server upload size limitation).</i> </td>
 * </tr>
 * <tr>
 * <td>realMaxPicWidth</td>
 * <td>Since 3.3.0: Integer.MAX_VALUE<BR>
 * (was -1)<br>
 * <br>
 * {@link wjhk.jupload2.policies.PictureUploadPolicy}<br>
 * <i>Since v2.8.1</i></td>
 * <td>Same as realMaxPicHeight, but for the maximum width of uploaded picture
 * that must be transformed. <br>