사용자 이름에 (일부) 유니코드 문자를 활성화했고, 모든 것이 예상대로 작동합니다.
카테고리 슬러그에 유니코드 문자를 사용하려고 했을 때, 이는 퍼센트 인코딩으로 변환되어 변경 사항을 저장할 수 있었지만, ERR_TOO_MANY_REDIRECTS 오류가 발생하여 더 이상 카테고리 토픽 목록에 접근할 수 없었습니다.
Rails 콘솔을 사용하여 문제를 해결한 것 같습니다:
Category.find(id).update(slug: ‘slug-without-unicode’)
이것은 서비스 중단을 일으키는 문제는 아니지만, 문제를 일으킬 수 있으므로 완전히 구현하거나 이에 대한 가드(방어)를 추가하는 것이 좋습니다.
과거에 이 문제에 대한 일부 작업이 이루어졌지만, 사용자가 겪은 문제가 해결되었는지 의문입니다. 제 생각에는 slug 생성 방법(slug generation method)이 'ascii’로 설정되어 있고, non-ascii 문자가 포함된 카테고리 슬러그를 직접 입력한 것 같습니다. 제 사이트에서도 slug 생성 방법을 'ascii’로 설정하고 다음 텍스트(yetersizliği)를 카테고리 슬러그(Category Slug) 필드에 직접 입력하면 해당 문제를 재현할 수 있습니다:
카테고리를 저장한 후:
그 카테고리 목록을 로드하려고 하면 실패합니다.
카테고리 슬러그 필드에 아무것도 입력하지 않으면, slug 생성 방법이 'ascii’로 설정되어 있어도 Discourse가 슬러그를 올바르게 생성합니다.
slug 생성 방법이 'encoded’로 설정된 경우, 카테고리 슬러그 입력 필드를 비워 두거나 non-ascii 슬러그를 직접 입력하더라도 Discourse가 슬러그를 올바르게 생성합니다.
따라서 slug 생성 방법이 'ascii’로 설정되어 있을 때, 카테고리 슬러그 필드에 non-ascii 슬러그가 여전히 입력될 수 있다는 것이 문제의 원인으로 보입니다. 이로 인해 리다이렉트 문제가 발생하며, 이는 Rails 콘솔에서만 수정할 수 있습니다.
그래서 여기서 저장 시 모델 검증을 해야 한다는 거죠?
제가 맡을게요.
제가 정확히 그렇게 했습니다. 이전에 생성된 카테고리의 이름과 슬러그를 모두 수정하고 있었거든요. 슬러그 생성 방법 설정에 대해 몰랐고, 나중에 해당 설정이 ascii로 되어 있음을 발견했지만 슬러그는 여전히 인코딩되어 있었습니다.
이러한 강제 변환은 나중에 설정을 무시하는 방식으로 인코딩된 슬러그를 인식할 수 있는 경우에만 의미가 있을 수 있습니다.
이것이 문제를 수정해야 합니다
3개의 게시물이 새로운 주제로 분리되었습니다: 유니코드 사용자 이름으로 프로필 페이지 로드 시 오류 발생
위 PR이 병합되었습니다 
