Services for Macintosh uses default locale translation table to map localized characters

Localized Macintosh clients may not be able to interoperate properly with SFM shares on computers running Services for Macintosh (SFM), even though Windows 2000 and Windows Server 2003 provide native support for multiple languages.

For example, when a Japanese Macintosh client attempts to open a file (through a SFM share) saved by a computer running Japanese Windows NT Workstation to a U.S.-based server, the file name may be displayed on the Macintosh computer as ?????????.txt rather than the proper file name. The file is also reported as corrupt or unreadable by the Japanese Macintosh computer when you attempt to open it.

This problem occurs because Mac OS 9 does not support the Unicode standard, but does support ANSI.

To resolve this problem and support both Japanese and U.S. clients from a U.S.-based server, change the default system locale to Japanese on the U.S.-based server. To do this, use one of the following methods.

Note This resolution is most effective when you attempt to support one single byte and one double byte character set (DBCS) language from the same server. It does not work effectively when multiple DBCS languages need to be supported on the same computer running Windows 2000. After you resolve this problem, you must restart the server.

Microsoft Windows 2000

1. Click Start, point to Settings, click Control Panel, and then double-click Regional Options.
2. Click the General tab.
3. Click Set Default.
4. Select Japanese from the drop-down list, and then click OK.

Microsoft Windows Server 2003

1. Click Start, point to Control Panel, and then click Regional and Language Options.
2. Click the Advanced tab.
3. Select Japanese from the drop-down list, and then click OK.

Microsoft has confirmed that this is a problem in Microsoft Windows 2000 and in Microsoft Windows Server 2003.

By default, when a Windows NT client saves a file to a computer running Windows NT Server, the computers use Remote Procedure Call (RPC) to save the file as Unicode. The U.S.-based server stores DBCS files properly because Windows NT has native support for Unicode, even if it does not have the code pages installed to properly view the file. Thus, a Japanese Windows NT or Windows 2000 client can save and retrieve a DBCS file from a U.S.-based server and display it properly.

However, when a Japanese Macintosh computer that is running Mac OS 9 saves a file on a SFM share on a U.S.-based computer running Windows NT Server, the file is stored in the native ANSI character set (shift-jis), rather than Unicode. The Japanese versions of Windows NT and Windows 2000 support both s-jis and Unicode, so the Japanese Windows NT client can read files created by Japanese Macintosh clients. However, because Mac OS 9 does not support Unicode, the following process occurs when the Macintosh client requests a file from a computer running SFM.

• SFM checks the file to see if it is formatted in Unicode. Unicode files can be identified when opened with a hexadecimal editor by the first four nibbles, which are always FF FE (assuming UTF-8 encoding).
• If the file is formatted with Unicode, SFM translates the file into native ANSI format, based on the default system locale.
• The translated file is sent to the Macintosh client.

The default code page for Windows NT and Windows 2000 is defined in the following registry location: For example, if the default Windows NT code page setting is US English (code page 409), SFM maps the Unicode file to the ASCII/ANSI table. If the file is actually a Kanji file, the contents are interpreted incorrectly by this process, and thus are displayed incorrectly on the Japanese Macintosh client. Currently, there is no way for SFM to detect that the client is localized to a different language other than the server running SFM because of limitations in the AppleTalk File Protocol Specifications. Therefore, when all files are converted from Unicode, they are mapped to the code page translation table of the default system locale. This procedure occurs regardless of the localization of the Macintosh client. The Unicode Consortium's home page is located at: