# 카테고리 페이지에서 이상한 인코딩 문제 발생
**URL:** https://meta.discourse.org/t/weird-encoding-issue-on-categories-page/345490
**Category:** Support
**Tags:** unsupported-install
**Created:** [1월 3, 2025, 8:10오후 UTC](https://meta.discourse.org/t/weird-encoding-issue-on-categories-page/345490 "2025-01-03T20:10:08Z")
**Posts on this page:** 16
**Page:** 1
### Author:  [@hendersj](https://meta.discourse.org/u/hendersj)
#### Post date: [1월 3, 2025, 8:10오후 UTC](https://meta.discourse.org/t/weird-encoding-issue-on-categories-page/345490/1 "2025-01-03T20:10:08Z")
Docker를 사용하지 않는 설치 환경에서 이상한 문제를 추적하고 있습니다. (이 유형의 설치에 대한 지원이 제한적이거나 사실상 없다는 점은 인지하고 있으므로, 여기서 무엇이 문제일 수 있는지에 대한 힌트만 부탁드립니다. 저희 내부 패키징 팀은 ‘개발자 빌드’ 지침을 참고하여 필요한 패키지를 빌드하는 방법을 파악했습니다.) 설치 방식에 따라 문제가 발생하는 것을 확인했습니다. 인프라 팀은 Docker 기반 설치를 꺼려하고(모든 것을 직접 빌드하기를 선호합니다) 있으므로, 데이터베이스 사본을 가진 Docker 기반 및 비-Docker 기반 샌드박스 인스턴스를 실행하여 문제가 어디서 발생하는지 검증하고 있습니다. 이는 분명히 저희가 세트를 설치한 방식에서 비롯된 결과입니다.
3.3.2에서 3.3.3으로 업그레이드한 후, 영어가 아닌 언어를 사용하는 포럼 스태프 일부가 악센트 문자가 포함된 섹션의 ‘정보(About)’ 텍스트가 올바르게 인코딩되지 않는 것을 발견했습니다:
흥미롭게도, 제목을 포함한 모든 다른 텍스트는 올바르게 인코딩되어 있습니다. 실제로 ‘정보’ 메시지에 사용되는 메시지 자체도 올바르게 인코딩되어 있습니다:
카테고리 페이지에서 변경 사항을 확인하며 해당 텍스트를 편집함으로써 이것이 동일한 텍스트임을 확인했습니다.
즉, 이는 카테고리 페이지에서 해당 텍스트를 렌더링하는 방식과 관련된 특정 문제입니다.
브라우저에서 `document.characterSet`을 확인해 보니 UTF-8으로 올바르게 식별되고 있습니다. 데이터베이스에서도 포맷이 UTF-8으로 표시되고 있습니다.
이 텍스트가 카테고리 페이지에서 어떻게 렌더링되는지에 대해 무엇이 다른지 알려줄 수 있는 분이 있을까요? 제 추측으로는, 시스템의 다른 텍스트에는 사용되지 않지만 이 텍스트 렌더링에 사용되는 루비(ruby) 패키지가 제대로 빌드되지 않았거나(UTF-8 지원 누락 가능성) 또는 정보 메시지 텍스트를 처리하고 잘라내는(이 경우 실제로 잘라져 있는 것을 확인했습니다. 그러나 잘라지지 않은 외부 프랑스어 포럼 링크도 동일한 코드로 평가되는 것으로 추정됩니다) 어떤 요소가 문제일 것 같습니다.
힌트를 주시면 감사하겠습니다. 좀 막막한 상태입니다.
---
### Author:  [@supermathie](https://meta.discourse.org/u/supermathie)
#### Post date: [1월 3, 2025, 8:22오후 UTC](https://meta.discourse.org/t/weird-encoding-issue-on-categories-page/345490/2 "2025-01-03T20:22:47Z")
가끔은 올바르게 표시되는 것을 볼 수 있습니다:
원본 categories.json을 확인해 보면, 발췌문(excerpt)에서만 오류가 나는 것을 알 수 있습니다:
```plaintext
"description": "Esta sección del Foro se dedica a las personas usuarias de openSUSE que forman parte de la comunidad lingüística castellana, de tal forma que dichas personas puedan consultar y participar en el foro en dicha lengua (sea el dialecto español o cualquiera de las variedades latinoamericanas, etc.).",
"description_text": "Esta sección del Foro se dedica a las personas usuarias de openSUSE que forman parte de la comunidad lingüística castellana, de tal forma que dichas personas puedan consultar y participar en el foro en dicha lengua (sea el dialecto español o cualquiera de las variedades latinoamericanas, etc.).",
"description_excerpt": "Esta sección del Foro se dedica a las personas usuarias de openSUSE que forman parte de la comunidad lingüÃstica castellana, de tal forma que dichas personas puedan consultar y participar en el foro en dicha lengua (sea el dialecto español o cualquiera de las variedades latinoamericanas, etc.).",
```
try.discourse.org에서 동일한 카테고리를 생성하고 categories.json을 확인하면 올바른 결과가 나옵니다:
```plaintext
"description": "Esta sección del Foro se dedica a las personas usuarias de openSUSE que forman parte de la comunidad lingüística castellana, de tal forma que dichas personas puedan consultar y participar en el foro en dicha lengua (sea el dialecto español o cualquiera de las variedades latinoamericanas, etc.).",
"description_text": "Esta sección del Foro se dedica a las personas usuarias de openSUSE que forman parte de la comunidad lingüística castellana, de tal forma que dichas personas puedan consultar y participar en el foro en dicha lengua (sea el dialecto español o cualquiera de las variedades latinoamericanas, etc.).",
"description_excerpt": "Esta sección del Foro se dedica a las personas usuarias de openSUSE que forman parte de la comunidad lingüística castellana, de tal forma que dichas personas puedan consultar y participar en el foro en dicha lengua (sea el dialecto español o cualquiera de las variedades latinoamericanas, etc.).",
```
귀하의 설치 환경에서 이 문제를 추적하기 위한 다음 단계가 무엇인지 확실하지 않지만, 발췌문을 생성하는 코드 경로에 집중하면 도움이 될 수 있습니다. 또한 이 문제가 UTF-8 인코딩이 iso-8859-1로 해석되는 과정에서 발생했다는 점을 아는 것도 중요합니다.
---
### Author:  [@hendersj](https://meta.discourse.org/u/hendersj)
#### Post date: [1월 3, 2025, 8:29오후 UTC](https://meta.discourse.org/t/weird-encoding-issue-on-categories-page/345490/3 "2025-01-03T20:29:35Z")
네, 저도 그렇게 추측했어요. 발췌문을 생성하는 곳이 바로 적절한 장소일 가능성이 높거든요. 다만 그게 코드 어디에 있는지 확실하지는 않아요. 그래도 "excerpt"이라는 용어를 찾아봐야 한다는 걸 알게 된 건 확실히 도움이 되네요. 감사합니다!
어떤 시점에서 iso-8859-1로 넘어오는 것처럼 보였거든요. 그래서 그 확인도 감사해요. (제가 보고 있던 인코딩 오류가 바로 그것인지 100% 확신은 없었지만, 그럴 것 같았거든요.)
try.discourse.org에서 보신 내용은 제 도커 기반 설치 환경에서도 동일하게 확인되었습니다. (아, 인코딩이 올바르게 처리된 최종 결과는요 🙂 )
감사합니다!
---
### Author:  [@supermathie](https://meta.discourse.org/u/supermathie)
#### Post date: [1월 3, 2025, 8:33오후 UTC](https://meta.discourse.org/t/weird-encoding-issue-on-categories-page/345490/4 "2025-01-03T20:33:28Z")
> [@hendersj](#):
>
> 내가 본 것이 그 잘못된 인코딩이 맞는지는 100% 확신하지 못했지만, 그럴 것 같았다
아래와 같이 쉽게 확인할 수 있습니다:
```plaintext
○ → ipython3
In [1]: 'Esta sección del Foro se dedica a las personas usuarias de openSUSE que forman parte de la comunidad lingüística castellana
...: , de tal forma que dichas personas puedan consultar y participar en el foro en dicha lengua (sea el dialecto español o cualq
...: uiera de las variedades latinoamericanas, etc.).'.encode('utf-8').decode('iso-8859-1')
Out[1]: 'Esta sección del Foro se dedica a las personas usuarias de openSUSE que forman parte de la comunidad lingüÃ\xadstica castellana, de tal forma que dichas personas puedan consultar y participar en el foro en dicha lengua (sea el dialecto español o cualquiera de las variedades latinoamericanas, etc.).'
```
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [1월 3, 2025, 8:54오후 UTC](https://meta.discourse.org/t/weird-encoding-issue-on-categories-page/345490/5 "2025-01-03T20:54:59Z")
어떤 종류의 캐싱이 이루어지고 있을 것 같습니다. 큰 도움이 되지는 않지만, 제가 먼저 확인해 볼 부분은 바로 그 부분입니다.
Docker를 싫어하는 것이 아니라면, [discourse\_docker](https://github.com/discourse/discourse_docker/tree/main/image)를 사용하여 자체 이미지를 빌드할 수 있습니다. 그러면 정확히 어떤 일이 일어나는지 직접 확인할 수 있고, 다른 사람의 이미지를 신뢰할 필요가 없습니다.
---
### Author:  [@hendersj](https://meta.discourse.org/u/hendersj)
#### Post date: [1월 3, 2025, 9:46오후 UTC](https://meta.discourse.org/t/weird-encoding-issue-on-categories-page/345490/6 "2025-01-03T21:46:28Z")
> [@supermathie](#):
>
> 다음 방법으로 쉽게 확인할 수 있습니다:
>
> ```plaintext
> ○ → ipython3
>
> In [1]: 'Esta sección del Foro se dedica a las personas usuarias de openSUSE que forman parte de la comunidad lingüística castellana
> ...: , de tal forma que dichas personas puedan consultar y participar en el foro en dicha lengua (sea el dialecto español o cualq
> ...: uiera de las variedades latinoamericanas, etc.).'.encode('utf-8').decode('iso-8859-1')
> Out[1]: 'Esta sección del Foro se dedica a las personas usuarias de openSUSE que form
>
> ```
좋네요, 알려주셔서 감사합니다.
> [@pfaffman](#):
>
> 제 추측으로는 어떤 종류의 캐싱이 일어나고 있는 것 같습니다. 큰 도움이 되지는 않지만, 제가 먼저 찾아볼 부분입니다.
그렇지 않을까 생각했지만, 메시지를 변경하자 업데이트가 이루어졌으므로 캐싱 문제는 아닌 것 같습니다. 인코딩이 잘못되고 있는 것 같습니다.
> [@pfaffman](#):
>
> Docker를 싫어하는 것이 아니라면, [discourse\_docker](https://github.com/discourse/discourse_docker/tree/main/image)를 사용하여 자체 이미지를 빌드할 수 있습니다. 그러면 정확히 어떤 일이 일어나고 있는지 직접 확인할 수 있고, 다른 사람의 이미지를 신뢰할 필요가 없습니다.
몇 가지 옵션을 제안했지만, 결국 인프라 팀은 빌드 서비스로 빌드된 패키지를 사용하는 쪽으로 결정했습니다. "우리는 Docker를 싫어한다"는 식의 문제는 아닌 것 같습니다(물론 podman을 사용하려는 경향이 더 클 수는 있지만), 더 정확히 말하면 현재 사용 중인 구성 관리 도구를 사용하여 모든 것을 동일한 방식으로 관리하려는 방식입니다. Docker/podman을 사용하는 일회성 설치는 그들이 사용하는 CI/CD 설정에 다른 복잡성을 더할 수 있다고 이해하고 있습니다.
결국, 저는 문제를 보고하기 위해 문제가 어디에서 비롯되었는지 파악할 수 있도록 두 개의 샌드박스를 설정했습니다. 불행히도, 이는 우리가 빌드한 방식에 문제가 있는 경우, 표준 Docker 기반 설치와 우리가 다르게 처리하고 있는 부분을 찾아내어 수정해야 함을 의미합니다.
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [1월 3, 2025, 10:00오후 UTC](https://meta.discourse.org/t/weird-encoding-issue-on-categories-page/345490/7 "2025-01-03T22:00:04Z")
> [@hendersj](#):
>
> 하지만 그들이 사용하는 구성 관리 도구를 사용하여 모든 것을 동일한 방식으로 관리하는 방법에 가깝습니다. Docker/podman을 사용하는 일회성 설정은 그들이 사용하는 CI/CD 설정을 사용하는 데 다른 복잡성을 더하게 될 것입니다(그렇게 이해하고 있습니다).
그들이 _Discourse 방식_이 미친 짓이라고 생각하며 모든 것을 하나의 통합 시스템 하에서 관리하기를 정말로 원한다는 점은 이해합니다.
하지만요. 마지막으로 제가 일했던 고객 중 자신들이 좋아하는 도구를 사용하겠다고 고집했던 고객은 [discourse.org](http://discourse.org) 호스팅으로 이전할 수 있는 사용 가능한 백업을 만드는 데 거의 20시간의 작업 비용을 지불했습니다. 그 이전 고객은 사이트가 주에 여러 번 충돌하지 않도록 커스텀 설정을 조정하는 데 훨씬 더 많은 돈을 지불했고, 1년 후에는 [discourse.org](http://discourse.org) 호스팅으로 이전하는 데 또 다시 더 많은 비용을 지불했습니다. 🙂
행운을 빕니다!
---
### Author:  [@hendersj](https://meta.discourse.org/u/hendersj)
#### Post date: [1월 3, 2025, 10:23오후 UTC](https://meta.discourse.org/t/weird-encoding-issue-on-categories-page/345490/8 "2025-01-03T22:23:41Z")
조언에 감사드립니다. 좋은 소식은 프로덕션 시스템의 백업이 Docker화 된 설치 환경에서도 문제없이 작동한다는 점입니다(직접 테스트해 보았습니다). 따라서 Docker 기반 설치가 올바른 방향이라고 판단될 경우, 우리는 좋은 상태에 있을 것입니다. 우리는 상당량의 데이터를 보유하고 있으며(몇 년 전 vBulletin에서 Discourse로 마이그레이션했습니다) 전반적으로 잘 작동해 왔지만, 간혹 작은 문제들이 발생하기도 했습니다.
결국, 우리는 Discourse가 어떻게 작동하는지에 대해 많은 것을 배웠으므로 전반적으로 나쁜 일은 아니었습니다. 🙂
`/categories.json`은 정적 파일이 아니라 API 엔드포인트로 보입니다. 이는 문제를 Ruby 또는 JavaScript 중 하나로 제한하는 데 도움이 될 것 같습니다. 해당 엔드포인트의 스키마 위치는 찾았지만, Ruby에는 특히 익숙하지 않습니다(수년에 걸쳐 많은 프로그래밍 언어 경험을 쌓아왔기 때문에 코딩은 못 하더라도 대부분의 언어를 읽는 데는 문제가 없으며, 대략적인 내용은 쉽게 파악할 수 있습니다). JavaScript는 주로 브라우저에서 실행되고, Ruby는 서버에서 실행되는 것으로 보입니다(다만 nodejs도 설치되어 있으므로, 이 일반화가 정확하지 않을 수 있습니다).
`/categories`를 처리하는 함수를 찾으면(끝에 붙은 `.json`은 출력을 어떻게 포맷할지를 코드에 알려주는 것 같고, 예를 들어 `/top`와 `/top.rss`에서 비슷한 동작을 볼 수 있습니다), 코드에서 어디를 봐야 할지 좁혀질 것이며, 이는 어떤 Ruby gems(대부분 Ruby 코드일 것이라고 확신합니다)이 제대로 빌드되었는지 확인해야 하는지 알려줄 것입니다.
---
### Author:  [@hendersj](https://meta.discourse.org/u/hendersj)
#### Post date: [1월 6, 2025, 11:30오후 UTC](https://meta.discourse.org/t/weird-encoding-issue-on-categories-page/345490/9 "2025-01-06T23:30:30Z")
발췌(excerpting) 기능에 특정한 문제인 것 같습니다. 방금 검색 결과 페이지에서도 동일한 문제가 발생한다는 것을 알게 되었습니다:
(예를 들어)
해당 텍스트는 다음과 같습니다:
> 「공유」 버튼을 찾을 수 없습니다.
이것은 제가 사용자(panorain)에게 답변하면서 인용한 내용입니다. 실수로 이 문제를 발견했는데, 제 활동 내역을 확인하려 했더니 500 서버 오류가 발생했고, `/logs` 출력에서 `lib/excerpt_parser.rb`에 런타임 오류 "input string cannot be empty"가 표시되었습니다.
몇 가지 현상이 발췌 처리 과정의 어떤 부분으로 이어지는 것 같지만, 개발 스타일 설치 환경에서만 발생하는 것으로 보입니다.
Docker 기반 설치 환경에서는 오류 없이 제 활동 내역을 확인할 수 있습니다. 이상하게도, 해당 설치 환경의 데이터베이스는 최근 프로덕션 서버 백업에서 복원된 것이며, 그 프로덕션 환경에서는 문제가 존재합니다.
---
### Author:  [@hendersj](https://meta.discourse.org/u/hendersj)
#### Post date: [1월 13, 2025, 2:44오전 UTC](https://meta.discourse.org/t/weird-encoding-issue-on-categories-page/345490/10 "2025-01-13T02:44:37Z")
nokogiri를 1.17.2로 업그레이드한 것 같고, Docker화 된 버전은 1.16.7로 보입니다. 이 문제의 원인이 그 때문일 것 같습니다. 해당 업데이트(그리고 동시에 업데이트된 다른 항목들)를 되돌리는 방법을 확인해 보겠습니다.
---
### Author:  [@darix](https://meta.discourse.org/u/darix)
#### Post date: [1월 26, 2025, 8:38오후 UTC](https://meta.discourse.org/t/weird-encoding-issue-on-categories-page/345490/11 "2025-01-26T20:38:58Z")
그래서 패키지를 내려서 다시 nokogiri 1.16을 사용하도록 했습니다. 이해가 안 되는 점은, 중복 패키징을 줄이기 위해 gem을 업데이트할 때마다 `main`에 관련 변경 사항이 있는지 확인하는데, 변경 사항이 없었습니다. 제가 무언가를 놓친 것이 아니라면요.
```plaintext
"description": "Witaj w polskiej sekcji społeczności openSUSE!",
"description_text": "Witaj w polskiej sekcji społeczności openSUSE!",
"description_excerpt": "Witaj w polskiej sekcji spoÅecznoÅci openSUSE!",
```
보시는 것처럼 올바른 텍스트가 두 번 있고, `PrettyText.excerpt`를 거칠 때만 깨집니다. `main`에서는 이것이 어떻게 처리되나요?
@hendersj DB의 사본으로 테스트할 수 있도록 `main` 패키지를 준비하고 있습니다.
[DEV: Update nokogiri to 1.18.1 (#30554) · discourse/discourse@affe26f · GitHub](https://github.com/discourse/discourse/commit/affe26f0dd8ecb9f9adc4024c7d68524a7e6665c) 에서 처리된 것으로 보입니다.
하지만 궁금한 점이 있습니다. `lib/retrieve_title.rb`에서
```plaintext
doc = Nokogiri.HTML5(html, encoding:)
```
이 부분은 다음과 같이 되어야 하지 않나요?
```plaintext
doc = Nokogiri.HTML5(html, encoding: Encoding::UTF_8)
```
---
### Author:  [@darix](https://meta.discourse.org/u/darix)
#### Post date: [2월 5, 2025, 12:43오전 UTC](https://meta.discourse.org/t/weird-encoding-issue-on-categories-page/345490/12 "2025-02-05T00:43:44Z")
@pfaffman 그 이상한 코드는 3.4.0 릴리스에도 있습니다. 🙂
빈 encoding: 설정으로 호출되는 것이 맞는지 확인해 주시겠어요?
---
### Author:  [@supermathie](https://meta.discourse.org/u/supermathie)
#### Post date: [2월 5, 2025, 1:25오전 UTC](https://meta.discourse.org/t/weird-encoding-issue-on-categories-page/345490/13 "2025-02-05T01:25:09Z")
그렇게 생각하는 이유가 있나요? UTF-8이 기본값입니다.
```plaintext
[1] pry(main)> Nokogiri::VERSION
=> "1.18.2"
[2] pry(main)> t = 'Witaj w polskiej sekcji społeczności openSUSE!
'
=> "Witaj w polskiej sekcji społeczności openSUSE!
"
[3] pry(main)> Nokogiri.HTML5(t).to_s
=> "Witaj w polskiej sekcji społeczności openSUSE!
"
[4] pry(main)> Nokogiri.HTML5(t, encoding: Encoding::UTF_8).to_s
=> "Witaj w polskiej sekcji społeczności openSUSE!
"
[5] pry(main)> Nokogiri.HTML5(t).to_s == Nokogiri.HTML5(t, encoding: Encoding::UTF_8).to_s
=> true
```
`retrieve_title` 함수는 _외부_ URL(예: YouTube)에서 제목을 추출하는 데 사용되며, 이 코드 경로에 대해 매우 정통하지는 않지만 이것이 문제의 원인이면 놀라울 것입니다.
_다른_ 것(예: 커스텀 플러그인에서 이 함수를 사용하는 경우)을 하고 있다면,那里的 인코딩 매개변수는 가져온 리소스의 content-type 헤더에서 가져옵니다:
```plaintext
if !encoding && content_type = _response["content-type"]&.strip&.downcase
if content_type =~ /charset="?([a-z0-9_-]+)"?/
encoding = Regexp.last_match(1)
encoding = nil if !Encoding.list.map(&:name).map(&:downcase).include?(encoding)
end
end
max_size = max_chunk_size(uri) * 1024
title = extract_title(current, encoding)
```
따라서 응답하는 웹 서버가 잘못된 content-type을 보고하고 있다고 의심할 수 있습니다.
---
### Author:  [@darix](https://meta.discourse.org/u/darix)
#### Post date: [2월 5, 2025, 1:29오전 UTC](https://meta.discourse.org/t/weird-encoding-issue-on-categories-page/345490/14 "2025-02-05T01:29:27Z")
해당 패치 내의 모든 다른 호출에는 encoding: 매개변수가 지정되어 있기 때문입니다.
retrieve title에 있는 호출만 그렇지 않네요. 이는 일관성이 없어 보입니다. 그리고 UTF-8 인코딩을 제대로 처리하지 않는 것이 이 스레드를 만든 논의의 핵심이었죠.
---
### Author:  [@supermathie](https://meta.discourse.org/u/supermathie)
#### Post date: [2월 5, 2025, 1:36오전 UTC](https://meta.discourse.org/t/weird-encoding-issue-on-categories-page/345490/15 "2025-02-05T01:36:39Z")
> [@darix](#):
>
> retrieve title에 있는 것만 그렇지 않습니다.
아:
> [@darix](#):
>
> `doc = Nokogiri.HTML5(html, encoding:)`
은 다음과 동일한 축약 표현입니다:
```plaintext
doc = Nokogiri.HTML5(html, encoding: encoding)
```
거기서 UTF-8을 강제하면 웹 서버에서 반환되는 UTF-8이 아닌 응답의 파싱이 깨지게 됩니다.
---
### Author:  [@darix](https://meta.discourse.org/u/darix)
#### Post date: [2월 5, 2025, 1:41오전 UTC](https://meta.discourse.org/t/weird-encoding-issue-on-categories-page/345490/16 "2025-02-05T01:41:57Z")
설명해 주셔서 감사합니다. 3.4.0 패키징으로 돌아가겠습니다.