Michael Foord пишет:
> One possible approach would be to store the repr of the string. This
> will escape quotes and so avoids the problem. You then use the
> "string_escape" codec to unescape again.
>
> This would also escape newlines, so would turn strings into a single
> line. If you still want them to be human readable then you could
> manually replace "\n" with a newline in the escaped string and reverse
> this before unescaping.
>
> e.g. to write:
>
> value = repr(the_real_value).replace('\\n', '\n')
>
> and to read:
>
> the_real_value = value.replace('\n', '\\n').decode('string_escape')
>
Thank you, Michael.
But actually for our purpose to store arbitrary non-ascii text we need
'unicode-escape' codec, I think. We can use this approach in QBzr
library that has the code to trigger this bug. Although for QBzr it
means we have to break backward compatibility with older QBzr versions.
Michael Foord пишет: real_value) .replace( '\\n', '\n') decode( 'string_ escape' )
> One possible approach would be to store the repr of the string. This
> will escape quotes and so avoids the problem. You then use the
> "string_escape" codec to unescape again.
>
> This would also escape newlines, so would turn strings into a single
> line. If you still want them to be human readable then you could
> manually replace "\n" with a newline in the escaped string and reverse
> this before unescaping.
>
> e.g. to write:
>
> value = repr(the_
>
> and to read:
>
> the_real_value = value.replace('\n', '\\n').
>
Thank you, Michael.
But actually for our purpose to store arbitrary non-ascii text we need
'unicode-escape' codec, I think. We can use this approach in QBzr
library that has the code to trigger this bug. Although for QBzr it
means we have to break backward compatibility with older QBzr versions.
--
All the dude wanted was his rug back