Làm th? nào đ? chuy?n đ?i t? ANSI t?i Unicode & Unicode đ? ANSI cho OLE

D?ch tiêu đ? D?ch tiêu đ?
ID c?a bài: 138813
Bung t?t c? | Thu g?n t?t c?

TÓM T?T

T?t c? các dây đư?c truy?n cho và nh?n đư?c t? 32-bit OLE API và phương pháp giao di?n s? d?ng Unicode. Đi?u này đ?i h?i các ?ng d?ng s? d?ng ANSI dây đ? chuy?n chúng đ?n Unicode trư?c khi đi qua h? đ? OLE và đ?n chuy?n đ?i Unicode dây nh?n đư?c t? OLE đ? ANSI. Đi?u này đi?u đó ch?ng t? làm th? nào các chuy?n đ?i có th? đư?c th?c hi?n.

THÔNG TIN THÊM

Windows NT th?c hi?n Unicode (hay nhi?u k? t?) và ANSI Phiên b?n c?a Win32 ch?c năng mà ph?i m?t các thông s? chu?i. Tuy nhiên Windows 95 không th?c hi?n phiên b?n Unicode h?u h?t ch?c năng Win32 m?t chu?i các tham s?. Thay vào đó nó th?c hi?n ch? ANSI b?n này ch?c năng.

M?t ngo?i l? l?n cho quy t?c này là 32-bit OLE. 32-bit OLE API và s? d?ng phương pháp giao di?n trên Windows NT và Windows 95 Unicode đ?c quy?n. ANSI Phiên b?n c?a các ch?c năng này là không th?c hi?n ho?c trên Windows NT ho?c Windows 95.

Đi?u này có ngh?a là m?t ?ng d?ng 32-bit r?ng c?n ph?i ch?y trên c? Windows 95 và Windows NT ph?i s? d?ng phiên b?n ANSI c?a các phi - OLE Win32 ch?c năng và ph?i ANSI dây đ? chuy?n đ?i Unicode trư?c khi chúng thông qua v?i OLE.

M?t ?ng d?ng Unicode 32-bit ch? ch?y trên Windows NT c?n không s? d?ng b?t k? ch?c năng chuy?n đ?i ANSI/Unicode.

Win32 cung c?p MultiByteToWideChar và WideCharToMultiByte đ? chuy?n đ?i ANSI dây t?i Unicode và Unicode dây đ? ANSI. Bài vi?t này cung c?p AnsiToUnicode và UnicodeToAnsi, trong đó s? d?ng các ch?c năng này cho ANSI/Unicode chuy?n đ?i.
/*
 * AnsiToUnicode converts the ANSI string pszA to a Unicode string
 * and returns the Unicode string through ppszW. Space for the
 * the converted string is allocated by AnsiToUnicode.
 */ 

