문제

Trichedit 및 Tlmdrichedit을 사용하여 편집 한 RTF를 많이 사용하는 Delphi 2009에서 응용 프로그램을 진행하고 있습니다. 이 RTF 컨트롤에서 일본어 텍스트를 입력 한 사용자는 동부 언어 지원이 설치된 Win XP 및 Vista에 컨텐츠를 다시로드 할 때 일본어 텍스트가 gribberish로 표시되는 간헐적 보고서를 제출하고 있습니다.

일반적으로 영어와 일본어는 혼합되어 있으며 대부분 문제없이 표시됩니다.

Inventory turns partnerships.  在庫回転率の

(일본어 텍스트가 잘못 부러지면 사과합니다. 언어를 말하거나 읽지 않습니다).

그러나 텍스트의 일본어 부분만이 횡설수설이 될 것입니다.

ŒÉñ?“]-¦Œüã‚Ì·•Ê‰?-vˆö‚ðŽû‰v‚ÉŒø‰?“I‚ÉŒ‹‚т‚¯‚é’mŽ¯‚ª‘÷Ý‚·‚é?(マーケットセクター、
見込み客の優  先順位と彼らに販売する知識)

광범위한 온라인 검색에서 문제는 RTF의 일부로 저장된 글꼴의 결과 인 것으로 보입니다. 일본어 버전의 Windows에 존재하는 글꼴은 반드시 미국 영어 버전과 동일하지는 않습니다. RTF 파일의 글꼴을 프로그래밍 방식으로 교체 할 수있어 거의 허용되는 결과를 얻을 수 있습니다.

-D‚‚スƒIƒyƒŒ[ƒVƒ・“‚ニƒƒWƒXƒeƒBƒbƒN‚フƒpƒtƒH[ƒ}ƒ“ƒX‚-˜‰v‚ノŒ‹‚ム‚ツ‚ッ‚ネ‚「‚±ニ‚ヘ?A‘‚「‚ノ-ウ‘ハ‚ナ‚ ‚驕B‚サ‚‚ヘAl“セ‚オ‚ス・‘P‚フˆロ‚ƒƒXƒN‚ノ‚ウ‚‚キB

그러나 일본어로 올바르게 인식되지 않은 "정크"캐릭터가 여전히 꽤 많이 있습니다. 원시 RTF를 보면 다음이 표시됩니다.

-D\'82\'82\u65405?\'83I\'83y\'83\'8c[\'83V\'83\u12539?\ldblquote\'82\u65414?

분명히, 유니 코드 문자는 올바르게 렌더링되지만 예를 들어 '82 '82 문자 쌍은 다른 것이되어야합니까? 내 생각에 그것은 실제로 일종의 이중 바이트 캐릭터를 나타내는 것입니다. 단일 유니 코드 문자보다는 두 개의 별도 문자로 인코딩 된 신비한 이유가있었습니다.

동부 언어를 포함하는 RTF를 가져 와서 다시 표시하는 일반적인 (비교적) (비교적) 완벽한 방법이 있습니까?

완전성을 위해 RTF 글꼴 테이블을 다음과 같이 업데이트했습니다.

  • 글꼴 이름 "? l? r? o? s? v? b? n;" " '82 '6c '82 '72 '82 '6f '83 '53 '83 '56 '83 '62 '83 '4e;"
  • " Froman fprq1 fcharset0"을 " fnil fprq1 fcharset128"으로 대체하여 업데이트 된 글꼴 이름
  • " from fprq1 fcharset238"을 " fnil fprq1 fcharset128"으로 바꾸어 업데이트 된 글꼴 이름
  • " froman fprq1"을 " fnil fprq1 fcharset128"으로 대체하여 업데이트 된 글꼴 이름
  • 글꼴 이름 대체 "??????;" " '82 '6c '82 '72 '82 '6f '83 '53 '83 '56 '83 '62 '83 '4e;"

업데이트 : 글꼴 이름 만 업데이트하면 차이가 없습니다. 로케일은 큰 문제인 것 같습니다. 나는 일본 RTF의 디스플레이를 대부분의 독자가 처리 할 수있는 것으로 변환하는 방법에 관한 몇 가지 사이트를 보았지만 아직 해결책을 찾지 못했습니다. 예를 들어보십시오.여기 그리고 여기.

도움이 되었습니까?

해결책

내 생각에 RTF에서 글꼴 이름을 바꾸면 아마도 상황이 악화되었을 것입니다. RTF에 지정된 글꼴이 유니 코드 글꼴이 아닌 경우, 해당 글꼴로 렌더링 될 문자는 유니 코드가 아닌 Shift-JI로 인코딩됩니다. 그러면 텍스트의 다른 문자도 마찬가지입니다. 따라서 모든 것을 유니 코드로 취급하거나 유니 코드 텍스트를 추가하면 부패가 발생합니다. 가져 오는 RTF가 인코딩 된 Shift-Jis 또는 Unicode인지 여부와 실행중인 시스템 (따라서 D2009 기본 입력 형식)이 일본인인지 아닌지를 설정해야합니다. 일본에서는 텍스트 파일에 유니 코드 BOM이없는 경우 일반적으로 Shift-JIS (항상 그런 것은 아닙니다).

다른 팁

나는 비슷한 것을보고 있었지만 일본 글꼴은 아닙니다. 마이크로 (마이크로 리터에서와 같이) 및 슈퍼 스크립트와 같은 특수 문자 만 있습니다. 문제는 내가 ASP.NET 웹 페이지에서 사용자에게 보내는 RTF 문자열이 정확했지만 (Fiddler2를 사용하여 인코딩 된 RTF 스트림을 볼 수 있음) MS Word가 실제로 RTF를 열었을 때, 가비지 탈출을 추가했다는 것입니다. 샘플에서 볼 수있는 코드.

내가 한 일은 ASCII 127의 모든 문자를 특수 유니 코드 포인트로 교체하는 변환 루틴을 통해 전체 RTF 텍스트를 실행하는 것이 었습니다. 그래서 uc1 u181과 같은 것을 얻을 수 있습니까? 특수 문자의 경우 (마이크로). 내가 그렇게했을 때, Word는 파일을 열 수 없었습니다. 아이러니하게도, 그것은 uc1 uxxx를 다시 인코딩 했습니까? 그들의 RTF로 돌아가서 당당한 동등한 수준으로 돌아갑니다.

Private Function ConvertRtfToUnicode(ByVal value As String) As String

    Dim ch As Char() = value.ToCharArray()
    Dim c As Char
    Dim sb As New System.Text.StringBuilder()
    Dim code As Integer

    For i As Integer = 0 To ch.Length - 1
        c = ch(i)
        code = Microsoft.VisualBasic.AscW(c)
        If code <= 127 Then
            'Don't need to replace if one of your typical ASCII codes
            sb.Append(c)
        Else
            'MR: Basic idea came from here http://www.eggheadcafe.com/conversation.aspx?messageid=33935981&threadid=33935972
            '  swaps the character for it's Unicode decimal code point equivalent
            sb.Append(String.Format("\uc1\u{0:d}?", code))
        End If
    Next

    Return sb.ToString()

End Function

그것이 당신의 문제에 도움이 될지 확실하지 않지만 그것은 나를 위해 일하고 있습니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top