[Insight-users] Using ITK with unicode character set

Sébastien Fricker sebastien.fricker at phaseview.net
Fri Jul 6 03:01:45 EDT 2007


Luis,
Thanks for your reply. std::string is a string of char* so we have the same
problem.

To me, an overload using wchar_t* instead of char* (or a std::wstring
instead of a std::string) would solve the problem.

Sebastien



-----Original Message-----
From: insight-users-bounces+sebastien.fricker=phaseview.net at itk.org
[mailto:insight-users-bounces+sebastien.fricker=phaseview.net at itk.org] On
Behalf Of Luis Ibanez
Sent: jeudi 5 juillet 2007 17:58
To: Sean McBride
Cc: insight-users at itk.org; Nithiananthan, Sajendra
Subject: Re: [Insight-users] Using ITK with unicode character set


Hi Sean,

We recently added to the StringMacro the extra method that overloads
all the methods that use to accept "char *", they also accept now
"std::string" as argument.

See August 9th 2006 commit:
http://www.itk.org/cgi-bin/viewcvs.cgi/Code/Common/itkMacro.h?root=Insight&s
ortby=date&r2=1.67&r1=1.66

This propagates to the SetFileName() methods of ImageFileReader and
ImageFileWriter, since they use the StringMacro().


I'm not sure if you could solve the ambiguity of unicode by
passing std::string to the SetFileName() methods.

If that is not the case,


then we could add another overload to that StringMacro in order
to have methods with the wide char pointer as argument.

That's a relatively minor change to make.


    Luis


--------------------
Sean McBride wrote:
> On 7/3/07 9:55 AM, Nithiananthan, Sajendra said:
> 
> 
>>>>I assume that because char type is too small to hold Unicode 
>>>
>>>encoding so I
>>>
>>>>need to use wchar_t.
>>>
>>>This assumption is incorrect.  I really suggest you read:
>>><http://www.joelonsoftware.com/articles/Unicode.html>
>>>
>>>char* is perfectly fine for a unicode string that is encoded as UTF8.
>>>
>>>
>>>After reading the above article, the question you should ask (and I
>>>don't know the answer) is "What encoding does ITK's 
>>>SetFileName() expect?".
>>>
>>
>>char * might be perfectly fine for UTF8, but you can't guarantee that the
>>Windows File System will understand UTF-8.  Windows likes to use wide
>>characters for filenames (at least on some systems I've seen) so you have
to
>>account for that.
> 
> 
> That's fine.  But you are perhaps missing my point.  ITK exposes its own
> APIs.  It has an API named SetFileName() that takes a char*.  As users
> of the API, we need to know what encoding it expects.  We'd still need
> to know even if the parameter was wchar_t, void*, or anything else.  The
> implementators of the API may have to conditionally convert from that
> encoding to whatever encoding a particular OS's file system APIs
> desire.  That's fine too, but it's also an implementation detail that
> users of the API should not care about.
> 
> The question remains: What encoding does ITK's SetFileName() expect?
> 
_______________________________________________
Insight-users mailing list
Insight-users at itk.org
http://www.itk.org/mailman/listinfo/insight-users



More information about the Insight-users mailing list