Le 08/03/2015 16:53, Lester Caine a écrit :
"Lorem ipsum dolor sit amet"->length(); "Lorem ipsum dolor sit amet"->search('lorem'); "Lorem ipsum dolor sit amet"->replace('lorem', 'Lorem');This is actually the problem that trying to ignore unicode then creates a black hole. The amount of space needed to store the string is a variable once one moves outside the single byte encodings, but where legacy systems only allow buffering for the single byte version, one gets a number of problems where the data returned has multi-byte characters. The first example has several answers depending on what one is doing with the return. Size of buffer needed (sizeof in my crib sheet), or one of the methods of counting the number of symbols used (count but with an agreed decoding). The other two actually work with multi-byte strings until one adds 'adornments' to the characters which may need a search to look for a set of similar words all with the same meaning, just encoded differently. My point is perhaps that it is all to easy nowadays or post/get data to have multi-byte strings from different languages which trying to map to a single byte solution is no longer appropriate. I've just been downloading a set of documents which are essentially all English, but the file names includes words from a number of other languages resulting in UTF8 being the only way to store them, and ideally the search engine should be able to find them again in the future.
I understand your point, but what I mean is not making the user totally unaware of the encoding, but building a common API to make it easier for everyone to avoid the need of permanent awareness, anywhere, anytime of the encoding.
Instead, make the string API make the job of choosing whichever backend extension is used (default or mbstring), then if the user feels the need of mixing encodings, he *SHOULD* have to be aware of it *AND* have the right transformations API availiable.
This is to make possible to simply build methods that do not need to be aware of encoding (eg. pure frontend text treatments) to automatically map to the right encoding (maybe with E_RECOVERABLE_ERROR on incompatible charsets).
Maybe string notations could also evolve, such as what exists in C for wchar_t strings (like some L prefix, or else), I have no fixed opinions about that and it is not the main subject anyway.
The main question is about an uniform API for strings, do you feel it is important/useful or not?
Grégory Planchat -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
