[MSSQL] MSSQL에서 윈도우 이모지가 깨져서 나오는 문제 해결하기

DBMS/MSSQL

Doshisha 2022. 11. 7. 12:23

개요

이번 글에서는 MSSQL에서 테이블에 윈도우 이모지 값이 삽입되었을 때 깨져보이는 것을 해결하는 방법에 대해 이야기해 보려고 한다.

사내 웹 운영툴을 Spring에 MySQL과 SQL Server을 같이 사용하여 운영하고 있는데

게임 사업실로부터 운영툴에서 게임 커뮤니티의 카테고리 이름에 윈도우 이모지를 넣어서 새로 등록하면 해당 이모지가 등록 시에 사라진다는 이슈를 전달받았다.

해당 카테고리 등록 API를 확인해 보니 SQL Server와 커넥션이 일어나는 API인 것을 확인하고 카테고리 테이블의 카테고리 이름 컬럼의 데이터 형식을 살펴보았다.

역시나 해당 컬럼의 데이터 형식은 varchar로 구성되어 있었다.

예를 들어 아래와 같이 말이다.

CREATE TABLE [dbo].[카테고리](
	[id] [int] IDENTITY(1,1) NOT NULL,
	[category_name] [varchar](32) NOT NULL
) ON [PRIMARY]
GO

varchar는 기본적인 영문 데이터형, 테이블에 설정된 기본 언어 타입까지 저장 지원하기에 윈도우 이모지나 한자, 특수문자가 깨지는 문제가 발생할 수 있다.

이번 사례와 비슷한 문제가 발생하는 컬럼의 데이터 타입을 확인해 보면 전체 범위의 유니코드 문자 저장을 지원하지 않는 VARCHAR, TEXT 등을 사용하고 있을 것이다.

ALTER TABLE [테이블명] ALTER COLUMN [컬럼명] NVARCHAR NOT NULL

최종적으로는 운영툴 DB의 문제가 발생하는 컬럼의 데이터 타입을 NVARCHAR로 수정하여 이슈를 해결할 수 있었다.

NVARCHAR, NTEXT는 모든 범위의 유니코드 데이터를 저장할 수 있기 때문에 윈도우 이모지 또한 정상적으로 저장할 수 있게 되었다.

UPDATE [테이블명] SET [컬럼명] = N'😁💕🎶😒'

DBMS에서 직접 쿼리를 실행하여 확인해 보고 싶다면 데이터 앞에 접두사 'N'을 붙여 유니코드 문자열임을 명시하고 쿼리를 실행하면 정상적으로 이모지가 저장되는 것을 확인할 수 있다.

만약 접두사 'N'을 붙이지 않고 사용한다면 문자열은 ASCII 문자로 처리되며 유니코드 문자의 일부가 손실될 수 있다.

하지만 컬럼의 데이터 형식을 변환할 때 고려해야 하는 부분이 생긴다.

기본적으로 nvarchar는 varchar에 비해 저장 공간이 커 DB의 크기 및 성능에 영향을 미칠 수 있어 데이터 형식을 변환했을 때 생길 수 있는 DB 성능 저하에 대한 충분한 확인 및 테스트가 필요하며 현재 서비스에 영향을 미치지 않도록 해야 한다.

반대로 nvarchar를 varchar로 변환하는 경우에는 유니코드 문자가 손실될 수 있는 문제가 생긴다.

또한 varchar를 text로 변환했을 때 인덱스가 타지 않아 DB 성능 저하를 야기할 수 있듯이

데이터 형식의 변환을 고려할 때 각 데이터 형식의 특징을 잘 살펴보고 충분한 테스트 후에 서비스에 문제가 생기지 않도록 하자.