07/02/11 Yasushi Masuda<[EMAIL PROTECTED]> wrote:
> Instead, I'd like to propose making get_valid_filename() as default
> behaviour of ``filename_normalization``, and adding a
> ``filename_nomalizer`` parameter in FileField's constructor, like this::
I completely agree with Yasushi.
The point is
I'd like to ask for comments on #3119: problems on FileField/ImageField
with multi-byte filenames. Since this problem is caused by two reasons,
let me describe them step by step.
Multibyte characters in a filename are lost in get_valid_filaname().
-
Hi all.
I agree with Benjamin completely.
I hate Identity Map and synchronization approach.
They break database logic like trigger or view.
2007/2/5, Benjamin Slavin <[EMAIL PROTECTED]>:
>
> I've also given this some consideration -- I haven't found any
> information on this either.
>
> It would
Ok, I just added a ticket(http://code.djangoproject.com/ticket/3119).
Forget this patch at this time.
Do you have any idea?
2006/12/4, tsuyuki makoto <[EMAIL PROTECTED]>:
> Hello django developers.
>
> Currently, FIleField and ImageField store file-system-safe file name.
>
Hello django developers.
Currently, FIleField and ImageField store file-system-safe file name.
Imagine, if user upload a file named é.txt.
Yes, File-system-safe file name is .txt or _.txt.
It's not special case in Japan.
I know Django says non dynamic contents should be served via apache-ish
2006/7/20, Gábor Farkas <[EMAIL PROTECTED]>:
>
> Jeroen Ruigrok van der Werven wrote:
> > On 7/16/06, gabor <[EMAIL PROTECTED]> wrote:
> >> i think we do not need to discuss japanese at all. after all, there's no
> >> transliteration for kanji. so it's imho pointless to argue about
> >> kana-transl
2006/7/17, gabor <[EMAIL PROTECTED]>:
>
> Jeroen Ruigrok van der Werven wrote:
> > On 7/12/06, Julian 'Julik' Tarkhanov <[EMAIL PROTECTED]> wrote:
> >> This is handled by Unicode standard and is called transliteration.
> >
> >
> > Also, for Japanese, are you going to follow kunrei-shiki or rather
