Bug #75
Updated by Lionel Martin over 11 years ago
When uploading a file with the browser, the filename is not transcoded correctly sometimes.
The attached application package allows to reproduce the problem using the attached file.
Use a browser to go the bug_20120829.htm page of the application (http://localhost:1081/nv_app_BUG/bug_20120829.htm). This page displays 6 frames allowing to have all combinations of encoding regarding the page itself (ISO-8859-1 or UTF-8) and the encoding detection of the Nirva server (NV_FORM_ENCODING=AUTO, ISO-8859-1 or UTF-8). On the left, the frames are ISO-8859-1 encoded. On the right, they are UTF-8 encoded.
One frame has a text field, to check that Nirva server correctly handles transcoding for "normal" HTML fields.
When uploading the attached file Méditérannée.txt, we can see that the NV_FORM_ENCODING parameter does not affect the extracted name of the file by Nirva (stored in ORIGIN field of the Nirva FILE object). In ISO-8859-1 frames, it is always good. In UTF-8 frames, it is always wrong.
The field is always correctly handled by Nirva.
The problem has been verified on Linux 32bits, and Windows 32 and 64 bits.
The attached application package allows to reproduce the problem using the attached file.
Use a browser to go the bug_20120829.htm page of the application (http://localhost:1081/nv_app_BUG/bug_20120829.htm). This page displays 6 frames allowing to have all combinations of encoding regarding the page itself (ISO-8859-1 or UTF-8) and the encoding detection of the Nirva server (NV_FORM_ENCODING=AUTO, ISO-8859-1 or UTF-8). On the left, the frames are ISO-8859-1 encoded. On the right, they are UTF-8 encoded.
One frame has a text field, to check that Nirva server correctly handles transcoding for "normal" HTML fields.
When uploading the attached file Méditérannée.txt, we can see that the NV_FORM_ENCODING parameter does not affect the extracted name of the file by Nirva (stored in ORIGIN field of the Nirva FILE object). In ISO-8859-1 frames, it is always good. In UTF-8 frames, it is always wrong.
The field is always correctly handled by Nirva.
The problem has been verified on Linux 32bits, and Windows 32 and 64 bits.