There are many API methods which don't accept 'unicode' instance as their string type arguments.
e.g.
1st argument (attribute name) of FMEFeature.setAttribute
1st argument (message string) of FMELogFile.logMessageString
Currently users who are working with Non-ASCII locale have to add codes to check the class of each string value and convert it to a 'string' instance if it was a 'unicode' instance, to avoid the UnicodeEncodeError.
Hope every method will accept 'unicode' instances as string type arguments.
Released
Python FME API Objects: Enhancement for Unicode Support
This post is closed to further activity.
It may be a question with a best answer, an implemented idea, or just a post needing no comment.
If you have a follow-up or related question, please post a new question or idea.
If there is a genuine update to be made, please contact us and request that the post is reopened.
It may be a question with a best answer, an implemented idea, or just a post needing no comment.
If you have a follow-up or related question, please post a new question or idea.
If there is a genuine update to be made, please contact us and request that the post is reopened.
Btw, I'd give you an upvote, but apparently I have -8 votes to give, so it'll have to wait till Safe fixes it ;-)
+17- Contributor
Yes it is out intention to support unicode more completely moving forward. This is planned for FME 2017. See also
https://knowledge.safe.com/content/idea/19407/update-to-python-3x.html
+17- Contributor
This is done for FME 2016.1.1 as well as FME 2017 betas.
From the "whatsnew":
FME 2016.1.1.0 16593 20160620
-----------------------------
Python: Modified logMessage() and getMessage() to allow mixed unicode and str values in the message parameters. Fixed encoding of source code passed from PythonFactory to Python interpreter. (PR#70683)
Helpful Members This Week
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.