GRInvalidUtf8Error: Invalid UTF-8 input

> On 25 Jun 2016, at 10:21, Johan Brichau <[hidden email]> wrote:
>
>
>> On 25 Jun 2016, at 10:00, Johan Brichau <[hidden email]> wrote:
>>
>> The “funny” part right now is that the upload file test does not break in my image when using the published code for Zinc-Seaside!
>> So… I am a bit baffled and would like to understand first what is going in.
>
> I got it... it crashes in Safari, not with Chrome.
> Obviously, the ‘old fix’ was wrong and I undid it in December 2016 but the package was never correctly committed (only in my package cache… which I also never cleared apparently in my Seaside work folder…)
>
> I sent my package .44 to Sven for publication. Just remove the decode: message send in the adaptor, as you mentioned.
>
> thanks for reporting and sorry about the mess
>
> Johan
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

>
>
> Le 22/06/2016 09:40, Philippe Marschall a écrit :
>> Ok, it's likely in the server adapter before Seaside actually kicks in
>> then. Can you set a break point in GRPharoUtf8Codec >> #invalidUtf8?
>>
>> My suspect would be ZnZincServerAdaptor >> #convertMultipart:
>>
>> If you can send us the string it's trying to convert that would be helpful.
>
>
> The string argument of GRPharoUtf8Codec>>decode:
>
> is
>
> aString ->'Identités certifiées.pdf'
>
> printed as this in the Debugger. As we know Pharo does not use UTF8
> internally it is suspect to see an utf8 string correctly printed in
> Pharo, right?

> Now looking back in the stack as you suggested, then decoding already
> took place at:
>
> ZnMimePart>>fileName
> "Pathnames are often silenty encoded using UTF-8,
> this is a no-op for ASCII, but will fail on Latin-1 and others"
> ^ (self detectContentDispositionValue: 'filename')
>         ifNotNil: [ :encodedFileName | encodedFileName asByteArray utf8Decoded ]
>
>
> The timecode of this method is 10/10/2014 from Sven
>
> The second place where the decode takes place is (Zinc-Seaside package):
>
> ZNZincServerAdaptor>>convertMultipartFileField: part
> | file |
> (file := WAFile new)
>         fileName: (self codec decode: part fileName);
>         contentType: part contentType printString;
>         contents: part contents asByteArray.
> ^ file
>
> Timecode is 11/14/2014 from Johan, where the decode was added.
>
>
> This two methods use too different decoding methods (duplication?), one
> from the Grease package, the other from ZN package.
>
> My opinion is the Zinc-Seaside package should not try to decode, or
> preferably use the ZN decode method (utf8Decoded), but it will bring an
> error on already decoded string.