내 생각에 당신은 고전적인 형태의 글자 인코딩 불일치 문제에 빠져들고 있습니다.
그것은 이렇게 가고 : -
- 당신은 UTF-8 인코딩을 사용하여 클라이언트에게 제공되는 형태를 갖는다.
- 결과적으로 브라우저는 UTF-8 인코딩을 사용하여 양식에 입력 된 텍스트 값을 게시합니다.
- 게시물을받는 작업 페이지의 Response.Codepage가 일반적인 OEM 코드 페이지 (예 : 1252
- )로 설정되어 있습니다. 게시 된 UTF-8 문자열의 각 바이트는 UTF 집합을 디코딩하지 않고 서버에 의해 개별 문자로 처리됩니다 -8 인코딩 된 바이트를 올바른 유니 코드 문자로 바꿉니다.
- 문자열이 현재 손상된 문자로 DB에 저장됩니다.
- 페이지가 손상된 문자가 들어있는 DB 필드의 내용을 클라이언트에 제공하려고합니다.
- 페이지는 CharSet를 UTF-8로 설정하지만 Response.CodePage는 1252와 같은 OEM 코드 페이지에 남아 있습니다.
- Response.Write는 클라이언트로 필드 내용을 보내는데 사용되며 유니 코드 문자는 byte 세트의 바이트는 청취자 포스트에서 수신되었다.
- 클라이언트는 UTF-8을 얻는다고 생각하기 때문에 서버에서 수신 한 문자를 UTF-8로 원래의 것과 같이 디코딩하므로 제대로 표시됩니다.
- ASP를 통해 앞뒤로 튀어 오르는 것처럼 모든 것이 정상인 것처럼 모든 것이 잘 진행됩니다. 한 페이지의 버그는 다른 페이지 (동일한 페이지 일 수 있음)에서 일치하는 버그가있어 모든 것을 멋지게 만듭니다.
SQL 서버 도구로 필드 내용을 직접 검사하면 손상된 문자열이 나타날 수 있습니다. 이제이 문자열을 직선적 인 유니 코드 문자열을 기대하는 다른 구성 요소와 함께 사용하려는 경우가 있으므로이 버그를 발견 할 수 있습니다.
해결책은 모든 페이지가 응답에서 CharSet = "UTF-8"을 전송할뿐만 아니라 Response.CodePage = 65001을 사용하여 Response.Write를 사용하고 Request.Form 값을 읽으려고 시도하기 전에 사용하는 것입니다. < % @ 페이지 헤더의 Codepage 지시문을 사용하십시오.
이제 DB에 손상된 문자열을 복구해야합니다.
ADODB를 사용하십시오.스트림 : -
Function ConvertFromUTF8(sIn)
Dim oIn: Set oIn = CreateObject("ADODB.Stream")
oIn.Open
oIn.CharSet = "WIndows-1252"
oIn.WriteText sIn
oIn.Position = 0
oIn.CharSet = "UTF-8"
ConvertFromUTF8 = oIn.ReadText
oIn.Close
End Function
이 기능 (BTW 실제 질문에 대한 답변입니다) 손상된 문자열이 있었어야 문자열로 변환 (바이트 표현의 바이트를 가지고 하나)합니다. 버그의 피해를 입은 DB의 모든 필드에이 변환을 적용해야합니다.
-1 이것은 ASP.NET이 아닌 고전적인 ASP입니다. –