Kopiera emojis i text från MySQL till SQL Server

Unicode-kodpunkten för tecknet 🤘 är U+1F918 , vilket betyder att det är utanför Basic Multilingual Plane (BMP) för Unicode, som täcker kodpunkter upp till U+FFFF.

För att behandla Unicode-tecken utanför BMP måste du använda kollationer som stöder tilläggstecken , namngiven som *_SC :

Jämför resultaten av denna SQL-sats

select 
    nchar(unicode(N'🤘' collate Latin1_General_100_CI_AS_SC)) as EmojiSC, 
    unicode(N'🤘' collate Latin1_General_100_CI_AS_SC) as EmojiSCUnicode, 
    cast(N'🤘' as varbinary) as EmojiBinary, 
    cast(nchar(unicode(N'🤘')) as varbinary) as EmojiConvBinary,
    unicode(N'🤘') as EmojiUnicode

som körs mot en databas med Latin1_General_CI_AS

EmojiSC EmojiSCUnicode  EmojiBinary EmojiConvBinary EmojiUnicode
NULL    129304          0x3ED818DD  0x3ED8          55358

kontra en databas inställd på Latin1_General_100_CI_AI_SC

EmojiSC EmojiSCUnicode  EmojiBinary EmojiConvBinary EmojiUnicode
🤘      129304          0x3ED818DD  0x3ED818DD      129304

Varför ser du "🤘 "?

UTF-8-kodningen för U+1F918 är 0xF0 0x9F 0xA4 0x98 , och tecknen är resultatet av att tolka dessa koder som ANSI-tecken .

Varför ser du "�"?

Tecknet � är Unicode ERSÄTTNINGSKARAKTER och är

och det beror på att U+D83E är inte en giltig Unicode-kodpunkt , men det första ordet i kodpunkten kodat som UTF-16 (0xD83E 0xDD18 ).

Kontrollera vad som lagras, inte vad som visas

Att visa Unicode-data kan vara knepigt, och det mest effektiva sättet att ta reda på vad som händer under huven är att titta på byten. I TSQL, använd cast(... as varbinary) för att analysera var Unicode-datamanipulation går fel.