(In reply to comment #8)
> (From update of attachment 305229 [details])
> >+ nsCAutoString charset;
> >+ rv = aURI->GetOriginCharset(charset);
> >+ NS_ENSURE_SUCCESS(rv, rv);
> This could be empty - in which case it's assumed to be UTF-8
>
> >+ nsAutoString uriSpec;
> >+ (void)textToSubURI->UnEscapeURIForUI(charset, utf8URISpec, uriSpec);
> So, I don't particularly like this because of
> * escaping back the result (unescaped string) is not guaranteed to give the
> original escaped string
> I don't think that that is how we want to store the information at least.
> I think that calling unEscapeNonAsciiURI and maybe UnEscapeAndConvert (not
> necessarily in that order) would be better here.
>
> >+ rv = statement->BindStringParameter(index,
> >+ StringHead(uriSpec, HISTORY_URI_LENGTH_MAX));
> I know you didn't change this, but I don't understand why we need StringHead...
>
> I do believe that if we are changing how we store information in the database
> that we also need to migrate existing data. This is an interesting use case
> because technically we aren't changing any of the schema...
>
> Also a test showing that this works with a database that already has this stuff
> in it would be good.
>
(In reply to comment #8) Charset( charset) ; SUCCESS( rv, rv); URI->UnEscapeUR IForUI( charset, utf8URISpec, uriSpec); >BindStringPara meter(index, URI_LENGTH_ MAX));
> (From update of attachment 305229 [details])
> >+ nsCAutoString charset;
> >+ rv = aURI->GetOrigin
> >+ NS_ENSURE_
> This could be empty - in which case it's assumed to be UTF-8
>
> >+ nsAutoString uriSpec;
> >+ (void)textToSub
> So, I don't particularly like this because of
> * escaping back the result (unescaped string) is not guaranteed to give the
> original escaped string
> I don't think that that is how we want to store the information at least.
> I think that calling unEscapeNonAsciiURI and maybe UnEscapeAndConvert (not
> necessarily in that order) would be better here.
>
> >+ rv = statement-
> >+ StringHead(uriSpec, HISTORY_
> I know you didn't change this, but I don't understand why we need StringHead...
>
> I do believe that if we are changing how we store information in the database
> that we also need to migrate existing data. This is an interesting use case
> because technically we aren't changing any of the schema...
>
> Also a test showing that this works with a database that already has this stuff
> in it would be good.
>