Unicode support

[aeroplane]

I've been able to build and use this lib on vista with vs2010 and boost 1.43. When i try to write a unicode filename with chinese characters in it, it works fine. When i try to log (write) chinese (or russian) characters to that file, the stream just stops writing and quits when it encounters those non ascii chars. I do have BOOST_LOG_USE_WCHAR_T defined, all string literals are wrapped in _T() macro, unicode is set as compiler option and i've used the wide char methods provided in logging lib:
winit_log_to_console (which doesn't seem to accept formatters), winit_log_to_file,  wadd_common_attributes, wlogger and wseverity_logger. Did i miss something i need to do when using this lib in combination with unicode chars?

[Andrey Semashev]

I have one guess. The file stream will always try to convert wide strings that are produced by the library to a sequence of narrow characters to be written into the file. This conversion may fail if done by the classic locale, and the string contains national characters. Right now, I'm afraid, there is no user-side way around it, except implementing the sink backend yourself.

[aeroplane]

Yes you are correct, thats the problem. To correct this issue i should use a null_codecvt that basically doesn't do the narrow char conversion. After that i should imbue that filestream, but how can i implement it in your lib?

[Andrey Semashev]

Unfortunately, the current interface doesn't allow you to do that, unless you're using text_ostream_backend. That's something I want to change in v.2.0. Meanwhile, I can suggest two options:

1. Set the global locale with the needed facet before creating the file sink. The file stream will inherit the global locale. After that you can restore the global locale.
2. Extend the file backend interface in your local copy of the library and set the locale to the stream.

[Yang Lian]

I am using the suggest 2.
I dont think set global locale is a good idea.because  I also referred GetText library.

Would you like to add this issue to FQA? that may goog for beginners just like me.

[Vasiliy Novosiadliy]

I found another another alternative - to use the set_open_handler with a functor like:

struct locale_imbuer{
  void operator()(sinks::wtext_file_backend::stream_type & s){
     s.imbue(std::locale(std::locale::classic(), new NullCodecvt ));
  }
};

It gets called every time a file is opened.

[Andrey Semashev]

Great! I should have thought about this.

[Juan Fernandez]

Is there any update on the support of unicode strings (e.g. Chinese or Russion log strings) on the latest version of boost.log? I'm facing the same trouble. My calls to the logger, throw an exception upon logging Chinese characters in the method:code_convert of code_conversions.cpp.

Is there any further explanation about what to do with Vasino's proposal above (top 6)?

I'm currently using the same lib for the Debug and DebugUnicode target. Might it be necessary to compile boost.log with a unicode support flag?

[Andrey Semashev]

Unicode support is in place, you just have to install the appropriate locale in your narrow character sinks and use wide character loggers. See here.