#1026 Unexpected behaviour of mb_strlen() in external code

[Henning Zimmermann]

The constructor of the class TCPDF changes the default internal_encoding of the mb_string-functions (with mb_internal_encoding('ASCII')) to ASCII and the destructor changes it back.

This leads to an unexpected behavior of many multibyte-string-functions (like mb_strlen()) in external code as soon as an object of the class TCPDF is created. I can't see a reason, why this internal encoding must be changed to ASCII in the constructor, because in my humble opinion the mb-functions used by the class TCPDF work fine without modifying the internal_encoding to ASCII.

Therefore i suggest to remove the code from the consructor/destructor which manipulates the internal_encoding of the mb-functions.

[Nicola Asuni]

Currently TCPDF requires mb_internal_encoding('ASCII').
If you have a better solution please use the path section of this website.

[Henning Zimmermann]

I removed the code from the constructor / destructor and everything worked fine for all of my pdfs using my default encoding (UTF-8). Can you please give me a hint in which situation / which functionality needs the internal_encoding set to ASCII?

In TCPDF i only can find two mb_* functions:
mb_convert_case()
mb_convert_encoding()

Is the internal_encoding used at other places?
I would like to know if it is save to use UTF-8 without crashing the generated PDFs.