XML 1.0에서 "제어"문자가 잘못된 이유는 무엇입니까?

XML 1.0에서 "제어"문자가 잘못된 이유는 무엇입니까?

---

XML 1.0에서 합법적으로 인코딩 할 수없는 다양한 문자가 있습니다 U+0007( 예 : ( 'bell') 및 U+001B( 'escape')). 대부분의 흥미로운 것은 공백이 아닌 '제어'문자입니다.

(예를 들어) 이 질문 과 다른 사람들 로부터 문제가 되는 것이 XML 사양이라는 것이 분명합니다. 하지만 XML 사양이 이러한 문자를 금지 하는 이유에 대해 누구든지 저를 밝힐 수 있습니까?

예를 들어 및 각각 으로 이스케이프로 인코딩되어야하는 것처럼 보이지만 문자가 이스케이프되지 않고 금지 된 실질적인 이유가 있습니까?

응답자들은 전송 제어 문자를 피하려는 동기가 있다고 제안했지만 유니 코드에는 다른 제어와 유사한 문자가 많이 포함되어 있습니다 ( U+200C"폭이없는 비 결합 자"를 고려하십시오 ). 이 행동에 대한 합당한 이유가 없을 수도 있음을 알고 있지만 여전히 더 잘 이해하고 싶습니다.

이러한 문자 값이 다른 인코딩 데이터 형식으로 표시되면이를 인코딩해야하는 새 XML 문서를 "이중 이스케이프"하게 되므로 특히 실망 스럽 습니다.

---

내 이해는이 범위는 마크 업 언어가 전송 및 흐름 제어 문자를 지원할 필요가 없어야하고이를 포함하면 이진 변환에서 모든 편집자 및 파서에 문제가 될 수 있다는 이유로 금지된다는 것입니다.

나는 Tim Bray 등으로부터 이것에 대한 전 카테 드라를 찾기 위해 고군분투하고 있습니다.

편집 : 일부 토론 제어 문자와 정확히 과다 설계 아니었다 모호한 입장 :

09:27 AM 17/06/00 -0500, Mark Volkmann은 다음과 같이 썼습니다.

양식 피드와 같은 대부분의 ASCII 제어 문자가 XML 문서에서 허용되지 않는 이유에 대한 논의를 본 적이 없습니다. 누구든지 그 결정의 이유를 말하거나 사양을 알려줄 수 있습니까? 그게 설명이 되나요?

우리가 다시한다면 같은 방식으로 할 수 있을지 모르겠습니다. 나는 그들이 실제로 해를 끼치는 것을 보지 않습니다. 확실히 상호 운용성이 뛰어난 콘텐츠 마크 업 언어 (그리고 XML)를 최적화하는 경우 수직 탭 및 백 스페이스 등을 의심하는 것이 합법적입니다.하지만 어떻게 일관성을 유지할 수 있습니까? \ n 및 DEL 등? -팀

---

예를 들어 & # x0007; 및 & # x001B;

\ 0을 제외한 모두에 대해 XML 1.1에서 정확히 수행 할 수 있습니다.

---

오래 전 일 이었지만, 제가 가장 기억에 남는 것은 그래픽 표현이없고 합의 된 의미론도 없다는 것입니다. 무작위로 커플을 선택하면 U + 0006 "승인"또는 U + 0016 "동기 유휴"가 표시됩니다 ... 그게 무슨 뜻입니까? 유니 코드는 말하지 않습니다. 모든 사람들이 ASCII를 지원한다고 주장했을 때도이 쓰레기와 관련된 상호 운용성은 없었습니다. XML은 상호 운용성에 관한 것입니다.

경험은 이러한 것들을 사용하려는 사람들이 실제로 XML 요소에 바이너리 데이터를 넣기를 원한다는 것입니다 (그리고 그들이 원하는 다음 것은 U + 0000 NULL을 포함하는 것입니다). 이는 날부터 명시 적으로 XML의 목표가 아니 었습니다. 1. 숫자 0x6 또는 0x16을 나타내려면 "문자"라는 개념을 혼동하지 않는 좋은 방법이 많이 있습니다.

---

XML 1.1의 관점에서도 다시 요약 할 때입니다.

유니 코드에는 어떤 제어 문자 코드 포인트가 있습니까?

• U+0000에 U+001f, ASCII에서 상 속됨.
• U+007F, ASCII에서 상 속됨
• U+0080까지 U+009F, Latin-1에서 상 속됨
• 유니 코드에 대해 명시 적으로 표준화 된 다양한 특수 목적 범위, 특히 비 마크 업 컨텍스트에서 특히 유용합니다. 그들은된다 여기서 논의 하는 이유와 사용 방법 또는 어쨌든 그들로 실행하면 무엇을 XML에서 사용하고하지 않는 이유를 포함한 블록에 의해 차단합니다.

XML은 이러한 제어 문자를 어떻게 봅니까?

