Edgewall Software

Ticket #2981 (closed defect: worksforme)

Opened 3 years ago

Last modified 17 months ago

unable to upload files which filename is non-english characters

Reported by: anonymous Owned by: cboos
Priority: normal Milestone:
Component: general Version: devel
Severity: normal Keywords: attachment unicode windows
Cc:

Description

With 0.10dev, while attaching a filename in asian-characters. Attachment function is broken. for example, 中文.txt became %E4%B8%AD%E6%96%87.txt and attachment link were unable to locate this file.

Attachments

Change History

  Changed 3 years ago by cboos

  • keywords attachment unicode added
  • owner changed from jonas to cboos
  • milestone set to 0.10

While trying out with european accented characters on Windows, I also had some issues, but different ones. I've fixed them in r3103.

Can you test if this works for asian characters too?

  Changed 3 years ago by anonymous

  • status changed from new to closed
  • resolution set to fixed

thanks, r3103 is now working with asian filenames.

  Changed 3 years ago by bitneer@…

  • keywords windows added
  • status changed from closed to reopened
  • resolution fixed deleted

attachement problem

  • Trac 0.10dev(revision 3416) on Windows XP
  • korean filename: example) 한글.txt

error message

Traceback (most recent call last):
  File "C:\Python23\Lib\site-packages\trac\web\main.py", line 314, in dispatch_request
    dispatcher.dispatch(req)
  File "C:\Python23\Lib\site-packages\trac\web\main.py", line 163, in dispatch
    if not req.path_info or req.path_info == '/':
  File "C:\Python23\Lib\site-packages\trac\web\api.py", line 193, in <lambda>
    path_info = property(fget=lambda self: self.environ.get('PATH_INFO', '').decode('utf-8'),
UnicodeDecodeError: 'utf8' codec can't decode byte 0xa2 in position 31: unexpected code byte

  Changed 3 years ago by mgood

The byte 0xa2 is not in the example filename you mentioned. I've tested the example filename on different Trac setups and it works fine. I also tested a filename with the character for 0xa2 "¢", which works fine as well. What web server are you using, and which Trac frontend (FastCGI, mod_python, CGI)? It looks like it must be encoding the PATH_INFO variable incorrectly.

  Changed 3 years ago by bitneer@…

I'm using

  • Apache 2.0.58 for Windows
  • CGI for Trac frontend

  Changed 3 years ago by mgood

  • milestone changed from 0.10 to 0.11

I can't reproduce this with the current information. Postponing until after the 0.10 release. This could get bumped up to 0.10.1 once we have that milestone.

  Changed 2 years ago by cboos

  • status changed from reopened to closed
  • resolution set to duplicate
  • milestone 0.11 deleted

I think it's the same issue as #3663.

follow-up: ↓ 9   Changed 21 months ago by Blackhex

  • status changed from closed to reopened
  • resolution duplicate deleted

I think that problem is in getting filename of uploaded file from request. I'm trying to upload files within ScreenshotsPlugin? using this:

file = req.args['file']
filename = file.filename

The filename object is then of type str and should be of type unicode, should't it?

in reply to: ↑ 8 ; follow-up: ↓ 11   Changed 21 months ago by eblot

Replying to Blackhex:

I think that problem is in getting filename of uploaded file from request. I'm trying to upload files within ScreenshotsPlugin? using this:

Which file/version are you refering to?

  Changed 21 months ago by nkantrowitz

I traced the error to trac.web.api.Request._parse_args, and it affects both 0.10-stable and trunk. In short, non-file arguments (i.e. most of them) are decoded as UTF8 text there, but filenames are left alone. These should be decoded as well.

in reply to: ↑ 9   Changed 21 months ago by anonymous

Replying to eblot:

Which file/version are you refering to?

I'm working with 0.10.3 but coderanger said me that code handling argskey?.filename is not changed in trunk since 0.10.3.

  Changed 17 months ago by eblot

  • status changed from reopened to closed
  • resolution set to worksforme

I can't reproduce this issue with the latest trunk, using tracd on a Mac OS 10.4.10. I tried with the same machine as the client (OmniWeb/WebKit), as well as with a virtualized Linux/Ubuntu 7.04 (Firefox 2.0.0.3), using the proposed korean 한글.txt and chinese(?) 中文.txt filenames.

Add/Change #2981 (unable to upload files which filename is non-english characters)

Author



Change Properties
<Author field>
Action
as closed
Next status will be 'reopened'
to The owner will change from cboos. Next status will be 'closed'
 
Note: See TracTickets for help on using tickets.