다음 PR를 발견했습니다:
이것이 합법적인 히브리어 또는 아랍어 텍스트를 읽을 수 없게 만드는 것 같습니다.
제가 발견한 해결책 중 하나는 유니코드 알고리즘을 비활성화하고 인쇄할 수 없는 문자의 일부 표현을 표시하는 것이었습니다(이것이 Pootle에서 구현된 것으로 생각됩니다).
즉, 기본적으로 다음과 같은 텍스트를:
This text
다음과 같이 변환하는 것입니다:
This<LRM><RLM> text
이렇게 하면 사용자가 실제 문자를 이해하여 이것이 악의적인 것인지 아닌지를 판단할 수 있고, 텍스트를 올바르게 읽을 수 있도록 유니코드 알고리즘을 활성화하는 것을 선택할 수도 있습니다.
감사합니다.
이 문제를 지적해 주셔서 감사합니다. 이 우려 사항은 이미 인지하고 있었습니다. OP에서 링크하신 수정 사항은 pre와 code 블록 내의 유니코드 양방향 문자에만 적용되며, 이는 HTML로 직접 작성된 경우이거나 ``` 마크다운 펜스 코드 블록에서 생성된 경우에 해당합니다. 따라서 작성된 게시물에 포함된 일반적인 히브리어나 아랍어 텍스트에는 문제가 되지 않아야 합니다.
데모:
#include <stdio.h>
int main() {
/* Say hello; newline<U+2067> /*/ return 0 ;
printf("Hello world.\n");
return 0;
}
#include
int main() {
/* Say hello; newline<U+2067> /*/ return 0 ;
printf("Hello world.\n");
return 0;
}
테스트: "שלום חבר" - Hello Friend
BIDI 없이
테스트: “שלום חבר” - Hello Friend
마크다운:
Test: ‫"שלום חבר" - Hello Friend
Without BIDI
Test: "שלום חבר" - Hello Friend
세계에서 가장 좋은 예시는 아니지만, 핵심은 이해하셨을 것입니다. 이는 포럼에 게시되는 소스 코드에만 영향을 미칩니다. 소스 코드에 Bidi 문자를 사용하는 것은 일반적으로 하지 않는 일입니다.
RLM이 문장을 깨뜨리지 않는 또 다른 예를 하나 더 드리겠습니다.
שלום לכולם ובמיוחד ל־Sam, Martin בחר לעזוב אותנו.
שלום לכולם ובמיוחד ל־Sam, Martin בחר לעזוב אותנו.
차이를 보시나요?
거기서 변경된 부분은 RLM뿐입니다. Sam에게 축하를 전하고 Martin이 떠나고 있다는 사실을 알리고 싶었습니다(불쾌한 의도는 아닙니다).
네, 그 예시가 확실히 훨씬 좋습니다! 보시다시피, 보안 패치에도 영향을 받지 않고 계속 작동합니다 
음, 코드 블록이 아니네요 
제가 말한 건 코드 블록 안에서 예상대로 표시되지 않는다는 거였어요 (이 수정이 바로 그 문제를 해결하는 거잖아요, 맞죠?)
네, 그런데 왜 코드 블록에 포함시킨 거예요?
gettext의 발췌문, 히브리어/아랍어 네이티브 문자열, 이러한 사례가 있습니다.
여기서 예외적인 경우가 우회 방법(스크린샷, 첨부 파일 업로드 등)을 가지고 있다고 생각합니다. 또한 특수 문자가 이미 존재하는 것도 꽤 명확합니다.
https://trojansource.codes/ 의 위험성은 극단적인 예외적인 상황에서 발생하는 경미한 혼란의 위험성보다 더 높습니다.
하지만 제 제안은 문장을 어떤 큐(cue)로 끊어버리기 때문에, RLM과 LRM을 <RLM> 또는 <LRM>으로 대체하면 사용자가 추가 문자가 있었음을 알 수 있으며, 현재 텍스트가 그 문자 없이 렌더링되고 있음을 보여줄 수 있습니다. 또한 이것이 사용자 경험을 깨뜨릴 수 있다는 점과, 필요할 경우 수동으로 원래 문자로 되돌릴 수 있는 옵션이 있다는 점을 알려줄 수 있습니다. 문자를 완전히 제거하고 어떤 표시도 두지 않으면 사용자가 판단할 여지가 전혀 없습니다.
또한, 귀하가 언급하신 트로이 목마 소스 코드 문제도 방지할 수 있습니다. 표시자가 있으므로 사용자가 악성 코드를 확인할 수 있기 때문입니다.
Pootle에서 몇 가지 스크린샷을 가져오려고 합니다. 지난 몇 년간 원문(raw strings) 옵션을 본 기억이 없지만, LibreOffice 현지화 작업을 처음 시작할 때 그 옵션은 매우 유용했습니다.
이해가 안 됩니다. 우리는 제거하는 게 아니라 교체하는 건데, 위 예시를 참고해 주세요.
이해합니다. 유니코드 엔티티 대신 이름을 사용하는 것이 더 나을 것 아닙니까?
실제 사용 환경에서 반복되는 혼란이 보고되면, 확실히 세밀한 조정을 할 수 있습니다.