HRESULT __fastcall AnsiToUnicode(LPCSTR pszA, LPOLESTR* ppszW)
{

    ULONG cCharacters;
    DWORD dwError;

    // If input is null then just return the same.
    if (NULL == pszA)
    {
        *ppszW = NULL;
        return NOERROR;
    }

    // Determine number of wide characters to be allocated for the
    // Unicode string.
    cCharacters =  strlen(pszA)+1;

    // Use of the OLE allocator is required if the resultant Unicode
    // string will be passed to another COM component and if that
    // component will free it. Otherwise you can use your own allocator.
    *ppszW = (LPOLESTR) CoTaskMemAlloc(cCharacters*2);
    if (NULL == *ppszW)
        return E_OUTOFMEMORY;

    // Covert to Unicode.
    if (0 == MultiByteToWideChar(CP_ACP, 0, pszA, cCharacters,
                  *ppszW, cCharacters))
    {
        dwError = GetLastError();
        CoTaskMemFree(*ppszW);
        *ppszW = NULL;
        return HRESULT_FROM_WIN32(dwError);
    }

    return NOERROR;
/*
 * UnicodeToAnsi converts the Unicode string pszW to an ANSI string
 * and returns the ANSI string through ppszA. Space for the
 * the converted string is allocated by UnicodeToAnsi.
 */ 

HRESULT __fastcall UnicodeToAnsi(LPCOLESTR pszW, LPSTR* ppszA)
{

    ULONG cbAnsi, cCharacters;
    DWORD dwError;

    // If input is null then just return the same.
    if (pszW == NULL)
    {
        *ppszA = NULL;
        return NOERROR;
    }

    cCharacters = wcslen(pszW)+1;
    // Determine number of bytes to be allocated for ANSI string. An
    // ANSI string can have at most 2 bytes per character (for Double
    // Byte Character Strings.)
    cbAnsi = cCharacters*2;

    // Use of the OLE allocator is not required because the resultant
    // ANSI  string will never be passed to another COM component. You
    // can use your own allocator.
    *ppszA = (LPSTR) CoTaskMemAlloc(cbAnsi);
    if (NULL == *ppszA)
        return E_OUTOFMEMORY;

    // Convert to ANSI.
    if (0 == WideCharToMultiByte(CP_ACP, 0, pszW, cCharacters, *ppszA,
                  cbAnsi, NULL, NULL))
    {
        dwError = GetLastError();
        CoTaskMemFree(*ppszA);
        *ppszA = NULL;
        return HRESULT_FROM_WIN32(dwError);
    }
    return NOERROR;

}
				
M?u s? d?ng các ch?c năng này là như sau. CoTaskMemFree đư?c s? d?ng đ? mi?n phí chuy?n đ?i chu?i n?u CoTaskMemAlloc đư?c s? d?ng đ? phân b? các chu?i. Chu?i chuy?n đ?i không ph?i đư?c t? do n?u nó đư?c tr? v? thông qua m?t tham s? ra đ?n m?t OLE thành ph?n, v? thành ph?n đó là ch?u trách nhi?m v? gi?i phóng chu?i. LPOLESTR là m?t con tr? ch? t?i m?t Unicode chu?i.
// The following code gets an ANSI filename that is specified by the
// user in the OpenFile common dialog. This file name is converted into
// a Unicode string and is passed to the OLE API CreateFileMoniker. The
// Unicode string is then freed.

OPENFILENAME ofn;
LPOLESTR pszFileNameW;
LPMONIKER pmk;
:

// Get file name from OpenFile Common Dialog. The ANSI file name will
// be placed in ofn.lpstrFile

GetOpenFileName(&ofn);
:
AnsiToUnicode(ofn.lpstrFile, &pszFileNameW);
CreateFileMoniker(pszFileNameW, &pmk);
CoTaskMemFree(pszFileNameW);

// The following code implements IOleInPlaceFrame::SetStatusText.
// The lpszStatusText string, that is received from another OLE
// component, uses Unicode. The string is converted to ANSI before it is
// passed to the ANSI version of SetWindowText. Windows 95 supports only
// the ANSI version of SetWindowText.

COleInPlaceFrame::SetStatusText(LPCOLESTR pszStatusTextW)
{

    LPSTR pszStatusTextA;
    UnicodeToAnsi(pszStatusTextW, &pszStatusTextA);
    SetWindowText(m_hwndStatus, pszStatusTextA);
    CoTaskMemFree(pszStatusTextA);

}
				
LƯU ?: ? ki?n t?i AnsiToUnicode và UnicodeToAnsi liên quan đ?n các c?p phát đư?c s? d?ng đ? phân b? chu?i đư?c c?i bi?n. CoTaskMemAlloc (c?p phát OLE) đư?c yêu c?u đ? đư?c s? d?ng ch? khi chu?i k?t qu? s? đư?c thông qua v?i m?t OLE thành ph?n và n?u thành ph?n đó có th? gi?i phóng các chu?i. Này có ngh?a là chu?i đó đư?c thông qua như trong tham s? đ? OLE phương pháp giao di?n c?n không s? d?ng c?p phát OLE. Chu?i đư?c thông qua như là tham trong-ra-s? ho?c quay tr? l?i thông qua các tham s? ra ho?c trong – ra-tham s? ph?i đư?c c?p phát b?ng cách s? d?ng c?p phát OLE.

H?ng s? chu?i có th? đư?c chuy?n đ?i sang Unicode t?i th?i gian biên d?ch b?ng cách s? d?ng v? mô OLESTR. Ví dụ:
CreateFileMoniker(OLESTR("c:\\boo\\har.doc"), &pmk);
				
M?t ví d? khác c?a ANSI/Unicode thói quen chuy?n đ?i có th? đư?c t?m th?y trong các Microsoft n?n t?ng Classes (MFC) m? ngu?n mà tàu v?i các Visual C++ 4,0 biên d?ch. Nh?ng thói quen đư?c mô t? trong MFC Technote 59: 'B?ng cách s? d?ng MFC MBCS/Unicode chuy?n đ?i Macros'. Đ?nh ngh?a này macro OLE2T, T2OLE, OLE2CT, T2COLE, A2W, W2A, A2CW, W2CA và USES_CONVERSION là trong \msdev\mfc\include\afxpriv.h. C?ng xem AfxA2WHelper và AfxW2AHelper trong MFC ngu?n m? trong \msdev\mfc\src và s? d?ng OLE2T, T2OLE, OLE2CT và T2COLE trong MFC m? ngu?n trong \msdev\mfc\src. Các ch?c năng này cho phép m? biên so?n ho?c cho Unicode ho?c ANSI tùy thu?c vào vi?c _UNICODE preprocessor đ?nh ngh?a đ? đư?c th?c hi?n. Ví d?, CreateFileMoniker g?i trong các ? trên ví d? có th? đư?c th?c hi?n như sau v?i các macro MFC:
USES_CONVERSION;
GetOpenFileName(&ofn);
CreateFileMoniker(T2OLE(ofn.lpstrFile), &pmk);
				
N?u _UNICODE đư?c đ?nh ngh?a, T2OLE đư?c đ?nh ngh?a như sau:
inline LPOLESTR T2OLE(LPTSTR lp) { return lp; }
				
N?u _UNICODE không đư?c xác đ?nh, T2OLE đư?c đ?nh ngh?a như sau:
#define T2OLE(lpa) A2W(lpa)
				
T t?i T2OLE ch? ra r?ng lo?i đang đư?c chuy?n đ?i thành m?t chu?i OLE (Unicode chu?i) là m?t chu?i Unicode khi _UNICODE đư?c xác đ?nh và m?t ANSI chu?i khi _UNICODE không xác đ?nh. Tương t? như v?y LPTSTR đư?c đ?nh ngh?a là m?t con tr? đ?n m?t chu?i Unicode khi _UNICODE đư?c đ?nh ngh?a và như là m?t con tr? đ? m?t chu?i ANSI khi _UNICODE không xác đ?nh. T2OLE không làm b?t k? chuy?n đ?i khi _UNICODE đư?c đ?nh ngh?a (LPTSTR == LPOLESTR). Khi Unicode là không xác đ?nh, A2W đư?c g?i là. A2W chuy?n đ?i m?t chu?i ANSI t?i Unicode như sau:
#define A2W(lpa) (\ 
        ((LPCSTR)lpa == NULL) ? NULL : (\ 
            _convert = (strlen(lpa)+1),\ 
            AfxA2WHelper((LPWSTR) alloca(_convert*2), lpa, _convert)\ 
        )\ 

)
				
