On 14/09/2011 11:04, Felipe Monteiro de Carvalho wrote: > > IMHO a platform-dependent string would be the worse solution of all > ... far worse then migrating to UTF-16.
I don't see why? Use the RTL functions to manipulate your text strings. Both the string and RTL functions will use the same encoding on each platform - so no problems, no conversions. If you really needed to know the encoding, the RTL could include a helper function to tell you the encoding of any string (just like Delphi 2009+ has). > Just recently I had a student from my university implement a routine > which converts HTML text from utf-8 to braille in utf-8 ... I didn't Again, no problem. The HTML should have specified the encoding it is in. Normally that would be UTF-8. So under Linux, MacOSX etc it will already be in the native encoding. Under Windows, text is normally stored in UTF-8, contrary to UTF-16 being the encoding off the native Windows API. So loading the file you can compare the HTML file encoding to the current RTL encoding and do a conversion if needed (same as is required in Delphi). As for the text-to-braille functionality, that is outside the scope of the FPC and RTL. But common sense should prevail, use RTL string functions to implement your conversion - don't assume 1 byte = 1 character. A unicode aware string iterator could be implemented to help you step through the characters one at a time. Such a string iterator could even become part of the RTL as it will probably be used often for many parsers. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel