Update ufile.cpp

[defrag257]

When Windows API is available, use Windows API _wfopen instead. Don't expect u_fopen to fail, because it might cause a mojibaked file name without a fail when perm contains "w" or "a".

Checklist

• [ ] Issue filed: https://unicode-org.atlassian.net/browse/ICU-_____
• [ ] Updated PR title and link in previous line to include Issue number
• [ ] Issue accepted
• [ ] Tests included
• [ ] Documentation is changed or added

[jefgen]

Thank you for creating a PR!

Would you be able to also create a bug/ticket for this change as well? https://unicode-org.atlassian.net/secure/Dashboard.jspa

[CLAassistant]

All committers have signed the CLA.

[jefgen]

Thanks for signing the CLA. Could you please file an issue at https://unicode-org.atlassian.net/ ? (All commits and PRs need to have a corresponding ticket). Thanks!

[markusicu]

@rp9-next is this worth doing and looks like a good start? If so, please file a ticket on the author's behalf. If not, please close this PR.

[rp9-next]

The PR points the reason for the changes as mojibaked text for fopen on windows. The windows docs, however point out that the functioning of fopen and _wfopen as the same (The latter being widechar version of the former). Closing this now. Please re-open if required.

[defrag257]

Documentations are not always reliable. Sad to see this PR closed. :( In Windows, a wide char actually supports a lot more chars than a narrow char. They are NOT THE SAME. Wide chars in Windows are in UTF-16LE encoding, which supports Unicode chars 0~0x10FFFF using one or two 16-bit wide chars. Especially, wide chars support emojis. 🙂 Narrow chars differs from one country/region to another. For example, the US English version of Windows uses Windows-1252, which only supports 256 chars. No emoji supports at all. ☹