ギリシャ語のテキスト行をnvarchar(2000)
で埋めたテーブルがありました。
最近、列のタイプをvarchar(4000)
に変更しましたが、いくつかのギリシャ文字が疑問符として表示されていることに気付きました。
それで、文字のユニコードが同じままであると思うので、それを修正するためにnvarchar(4000)
に変更してみました。
テーブルを変更する前に作成したバックアップを復元する代わりにこれを修正する方法はありますか?
いいえ、データが存在しないため、データを「修正」する方法はありません。 VARCHAR
に変換すると、各文字の基になる値がASCII ?
。これは表示の問題ではなく、これらの文字は物理的に通常の疑問符になっています。残念ながら、バックアップから復元する必要があります。
次のコード例は、Unicode文字がVARCHAR
に変換されると(照合で示されるコードページがその文字をサポートしていないと仮定して)、通常の 'ol疑問符になり、永久に残ることを示しています。など:
DECLARE @Character NCHAR(1) = NCHAR(0x3525);
SELECT @Character AS [TheCharacter],
UNICODE(@Character) AS [DecimalCodePoint],
ASCII(@Character) AS [DecimalValueOfVarchar],
UNICODE(CONVERT(VARCHAR(5), @Character)) AS [ConvertToVarchar],
UNICODE(CONVERT(NVARCHAR(5), CONVERT(VARCHAR(5), @Character)))
AS [ConvertToVarcharAndBack],
ASCII('?') AS [VarcharQuestionMark],
UNICODE(N'?') AS [UnicodeQuestionMark];
-- 㔥 13605 63 63 63 63 63
次の例は、ほとんどのフォントでサポートされることが(少なくとも現時点では)疑わしいUnicode文字のインスタンスを示しています。したがって、はとして表示されます。正方形のボックスですが、UNICODE
組み込み関数は、基になるコードが正しいUnicodeコードポイントであることを示しています。
SELECT NCHAR(0xABBF), N'ꮿ', UNICODE(N'ꮿ');
-- ꮿ ꮿ 43967
実際の文字はここで見ることができます: チェロキー小文字YA U + ABBF 。 これは表示の問題であり、さまざまなフォントで表されていない多くの文字は、文字の実際の値を変更せずに同じ方法で表示されますが、彼らはまだ別個の文字です。
カンニングの方法を探していましたが、srutzkyが正しいようです。以下は、根本的なデータ変更を証明する(私が思う)スクリプトです。
--build and populate table
IF OBJECT_ID('tempdb..#t') IS NOT NULL
DROP TABLE #t
CREATE TABLE #t
(txt nvarchar(1))
INSERT #t
VALUES
(N'Γ')
--show how it's stored
SELECT txt,CONVERT(varbinary,txt)
FROM #t
--Alter and show
ALTER TABLE #t
ALTER COLUMN txt varchar(2)
SELECT txt,CONVERT(varbinary,txt)
FROM #t
--And again
ALTER TABLE #t
ALTER COLUMN txt nvarchar(1)
SELECT txt,CONVERT(varbinary,txt)
FROM #t