AfxA2WHelper s? d?ng MultiByteToWideChar đ? làm vi?c chuy?n đ?i.

MFC chuy?n đ?i macro s? d?ng _alloca đ? c?p phát v? tr? t? chương tr?nh ngăn x?p cho chu?i đư?c c?i bi?n. Không gian là t? đ?ng deallocated khi các cu?c g?i th? t?c đ? hoàn t?t. OLE đ?i h?i c?p phát OLE đ? đư?c s? d?ng cho t?t c? các dây (d? li?u) mà s? đư?c c?p phát b?i m?t trong nh?ng thành ph?n và t? do c?a ngư?i khác. Đi?u này có ngh?a r?ng dây qua ra- tham s? và thông trong-ra-s? lư?ng giao di?n OLE ph?i đư?c c?p phát v?i c?p phát OLE. Trong các tham s? không c?n đư?c giao v?i các OLE c?p phát b?i v? ngư?i g?i là trách nhi?m gi?i phóng chúng. H?u h?t Liên k?t/g?n OLE giao di?n và API vư?t qua chu?i như trong tham s?. K?t qu? là các macro MFC chuy?n đ?i có th? đư?c s? d?ng trong h?u h?t trư?ng h?p. Các MFC chuy?n đ?i macro không th? đư?c s? d?ng cho các tham s? trong ra ho?c tr? v? giá tr? thông qua các tham s? ra v? h? không phân b? v? tr? b?ng cách s? d?ng c?p phát OLE. AnsiToUnicode và UnicodeToAnsi có th? đư?c s? d?ng trong các trư?ng h?p.

Đư?c m?t t?p h?p các thói quen chuy?n đ?i Unicode/ANSI có th? đư?c t?m th?y trong Don H?p c?a c?t ngày OLE trong Microsoft Systems Journal, tháng 8 năm 1995, Vol. 10 S? 8 (trang 86). Don h?p đ?nh ngh?a m?t class C++ v?i m?t nhà đi?u hành di?n viên mà s? tr? v? m?t chu?i Unicode/ANSI chuy?n đ?i. Không gian đư?c phân b? là t? đ?ng gi?i phóng khi đ?i tư?ng đi ra kh?i ph?m vi. L?p này có th? S?a đ?i c?p phát b?ng cách s? d?ng c?p phát OLE và đ? không gi?i phóng các phân b? v? tr? cho dây đư?c truy?n thông qua trong ra ho?c ra- các tham s?.

