On 23 May 2012, at 10:46, Lauri Aalto wrote: > > thanks for the report. The best place for bug reports is > <http://bugs.librdf.org>. > > I fixed this particular issue in commit > <https://github.com/dajobe/raptor/commit/391e09a5acddaf3ed63005bec880804896ca860e>. >
Thanks Lauri. I'll update from GIT later today and in future, I'll report bugs to the right place. I've found something else which might be a bug (well, an oversight really) but before I report it, let me describe it here in case I'm misunderstanding something. I'm working on a cross-platform app which uses lrdf to open and parse some files. 'lrdf_read_file()' eventually defers to 'raptor_parser_parse_file()' to open the actual disk file. 'raptor_parser_parse_file()' accepts a URI to identify the file to be opened. According to this document by Tim Berners-Lee:- http://tools.ietf.org/html/rfc3986 the specification states that before conversion to URI, a character string must first get converted to UTF-8 (see the final paragraph of Section 2 - just before Section 3). 'raptor_parser_parse_file()' calls 'raptor_uri_uri_string_to_filename()' to produce a string that identifies the local file. However, after decoding, that string will be in UTF-8 format. UTF-8 format seems to work for Linux and OS-X but on Windows, you cannot pass a UTF-8 string to 'open()'. So 'raptor_uri_uri_string_to_filename()' only works reliably in an English language locale. It will fail if there are non-English characters in the file path. On Windows an extra layer of decoding is needed to convert the UTF-8 file path into a valid Windows file path (Windows has functions to achieve this, I think). I could probably write a patch and submit it but before I do that, is there already some recommended way for dealing with this (i.e. have I simply missed something?) John _______________________________________________ redland-dev mailing list [email protected] http://lists.librdf.org/mailman/listinfo/redland-dev
