| Re: Unicode support [message #180977 is a reply to message #180976] |
Sat, 30 March 2013 13:25   |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma:
|
Senior Member |
|
|
Christoph Becker wrote:
> Thomas 'PointedEars' Lahn wrote:
>> Christoph Becker wrote:
>>> I recently read, that UTF-8 is not available on many Windows PCs in
>>> Taiwan, where `BIG5' is still prevalent, what would be very unfortunate.
>>
>> I would like to see proof of that. While possible, I consider it
>> unlikely. Taiwan is especially intertwined with the Western world (being
>> the location of major local hardware manufacturers, and major foreign
>> investments on the doorstep to mainland China), and Traditional Chinese
>> as written in Taiwan was one of the first scripts to be covered by
>> Unicode, with CJK Unified Ideographs, in 1992.
>
> I'm quite sure now, that I was mistaken. It is not UTF-8 support that
> is missing on the PCs, but rather that the file systems are using BIG5
> by default,
But not NTFS, I presume?
> what is of course something quite different. Sorry for the incorrect
> information.
Never mind.
>> Windows has been supporting Unicode, and came pre-installed with Unicode-
>> capable fonts since Windows NT (and so, Windows 2000). Did not Windows
>> XP support end last year?
>
> According to <http://www.microsoft.com/en-us/windows/endofsupport.aspx>
> support of Windows XP SP3 ends on April 8, 2014.
That is good to know. However, it should be noted that (at Microsoft) there
are different levels of support, and there are different versions of Windows
XP. Mainstream Support and Extended Support for some versions of Windows XP
has ended already:
< http://support.microsoft.com/lifecycle/search/default.aspx?sort=PN&alph a=Windows+XP&Filter=FilterMS&msdate=0>
We are now looking forward to the date that *all* support will be
discontinued for *all* versions of Windows XP (as there will be no more
Service Packs).
>>> […] if I'm not mistaken, the situation won't change with PHP 5.5. :(
>>
>> That would be a pity. Native Unicode support was announced for PHP 6
>> before those plans were abandoned. I wonder, what can be that hard in
>> implementing it? Apparently even Perl managed the transition years ago
>> although it requires a few extra lines per script.
>
> Native Unicode support was planned to be resp. already partially
> implemented by using UTF-16 internally throughout. It seems, that
> several PHP developers had concerns about the performance and memory
> overhead of doing so. Obviously no agreement could be found, and on
> March 11, 2010 Rasmus Lerdorf `decided' to delay PHP 6 and the Unicode
> support.[1]
Thanks. ISTM that PHP developers are struggling with the same issues as
Python developers did once. UTF-16 is considerably large, but string
operations (like determining string length) are fast within the BMP. UTF-8
is small for low code points, but harder to deal with. UTF-32 covers more
than the BMP, and would allow fast operations, but is wasteful of precious
memory. (As of Python 3.3, Python uses an encoding that attempts to get the
best of both worlds.)
Still, a UTF-8 pragma like in Perl would not be such a bad idea for PHP.
Only those who need it would use it.
> Of course there are several extensions handling UTF-8 quite well, but
> these may not be available on shared web hosting services, and anyway
> it's quite ugly to have e.g. strlen('€')===3 when dealing with UTF-8.
The same issue exists with characters outside the BMP in ECMAScript
implementations which uses 16-bit characters (usually one UTF-16 code unit
per character). But you can work around that rather efficiently.
> [1] <http://news.php.net/php.internals/47120>
I will read that later.
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]