Hello, I'm trying to store strings with certain unicode characters that don't convert to ascii in the ZODB. Specifically, as a file object and as properties of that file object. I get the following errors (from a script): *Error Type: AttributeError* *Error Value: 'unicode' object has no attribute 'seek'* and *Error Type: UnicodeEncodeError* *Error Value: 'ascii' codec can't encode character u'\u201c' in position 0: ordinal not in range(128)* Is there a way to work around this? or do I need to use a relational DB to store the data? I'm on Zope 2.9.7 Thanks, Thibaud
On 14.12.2008 1:13 Uhr, Thibaud Morel l'Horset wrote:
Hello,
I'm trying to store strings with certain unicode characters that don't convert to ascii in the ZODB. Specifically, as a file object and as properties of that file object. I get the following errors (from a script):
*Error Type: AttributeError* *Error Value: 'unicode' object has no attribute 'seek'*
First we need a full traceback. Second, it does not make sense to persistent file objects within the ZODB. Objects must be pickleable. -aj
Hey AJ, Thanks. Full traceback below. Regarding storing files, I meant the File Zope Object, as added by the following API call: newFolder.manage_addFile(id,title=title, content_type="text/plain", file=content). Exception Type AttributeError Exception Value 'unicode' object has no attribute 'seek' Traceback (innermost last): - Module ZPublisher.Publish, line 115, in publish - Module ZPublisher.mapply, line 88, in mapply - Module ZPublisher.Publish, line 41, in call_object - Module Shared.DC.Scripts.Bindings, line 311, in __call__ - Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec - Module Products.PythonScripts.PythonScript, line 326, in _exec - Module None, line 17, in updateWireFeed *<PythonScript at /GallopStaging/gallopWire/updateWireFeed>* *Line 17* - Module Shared.DC.Scripts.Bindings, line 311, in __call__ - Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec - Module Products.PythonScripts.PythonScript, line 326, in _exec - Module None, line 20, in createWireItem *<PythonScript at /GallopStaging/gallopWire/createWireItem>* *Line 20* - Module OFS.Image, line 62, in manage_addFile - Module OFS.Image, line 468, in manage_upload - Module OFS.Image, line 504, in _read_data AttributeError: 'unicode' object has no attribute 'seek' Thanks, Thibaud On Sun, Dec 14, 2008 at 2:19 AM, Andreas Jung <lists@zopyx.com> wrote:
On 14.12.2008 1:13 Uhr, Thibaud Morel l'Horset wrote:
Hello,
I'm trying to store strings with certain unicode characters that don't convert to ascii in the ZODB. Specifically, as a file object and as properties of that file object. I get the following errors (from a script):
*Error Type: AttributeError* *Error Value: 'unicode' object has no attribute 'seek'*
First we need a full traceback. Second, it does not make sense to persistent file objects within the ZODB. Objects must be pickleable.
-aj
On 14.12.2008 15:44 Uhr, Thibaud Morel l'Horset wrote:
Hey AJ,
Thanks. Full traceback below. Regarding storing files, I meant the File Zope Object, as added by the following API call: newFolder.manage_addFile(id,title=title, content_type="text/plain", file=content).
'file' must be an open file object and not a string with the binary content. -aj
Andreas Jung wrote at 2008-12-14 16:00 +0100:
On 14.12.2008 15:44 Uhr, Thibaud Morel l'Horset wrote:
Hey AJ,
Thanks. Full traceback below. Regarding storing files, I meant the File Zope Object, as added by the following API call: newFolder.manage_addFile(id,title=title, content_type="text/plain", file=content).
'file' must be an open file object and not a string with the binary content.
Almost: "file" is either a file like object or an "str" but not "unicode". @Thibaud: encode your unicode to a byte sequence ("str") using an adequate encoding (e.g. 'utf-8'). You should then also indicate the chosen charset in "content_type", e.g. "content_type='text/plain; charset=utf-8'". -- Dieter
Hi Dieter, That makes a lot of sense, thanks. Once I encode the strings in utf-8 there are no issues. That's a great tip about setting the content_type charset correctly. The way I was handling this so far was to specify it in the header of the page that was displaying the text: <span tal:content="nocall:python:request.response.setHeader('Content-Type','text/html; charset=UTF-8')" tal:omit-tag=""></span> But setting the content type is a lot cleaner, so I'll be doing that from now on. Thanks! Thibaud Also, in case anyone googles this... by default Zope renders content with a On Mon, Dec 15, 2008 at 2:56 PM, Dieter Maurer <dieter@handshake.de> wrote:
Andreas Jung wrote at 2008-12-14 16:00 +0100:
On 14.12.2008 15:44 Uhr, Thibaud Morel l'Horset wrote:
Hey AJ,
Thanks. Full traceback below. Regarding storing files, I meant the File Zope Object, as added by the following API call: newFolder.manage_addFile(id,title=title, content_type="text/plain", file=content).
'file' must be an open file object and not a string with the binary content.
Almost: "file" is either a file like object or an "str" but not "unicode".
@Thibaud: encode your unicode to a byte sequence ("str") using an adequate encoding (e.g. 'utf-8').
You should then also indicate the chosen charset in "content_type", e.g. "content_type='text/plain; charset=utf-8'".
-- Dieter
One more thing... as far as I can tell there is still a need to set the header through a nocall if try to display your file content as part of a larger page that is generated with out of the box Page Templates or DTML methods. So the call that I pasted below should help if anyone else ever runs into this... - Thibaud On Mon, Dec 15, 2008 at 3:52 PM, Thibaud Morel l'Horset <teebes@gmail.com>wrote:
Hi Dieter,
That makes a lot of sense, thanks. Once I encode the strings in utf-8 there are no issues.
That's a great tip about setting the content_type charset correctly. The way I was handling this so far was to specify it in the header of the page that was displaying the text: <span tal:content="nocall:python:request.response.setHeader('Content-Type','text/html; charset=UTF-8')" tal:omit-tag=""></span>
But setting the content type is a lot cleaner, so I'll be doing that from now on.
Thanks!
Thibaud
Also, in case anyone googles this... by default Zope renders content with a
On Mon, Dec 15, 2008 at 2:56 PM, Dieter Maurer <dieter@handshake.de>wrote:
Andreas Jung wrote at 2008-12-14 16:00 +0100:
On 14.12.2008 15:44 Uhr, Thibaud Morel l'Horset wrote:
Hey AJ,
Thanks. Full traceback below. Regarding storing files, I meant the File Zope Object, as added by the following API call: newFolder.manage_addFile(id,title=title, content_type="text/plain", file=content).
'file' must be an open file object and not a string with the binary content.
Almost: "file" is either a file like object or an "str" but not "unicode".
@Thibaud: encode your unicode to a byte sequence ("str") using an adequate encoding (e.g. 'utf-8').
You should then also indicate the chosen charset in "content_type", e.g. "content_type='text/plain; charset=utf-8'".
-- Dieter
Thibaud Morel l'Horset wrote at 2008-12-15 23:59 -0500:
One more thing... as far as I can tell there is still a need to set the header through a nocall if try to display your file content as part of a larger page that is generated with out of the box Page Templates or DTML methods.
The "index_html" method will set the "Content-Type" header automatically. This method is called when the object is visited (directly) from the web (i.e. is activated by "ZPublisher"). If you use the file content inside a larger page, then you would not use "index_html" and the larger page needs to set the "Content-Type" header itself. -- Dieter
I've been doing some googling and haven't found anything exactly what I'm looking for... Therefore, some input would be welcome. I want to search the data.fs file and modify existing part of a URLS from /zope/zope.pcgi/intranet/ to :8080/intranet/ Such that If I have a URL like test.domain.com/zope/zope.pcgi/intranet/test.html will become test.domain.com:8080/intranet/test.html ------------------------------------------------------------------------ Canada's Fan S/F Convention http://tcon.ca ------------------------------------------------------------------------ Stephen Christian(schrist@vex.net) _ Member of: www.vex.com/~schrist (_'-/-_ _ |_ _ _ DWIN,Polaris 22 Canada's B5 Information Pages: ._)( (-'|_)| )(-'| ). <*> www.cdnb5.ca | President of TCON
On Mon, Dec 15, 2008 at 03:52:35PM -0500, Thibaud Morel l'Horset wrote:
That's a great tip about setting the content_type charset correctly. The way I was handling this so far was to specify it in the header of the page that was displaying the text: <span tal:content="nocall:python:request.response.setHeader('Content-Type','text/html; charset=UTF-8')" tal:omit-tag=""></span>
On a stylistic tangent: combining "nocall" with "python" doesn't make any sense, and I don't believe it has any effect. Nocall's purpose is to prevent implicitly calling the object traversed at the end of a *path* expression. Also, don't use tal:content when you don't actually want to insert the result of the expression. The most common idiom I've seen when calling something purely for side effects is to abuse tal:define: <span tal:define="dummy python:request.response.setHeader(...)" tal:omit-tag="" /> Or, better, put the define in a tag that actually serves a purpose and you can leave out the omit-tag as well: <head tal:define="dummy python:..."> ... </head> -- Paul Winkler http://www.slinkp.com
participants (5)
-
Andreas Jung -
Dieter Maurer -
Paul Winkler -
Stephen Christian -
Thibaud Morel l'Horset