M?t trong các l?p h?c, String16, t? Don h?p c?t mà chuy?n đ?i m?t ANSI chu?i t?i Unicode, sau. M?t l?p h?c, String8, mà là tương t? như đ? đi?u này đư?c dùng cho ANSI đ? chuy?n đ?i Unicode. Các CreateFileMoniker g?i t? các ví d? trư?c có th? đư?c th?c hi?n như sau v?i l?p này:
GetOpenFileName(&ofn);
CreateFileMoniker(String16(ofn.lpstrFile), &pmk);
				
Trong m? ? trên, m?t th? hi?n c?a String16 đư?c t?o ra. Các nhà xây d?ng l?p s? chuy?n đ?i chu?i ANSI t?i Unicode. Ngôn ng? th?c hi?n s? g?i cho các di?n viên đi?u hành, nhà đi?u hành const wchar_t *, boû tham s? này đ? lo?i c?a CreateFileMoniker đ?u tiên tham s?. Các nhà đi?u hành di?n viên s? tr? v? chu?i Unicode mà là đư?c thông qua đ? CreateFileMoniker. Các đ?i tư?ng s? hu? khi trong đi ra ph?m vi.
// String16 //////////////////////////////////////////////////////// 
// Shim class that converts both 8-bit (foreign) and
// 16-bit (native) strings to 16-bit wideness

class String16 {
public:

// native and foreign constructors
    String16(const char *p8);
    String16(const wchar_t *p16);

// non-virtual destructor (this class is concrete)

  ~String16(void);

// native conversion operator

  operator const wchar_t * (void) const;
private:

// native wideness string
    wchar_t *m_sz;
// is foreign??
    BOOL m_bIsForeign;

// protect against assignment!

  String16(const String16&);

    String16& operator=(const String16&);
};

// native constructor is a pass-through

inline String16::String16(const wchar_t *p16)
: m_sz((wchar_t *)p16), m_bIsForeign(FALSE)
{
}

// simply give out the native wideness string

inline String16::operator const wchar_t * (void) const
{
  return m_sz;
}

// foreign constructor requires allocation of a native
// string and conversion

inline String16::String16(const char *p8)
: m_bIsForeign(TRUE)
{

// calculate string length

  size_t len = strlen(p8);

// calculate required buffer size (some characters may
// already occupy 16-bits under DBCS)

  size_t size = mbstowcs(0, p8, len) + 1;

// alloc native string and convert

  if (m_sz = new wchar_t[size])

    mbstowcs(m_sz, p8, size);

}

// delete native string only if synthesized in foreign constructor

inline String16::~String16(void) {
  if (m_bIsForeign)

    delete[] m_sz;

}
				

Thu?c tính

ID c?a bài: 138813 - L?n xem xét sau cùng: 18 Tháng Tám 2011 - Xem xét l?i: 2.0
T? khóa: 
kbcode kbhowto kbprogramming kbmt KB138813 KbMtvi
Máy d?ch
QUAN TRỌNG: Bài vi?t này đư?c d?ch b?ng ph?n m?m d?ch máy c?a Microsoft ch? không ph?i do con ngư?i d?ch. Microsoft cung c?p các bài vi?t do con ngư?i d?ch và c? các bài vi?t do máy d?ch đ? b?n có th? truy c?p vào t?t c? các bài vi?t trong Cơ s? Ki?n th?c c?a chúng tôi b?ng ngôn ng? c?a b?n. Tuy nhiên, bài vi?t do máy d?ch không ph?i lúc nào c?ng hoàn h?o. Lo?i bài vi?t này có th? ch?a các sai sót v? t? v?ng, cú pháp ho?c ng? pháp, gi?ng như m?t ngư?i nư?c ngoài có th? m?c sai sót khi nói ngôn ng? c?a b?n. Microsoft không ch?u trách nhi?m v? b?t k? s? thi?u chính xác, sai sót ho?c thi?t h?i nào do vi?c d?ch sai n?i dung ho?c do ho?t đ?ng s? d?ng c?a khách hàng gây ra. Microsoft c?ng thư?ng xuyên c?p nh?t ph?n m?m d?ch máy này.
Nh?p chu?t vào đây đ? xem b?n ti?ng Anh c?a bài vi?t này:138813

Cung cấp Phản hồi

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com