NVARCHAR 리터럴의 N 프리픽스 누락으로 한글·이모지가 에러 없이 깨지는 문제

이 문서의 적용 조건

바로 실행할 수 있는 명령

-- 対象: SQL Server 2012 以降 / Azure SQL Database・Managed Instance
-- 権限: メタデータの参照はpublicロールで可。個々のデータ確認には対象テーブルのSELECT権限が必要
-- 変更作業: なし（参照のみ）
-- Production実行: 可能
-- 非ASCII文字を保持しうる nvarchar / nchar 列を一覧化する（調査対象の絞り込み用）
SELECT
    t.name AS table_name,
    c.name AS column_name,
    ty.name AS type_name,
    c.max_length
FROM sys.columns AS c
INNER JOIN sys.tables AS t
        ON t.object_id = c.object_id
INNER JOIN sys.types AS ty
        ON ty.user_type_id = c.user_type_id
WHERE ty.name IN ('nvarchar', 'nchar')
ORDER BY t.name, c.column_id;

# 対象: アプリケーション・ストアドプロシージャのソースコードリポジトリ
# 権限: リポジトリの読み取り権限
# 変更作業: なし（参照のみ）
# Production実行: 可能
#
# .sql ファイル内で、Nプレフィックスの無いシングルクォート文字列リテラルのうち
# 非ASCII文字を含むものを検出する（正規表現なので誤検知はあり、ヒット箇所は目視確認が前提）
grep -RnoP "(?<![Nn])'[^']*[^\x00-\x7F][^']*'" --include=*.sql .

# 文字列結合や sp_executesql で動的SQLを組み立てている箇所も洗い出す
grep -RniE "(sp_executesql|EXEC\(|exec\()" --include=*.sql --include=*.cs --include=*.ts .

이런 상황에서 사용합니다

• 한글·일본어·이모지가 포함된 데이터를 등록하면 에러는 없지만 저장 후 값이 "?"나 다른 문자로 바뀌어 있다
• 애플리케이션 테스트（ASCII만 있는 테스트 데이터）에서는 문제가 없고, 본 가동 이후나 실데이터 투입 후에야 발견된다
• 동적 SQL（문자열 결합이나 sp_executesql）을 거치는 쓰기 경로에서만 발생한다
• 한 번 "수정"했다고 생각한 코드베이스에서, 다른 위치·다른 프로젝트에서 같은 증상이 재발한다

가능한 원인(가능성이 높은 순)

1. 01

   문자열 리터럴이 연결의 기본 코드페이지로 암묵 변환된다

   N 프리픽스가 없는 단일 인용 문자열 리터럴은 먼저 non-Unicode 문자열로 해석되고, 연결의 기본 코드페이지로 변환된 후 NVARCHAR 타입에 대입됩니다. 그 코드페이지로 표현할 수 없는 문자는 변환 시 손실됩니다.

2. 02

   동적 SQL을 조립할 때 NVARCHAR를 의식하지 않고 문자열을 결합하고 있다

   문자열 결합이나 sp_executesql로 SQL문을 조립할 때, 삽입하는 값의 문자열 리터럴에 N 프리픽스를 빠뜨리기 쉽습니다. 특히 값이 파라미터가 아니라 문자열로 직접 삽입되는 경우에 자주 발생합니다.

3. 03

   에러도 경고도 없어 테스트에서 알아차리기 어렵다

   컴파일 에러도 런타임 에러도 발생하지 않기 때문에 ASCII만 있는 테스트 데이터로는 정상으로 보입니다. 실제 비ASCII 데이터가 들어가야 비로소 증상이 나타납니다.

4. 04

   한 번 손실된 문자는 독립된 출처가 없으면 복구할 수 없다

   암묵 변환으로 손실된 문자는 NVARCHAR 컬럼 안에 남아 있지 않습니다. 다른 시스템의 로그나 원본 데이터 백업 등 독립된 출처가 따로 없는 한, 이후에 정확한 값을 복원할 수 없습니다.

확인 절차

1. 1

   대상 테이블의 nvarchar/nchar 컬럼을 찾아낸다

   참조만

   위의 진단 SQL로 비ASCII 문자를 담을 수 있는 컬럼 목록을 만듭니다.

2. 2

   소스코드 내 N 프리픽스 누락을 검색한다

   참조만

   grep으로 의심되는 문자열 리터럴과 동적 SQL 조립 위치를 찾아내고 건별로 확인합니다.

3. 3

   기존 데이터의 손상 징후를 확인한다

   참조만

   원래 비ASCII여야 하는 컬럼에서 의도치 않은 문자로 바뀐 곳이 없는지 개별 확인합니다.

4. 4

   손상된 데이터의 독립된 출처가 있는지 확인한다

   참조만

   외부 시스템 로그나 다른 경로의 기록 등, 올바른 값을 가진 별도 정보원이 남아 있는지 확인합니다.

대응 방법

버전·환경에 따른 차이

이것으로 해결되지 않을 때 확인할 사항

• 자체 코드베이스에서 같은 패턴이 다른 곳에도 없는지 횡단 검색했는가

  한 곳만 고쳐서는, 같은 방식이 다른 저장 프로시저나 배치 처리에 남아 있을 수 있습니다.

• 손상이 의심되는 컬럼에 대해 독립된 출처가 따로 남아 있는가

  없다면 복구할 수 없다는 것을 전제로 앞으로의 운영을 설계합니다.

• 파라미터화된 쿼리 경로는 원래 이 문제의 영향을 받지 않는다

  ORM이나 드라이버의 파라미터 바인드를 쓰는 경로는 대상 외임을 확인하고 우선순위를 올바르게 판단합니다.

이 문서의 근거와 한계

자주 묻는 질문

이 문서가 다루는 질문

• SQL Server에서 한글이나 이모지가 깨지는 원인
• N 프리픽스 없는 SQL 문자열에서 무슨 일이 일어나는가

위험도 표시의 의미

• 참조만데이터와 설정을 변경하지 않습니다.
• 낮음영향은 제한적이지만 권한과 부하 확인이 필요합니다.
• 중간성능·락·비용에 영향을 줄 수 있습니다.
• 높음장애·데이터 손실·복구 작업이 발생할 수 있습니다.
• 전문가 검토 필수프로덕션 적용 전 별도 검토가 반드시 필요합니다.

GIIP의 대응 범위

GIIP에서는 신규로 추가하는 SQL 코드에 대해 N 프리픽스 누락을 기계적으로 탐지하는 체크를 리뷰 공정에 넣고 있습니다. 같은 패턴의 사고가 여러 프로젝트에서 형태를 바꿔 재발한 경험으로, 리뷰에서의 육안 확인만 의존하지 않고 기계적 탐지를 반드시 병용하는 방침입니다.

관련 서비스

• 文字化け・データ破損の調査を依頼する
• 本番投入前のレビュー体制を相談する