Hi,
I've managed to find and modify WAListenerEncoded so that it can process multibyte language - I've only tested it with Korean as UTF-8. During testing I found following problem.
When I use WAListener/WAListenerEncoded I cannot get FileLibrary registered image files correctly. I can get CSS file or script file correctly, but I cannot get image files.
It seems that when I use WAListener, the server sent the image file of the size of 16135 byte, but original file size is 10819 byte, and this might be the source of the problem. I cannot open wrong sized file even though I cut the size of the file to the original one.
Can anyone help me? Thanks in advance.
It appears that you're trying to convince Seaside to send UTF-8, right? I had the same problem during my time working with it. Then again, I didn't want complete texts but only the Euro currency sign. And and what I did was: I left my fingers off of WAListener and all those. Instead, I assembled the three bytes needed for a Euro sign myself by hand into a normal String and lo and behold, it looked right in the browser.
For Korean your approach is probably better, I guess. Mine was unsatisfying, too, because it assumed incoming text to be encoded in latin-15, but emitted texts in utf-8. Really not satisfying. I thought, the right approach might be to enhance the String class with an additional field for the encoding and give it some methods to transcode between them. By the way: the method asUtf8 (or something like that) does not work properly with the Euro sign.
For example, when you print this:
'Grüß Gott!' asUtf8
it looks awful, because the new string doesn't know it's UTF-8.
So, it appears that for Seaside to cope with Korean well, you might have to change more than Seaside only.
niko
2008/1/3, chunsj@embian.com chunsj@embian.com:
Hi,
I've managed to find and modify WAListenerEncoded so that it can process multibyte language - I've only tested it with Korean as UTF-8. During testing I found following problem.
When I use WAListener/WAListenerEncoded I cannot get FileLibrary registered image files correctly. I can get CSS file or script file correctly, but I cannot get image files.
It seems that when I use WAListener, the server sent the image file of the size of 16135 byte, but original file size is 10819 byte, and this might be the source of the problem. I cannot open wrong sized file even though I cut the size of the file to the original one.
Can anyone help me? Thanks in advance.
2008/1/3, chunsj@embian.com chunsj@embian.com:
Hi,
I've managed to find and modify WAListenerEncoded so that it can process multibyte language - I've only tested it with Korean as UTF-8. During testing I found following problem.
Korean as UTF-8 should not work on WAListenerEncoded. If it does then it's a bug in WAListenerEncoded. The reason for this is that Korean as UTF-8 violates the contract between the server adapter and you. The *Encoded* adapters give you Strings in Squeak encoding (well not quite in the case of CJK because that is not possible since Unicode does not have the concept of language tags) but in turn expect Strings in Squeak encoding. In the case of Korean this means WideStrings. UTF-8 Strings are ByteStrings and should therefore not work.
When I use WAListener/WAListenerEncoded I cannot get FileLibrary registered image files correctly. I can get CSS file or script file correctly, but I cannot get image files.
I don't think WAListenerEncoded can ever work for binary files. The problem is that due to it's streaming nature WAListenerEncoded compared to WAKomEncoded can never look at the response. This means it can never decide wehter is should do encoding (based on the mimetype), so it always does it. In the case of binary content this is clearly wrong. Your best option (as always) is to serve static files (images, CSS, javascript) with Apache or something similar.
It seems that when I use WAListener, the server sent the image file of the size of 16135 byte, but original file size is 10819 byte, and this might be the source of the problem. I cannot open wrong sized file even though I cut the size of the file to the original one.
WAListener should not do any encoding at all so images should work. But then again we don't know what code you changed so we can't really help you. It would help if you send us the image so we can test.
Cheers Philippe
It seems that when I use WAListener, the server sent the image file of the size of 16135 byte, but original file size is 10819 byte, and this might be the source of the problem. I cannot open wrong sized file even though I cut the size of the file to the original one.
WAListener should not do any encoding at all so images should work. But then again we don't know what code you changed so we can't really help you. It would help if you send us the image so we can test.
It's likely that your images' bytes are being UTF-8 encoded. If the bytes are uniform, you can expect a 50% increase in size (the low 128 bytes are passed as they are, the high 128 bytes are expanded to two bytes; (128+128*2)/256 = 1.5) and that's what you are seeing.
Paolo
2008/1/4, Paolo Bonzini bonzini@gnu.org:
It seems that when I use WAListener, the server sent the image file of the size of 16135 byte, but original file size is 10819 byte, and this might be the source of the problem. I cannot open wrong sized file even though I cut the size of the file to the original one.
WAListener should not do any encoding at all so images should work. But then again we don't know what code you changed so we can't really help you. It would help if you send us the image so we can test.
It's likely that your images' bytes are being UTF-8 encoded. If the bytes are uniform, you can expect a 50% increase in size (the low 128 bytes are passed as they are, the high 128 bytes are expanded to two bytes; (128+128*2)/256 = 1.5) and that's what you are seeing.
But WAListener is like WAKom it should not do any encoding unless someone changed the code.
Cheers Philippe
squeak-dev@lists.squeakfoundation.org
-
chunsj＠embian.com -
Niko Schwarz -
Paolo Bonzini -
Philippe Marschall