CFileDialog getpathName не читает японский

У меня есть имя папки на японском языке. CFileDialog getpathNameis возвращает несколько вопросительных знаков при выборе папки. Есть ли способ решить эту проблему?


unicode visual-c++ cjk mfc filedialog
person sherin_    schedule 09.11.2011    source источник
comment
Фрагмент кода? Ваше приложение создано с включенной поддержкой Unicode?   -  person Roman R.    schedule 09.11.2011
comment
Это вопрос, связанный с Visual-С++ (или чем-то другим?), а не с общим С++. Более конкретное использование тегов помогает человеку, способному ответить на этот вопрос, увидеть его, помогает другим членам сообщества найти вопрос, а также увеличивает ваши шансы на получение ответа. Это беспроигрышный вариант ;]   -  person friendzis    schedule 09.11.2011
comment
Откуда вы знаете, что GetPathName не возвращает японские символы? Возможно ли, что проблема в коде, выводящем результаты, а не в самом GetPathName?   -  person Mark Ransom    schedule 09.11.2011
comment
@Roman нет, он не построен с включенной поддержкой Unicode   -  person sherin_    schedule 10.11.2011
comment
@Mark Когда я прошел через код, cstring, возвращаемый GetPathName, показывает некоторые ????? вместо японского текста   -  person sherin_    schedule 10.11.2011
comment
@friendzis Спасибо за ваш комментарий. Я обязательно отмечу это в будущих вопросах   -  person sherin_    schedule 10.11.2011
comment
Возможно, отладчик использует шрифт без японского языка. Чтобы быть уверенным, вы должны сделать двоичный дамп данных.   -  person Mark Ransom    schedule 10.11.2011
comment
Это мой код ‹code› CFileDialog dlg(TRUE, NULL, NULL, OFN_HIDEREADONLY | OFN_OVERWRITEPROMPT, файлы JPEG (.jpeg, *.jpg)|.jpeg; *.jpg||, NULL ); if (dlg.DoModal() == IDOK) { SetCursor(AfxGetApp()->LoadStandardCursor(IDC_WAIT)); FileName = dlg.GetPathName(); Standard_CString aFileName = (Standard_CString)(LPCTSTRFileName; }.‹/code›   -  person sherin_    schedule 10.11.2011

Ответы (1)


arrow_upward
2
arrow_downward

Если ваше приложение создано с поддержкой MBCS, а не с поддержкой Unicode, путь для японского языка будет обрабатываться правильно только в том случае, если для параметра "Язык для программ, не поддерживающих Unicode" (также известный как языковой стандарт системы) задан японский, что подходит для ваших японских пользователей, но может быть не для вас, если вы не японец.

Если язык вашей системы не японский, путь преобразуется в вашу кодовую страницу, прежде чем он будет возвращен GetPathName(). Он будет либо содержать замещающие (?) символы, либо мусор. Скорее всего смесь того и другого.

Вот несколько доступных возможностей:

  1. Ничего не делай. Ваше приложение должно нормально работать для большинства пользователей из Японии. Или не...

  2. Протестируйте свое приложение с японской кодовой страницей. Для этого либо временно измените свой язык для программ, не поддерживающих Unicode (требуется перезагрузка), либо (гораздо проще) протестируйте свое приложение в разделе Месторасположение приложения. (Примечание. Да, он отлично работает под Windows 7. Эта статья может помочьесли есть проблемы).

  3. Переключите его на Unicode. В зависимости от размера вашей кодовой базы это может быть очень утомительной задачей, в основном в зависимости от входных и выходных данных и от того, используете ли вы _T("blah") строковых литералов в своем коде. Конечно, есть и другие аспекты, но эти самые важные. Кстати, все новые проекты должны быть сделаны с учетом поддержки Unicode.

  4. Обработайте эту проблему пути специально. Поскольку мы говорим о файловом диалоге, весь диалог должен быть открыт как Unicode. Это означает, что вам, вероятно, придется явно вызывать Unicode-версию базового Win32 API, а не просто CFileDialog. Это не так сложно, но есть риск, что вы решаете только первую задачу подряд. После того, как вы правильно настроите японский путь, вам придется иметь дело с вводом текста на японском языке пользователем... Поэтому я не думаю, что это решение является хорошим.

Решение № 2, безусловно, является самым быстрым способом выявления небольших проблем. Решение № 3, безусловно, лучшее в долгосрочной перспективе. Но убедитесь, что вам это действительно нужно, потому что это может быть утомительно для существующих приложений.

person Serge Wautier    schedule 10.11.2011