Re: [RFC] Unicode Escape Syntax
| From: | Andrea Faulds | Date: | Tue, 25 Nov 2014 11:18:57 +0000 |
| Subject: | Re: [RFC] Unicode Escape Syntax | ||
| References: | 1 2 3 4 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-79157@lists.php.net to get a copy of this message | ||
> On 25 Nov 2014, at 10:41, Dmitry Stogov <dmitry@zend.com> wrote:
>
> u8"string" tells that the whole string is UTF-8 encoded.
> Your escape Unicode proposal assumes just UTF-8 codepoint, but the whole string encoding is
> still undefined.
True. There’s an assumption there that you’re using a UTF-8-compatible source file. Actually,
for other encodings, do we even guarantee that “\n” produces an ASCII LF just now? It certainly
will on most Windows and Unix systems, but since we’re just using C’s ‘\n’
(http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_language_scanner.l#885), it might produce the newline
character of some other encoding like EBCDIC in the right environment.
> > If you're using other encodings, why do you want to use a Unicode codepoints? Most
> > Unicode codepoints will not supported by another character set.
>
> Agree, this Unicode escapes are not going to be used for anything except UTF-8 encoded strings.
> I'm not completely against it. It's just an incomplete solution.
>
> echo "\u{1F602}"; // won't output 😂 if the output encoding is not UTF-8
>
> echo "Привет \u{1F602}"; // won't output anything useful if script
> encoding is not UTF-8
> The second problem present even for European counties that use Windows-1250 codepage.
> echo "mañana \u{1F602}"; // won't output anything useful if script encoding is
> not UTF-8
> Thanks. Dmitry.
Yeah, that’s unfortunate. Although I don’t think there’s much we can do about it here. We
can’t really convert, as if most Unicode characters won’t be available in the codepage you’re
using.
Even if we did have Unicode strings like the fabled PHP6 would have had, you still have this problem
when you’re outputting in non-Unicode encodings.
Although it’s worth noting that mbstring *should* handle this, since if you have an internal
encoding of UTF-8 and an output encoding of, say, Windows-1250, you can use UTF-8 in your strings it
should convert that for you on output. How well this works in practice, however, I have no idea.
--
Andrea Faulds
http://ajf.me/