이것은 다른 분류입니다.

• 탭과 줄 바꿈 (줄 바꿈이 무엇인지의 플랫폼 종속성에 관계없이)은 좋습니다. 모두가 사용합니다. 모두가 자신이 무엇을지지해야하는지 알고 있습니다. 거의 모든 알려진 형식에서 허용되며, 종종 마크 업 자체의 예쁜 인쇄에도 허용됩니다.
• U+0000악입니다. 널 문자? 문자열 종결 자? 바이너리 노이즈? 상호 운용성과 마크 업에 대한 반대입니다. 모든 형태로 금지됩니다.
• 다른 건 없나요? 거의 사용되지 않고 문제가있는 상호 운용성이지만 "제어"해야하는 것에 대해 많이 알지 못하더라도이를 용인 할 수있는 방법이 있습니다.

이제이 마지막 범주 인 적절한 제어 코드로주의를 전환 해 보겠습니다. 즉, 다음과 같은 요약 탭과 줄 바꿈이 적용되지 않습니다 : U+0009, U+000a, U+000D, U+0085, U+2028.

XML 1.0을 제외하고, 모두에게 제어 문자의 상기 범위를 허용 U+0000하는 U+001f텍스트로 (직접 포함 된 문자)와 같은 숫자 참조 . 허용 U+007F하는 U+009F이었다 분명히 누락에 의해이 불일치는 XML 1.1에서 수정되었습니다 만, 다른 방식 라운드. 그들은 표준 내부에 자세한 근거를 제시했습니다.

마지막으로 XML 문서에서 임의의 유니 코드 문자의 표준 표현을 정의해야합니다. 따라서 XML 1.1에서는 제어 문자 # x1에서 # x1F까지의 문자 참조를 사용할 수 있으며, 대부분은 XML 1.0에서 금지되어 있습니다. 그러나 견고성 때문에 이러한 문자는 문서에서 직접 사용할 수 없습니다. 문자 인코딩 감지의 견고성을 향상시키기 위해 XML 1.0 문서에서 자유롭게 허용되었던 추가 제어 문자 # x7F에서 # x9F까지 문자 참조로만 나타나야합니다. (공백 문자는 물론 예외입니다.) 이전 버전과의 호환성에 대한 사소한 희생은 중요하지 않은 것으로 간주됩니다. API의 잠재적 인 문제로 인해 # x0은 직접 및 문자 참조로 여전히 금지되어 있습니다.

유니 코드와 XML이 몇 가지 "상속 된"범위를 제외하고 마크 업과 유사한 제어 문자를 무료로 사용할 수있는 이유는 무엇입니까? 사람들은 그것들을 위해 마크 업을 사용해야합니다.

유니 코드는 비 마크 업 컨텍스트에서도 사용되며 여전히 진화하는 문자 집합입니다. 비 제어 문자 집합이 움직이는 대상이라면 준수 XML 프로세서를 구현하기가 너무 어려울 것입니다.

좋습니다. 유니 코드 전용 제어 문자와 비교할 때 상속 된 범위에 어떤 문제가 있습니까?

표준화 부족. 유니 코드 컨소시엄은 이러한 "문자"에 할당되는 숫자 또는 일반적인 시각적 표현이나 의미가 무엇인지 실제로 선택하지 않았습니다. ASCII (인코딩 된 UTF-8 레벨) 및 Latin-1 (코드 포인트 할당 레벨)과의 완전한 역 호환성은 다양한 텍스트 처리 컨텍스트에서 종종 첨부되는 다양한 특수하고 오버로드 된 의미에 관계없이 이러한 코드 포인트의 원시 포함을 강제했습니다.

잠깐, XML이 UTF-8과 달리 ASCII와 완전히 역 호환되지 않는다는 뜻입니까?

네. 맞습니다. 문서 요소가 필요합니다. raw <또는 &. 그렇다면 원시 제어 문자를 입력해야하는 이유는 무엇입니까?

---

XML은 (내가 아니에요 둘 유니 코드 (특히 UTF-8과 UTF-16) 및 ISO / IEC 10646, 주위에 특별히 디자인 된 아주 ASCII에서 남은 된 제어 문자 흐름 / 전송을 포함하는 ISO 10646에 대해 긍정적) 및 문자 기반 터미널의 시대. 이러한 문자는 여전히 사용되지만 XML과 같은 형식에는 속하지 않습니다.

이러한 코드를 다른 용도로 사용하는 이러한 새 인코딩에 대해서는 XML 사양을 조정해야 할 수 있습니다.

---

왜 이중으로 이스케이프를하나요? & bell;에게 좋은 장소 인 것 같습니다. 및 & escape ;. (정의되지 않음, 파서에서 코드로의 콜백에 의해 처리됨)

참고 URL : https://stackoverflow.com/questions/404107/why-are-control-characters-illegal-in-xml-1-0