[fpc-devel] Unit for handling UTF-8 strings
Mattias Gaertner
nc-gaertnma at netcologne.de
Sun Apr 7 17:59:14 CEST 2013
On Sun, 7 Apr 2013 13:35:40 +0200
Kostas Michalopoulos <badsectoracula at gmail.com> wrote:
>[...]I looked around in FPC 2.6.2's units and found nothing beyond
> utf8encode/decode (which in linux requires a C widestring manager that i'd
> like to avoid... and doesn't really help in all cases since Unicode can
> exceed the 16bit range).
It does not require a widestring manager.
> Searching in Google i found a discussion from 2007 which basically
> concluded to "yeah, it is a nice feature, has some warts, but people need
> it" but didn't went anywhere
> http://free-pascal-general.1045716.n5.nabble.com/UTF-8-versions-of-Copy-and-Length-td2814536.html
> and
> the apparent lack of a UTF8 unit in FPC six years later (even for basic
> stuff like copy, length, etc) means that that unit never came to exist.
>
> So, what is going on with that? Graeme mentioned that he already had some
> code and knew some other library that provided a more complete solution
See for example the Lazarus lazutf8 unit.
> that could be imported in FPC and even another guy had yet another library.
> But still no UTF8 in FPC, despite all the different implementations
> floating around out there and despite UTF8 being the most important Unicode
> encoding (being used by practically anything that doesn't falsely believe
> that 16bit integers are enough).
AFAIK there are no UTF16 functions either.
Lazarus provides a lazutf16 unit too.
> Personally i coded yet another unit, which you can find here:
> http://pastebin.com/cJ2TvRdZ
>
> Of course my code is most likely slow and there might be some bugs there -
> i only did some testing with Greek characters which seem to work fine, but
> nothing like Chinese or the new emoticon stuff which is regularly added in
> Unicode.
I agree, your unit is most likely slow.
>[...]
Mattias
More information about the fpc-devel
mailing list