토크:ASCII

새 작은 테이블

그것은 다음과 같은 코멘트로 되돌아왔다.

하지만 난 오래된 테이블이 더 좋아 표준 레이아웃(대부분 다른 곳에서도 사용), 색상 그룹화, 분산 표시, 보다 직접 읽을 수 있는 코드(이곳에는 표시되지 않으며, 어쨌든 마우스가 필요함)

IMHO 현재의 테이블은 정말 끔찍하고 오랫동안 있어왔다.

컬러 그룹화는 멍청한 바쁜 업무로 ASC가 아닌 많은 사람들에게 잘못된 것이다.II 문자(대부분은 카타고리에 속하지 않으며), 그 어떤 용도에도 대한 정보를 어느 누구에게도 전달하지 않는다. 변종과 기타 흥미로운 정보를 나타내기 위한 색상을 자유롭게 하는 것은 많은 도움이 된다(미안하게도 그가 불평한 이 표의 예를 지웠으나, 나는 그 정보가 이미 위의 거대한 중복 표에 있다고 느꼈고, 또한 97년 이전의 ASCII는 현재 세상에 전혀 존재하지 않으며, 이는 i가 가리키는 변종과는 다소 다르다.n 다른 테이블).

추가 정보는 사용자들에게 혼란을 주고 테이블을 부풀려 글자를 보기 어렵게 만든다. 유니코드 코드 포인트는 적어도 U+ 접두사가 필요하지만, 툴팁에 넣고 문자 이름을 추가하면 이러한 숫자가 테이블 항목의 인덱스가 아니라 유니코드라는 것을 명확히 하는데 많은 도움이 된다(글쎄, 편집자들이 계속해서 이것을 망치고 있다는 것을 의미한다). 또한 텍스트는 비 유니코드 점을 설명할 수 있다. 툴팁이 태블릿이나 전화기에 보이지 않는 것은 사실인데, 나는 그것에 대해 아무것도 할 수 있는 것이 없다고 본다. 이 테이블이 보이도록 하려면 큰 수직 테이블(예: 이전 ASCII 테이블과 같이 문자당 한 행)을 사용하십시오. IMHO는 등장인물을 찾기가 훨씬 어렵지만, 나는 이 모든 테이블을 수직으로 바꾸자는 주장을 볼 수 있다. 하지만 현재 하이브리드가 작동하지 않으니까 어떻게든 바꿔줘!

참고로 여기에 내 샘플 테이블이 있다(참고: 컨트롤 문자를 채우고 어떤 모양인지 표시하기 위해 가짜 색상을 가지고 있기 때문에 이 표는 어떤 글에서도 변경되지 않고 사용되도록 의도된 것은 아니다). 10진수 색인을 표시하는 가능한 방법을 보려면 도구 설명에서 'A'를 확인하십시오.

이것에 대해 의견을 좀 올려줘! 나는 떠나겠지만 건설적인 비난 없이 맹목적으로 되돌리는 것은 달갑지 않다. 건설적인 변경사항이 있는 경우 여기에 해당 변경사항을 삽입하십시오(아마도 표의 몇 행만 해당).

스피츠악 (토크) 17:57, 2018년 7월 17일 (UTC)[]

한 가지 생각: 테이블 셀을 클릭하면 참조가 작동하는 방식과 유사한 형식과 클릭 가능한 링크가 있는 대화 상자가 나타나도록 만드는 방법을 아는 사람이 있는가? 그렇게 되면 태블릿에서 정보를 볼 수 있게 되고, 최소한 줄 바꿈으로 포맷할 수 있는 능력은 엄청난 양의 도움이 될 것이다. 여기서는 작동하지 않지만 링크된 페이지의 매우 멋진 미리보기를 유지하면서 링크 팝업으로 정보를 가져오는 방법을 아는 사람이 있는가? 스피츠악 (토크) 18:09, 2018년 7월 17일 (UTC)[]

나도 생각해 보겠지만, 스피츠악, 지금 당장은 그런 가능성을 잘 모르고 있어. 두 경우 모두 문제가 태블릿과 스마트폰에만 국한되는 것이 아니라 일반적인 데스크톱 환경(마우스 사용)에도 해당된다는 점에 유의하십시오. 일반적으로 테이블이 있는 요점은 우선 어떤 "세포 포인터"를 이동하거나 하위 메뉴를 열거나 닫지 않고도 쉬운 직접적인 비교를 위해 적어도 모든 글리프와 코드를 동시에 볼 수 있게 하는 것이라고 나는 생각한다. 또한 툴팁이나 서브메뉴의 정보가 어떻게 출력되는지 알 수 없다. 글립스만으로 된 표를 인쇄하는 것은 내게는 상당히 무의미해 보인다. --마티아스폴 (토크) 21:40, 2018년 7월 17일 (UTC)[]

(분쟁 편집) 당신은 매우 과감한 변화를 시도했고 WP에 의해 되돌아갔다.BRD. 아무도 되돌리는 걸 좋아하지 않아. 그래서 나는 다른 편집자들의 기고를 되돌리는 것을 매우 꺼려하지만, 이 경우 나는 먼저 오랫동안 확립되어온 "현상"을 복구하지 않고는 앞으로 나아갈 길이 없다고 보았다. 결국, 당신의 제안된 변화는 논의되지 않았다. 광범위한 합의가 이루어지지 않는 한 다른 기사(ISO/IEC 8859-1 기사에서 이미 설명한 바와 같이)의 표를 변경하지 마십시오.

또한, 욕설을 사용하는 것은 역효과를 낳는다. 건설적인 편집자로서 나는 확실히 당신을 맹목적으로 혹은 가볍게 되돌리지는 않았지만 편집 요약에서 많은 이유를 밝혔다.

현재 표 레이아웃은 이곳뿐만 아니라 위키백과 전체에 걸쳐 거의 모든 문자 집합과 코드 페이지 관련 기사에서 사용되고 있다. 이것만으로도 이미 일관성을 위해 그것을 유지하는 강력한 이유가 되고 있다(더 개선될 수 있는 가능성을 배제하지 않음). 그러나, 정보를 삭제하거나 정보에 접근하기 어렵게 만드는 것은 분명히 개선된 것이 아니다.

컬러 그룹화 및 복싱은 같은 문자 집합에서도 글리프 그룹을 표시하거나 동일한 코드 포인트의 다중 의미를 강조하거나 수정본 또는 밀접하게 관련된 문자 집합의 차이를 표시하기 위해 사용된다(실제 용도는 기사에 따라 다르며, 거기서 설명해야 한다). 이것은 때때로 패턴을 보는 데 매우 유용하거나, 적어도 특별한 주의가 필요할 수 있는 코드 포인트를 쉽게 포착하는 데 도움이 된다. 이상적으로는 이 내용도 본문에서 논의되지만, 거기서만 제공된다면 그 정보는 쉽게 간과될 수 있다.

테이블 셀에 제시된 다양한 코드는 중요한 정보다. 툴팁은 접근성을 이유로 대신 사용할 수 없음: 그들은 마우스로 글리프 위를 맴돌 때만 나타날 것이다 - 이런 식으로 코드 패턴을 보는 것은 불가능하다. 또한, 일반적인 데스크톱 구성을 포함한 많은 시나리오에서 나타나지 않는다. 이 문제는 태블릿과 전화기, 또는 마우스가 없는 사용자로 제한되지 않는다. 예를 들어, 내 브라우저(Firefox)는 일반 데스크톱 PC에서 이러한 항목을 표시하지 않으며, 링크된 문서의 이름을 표시하므로 전혀 도움이 되지 않는다.

나는 네가 유니코드 이름도 제공하기를 원한다고 생각해. 이것은 내가 일반적으로 지지하는 것이다. (만약 우리가 이 정보를 제공하는 좋은 방법을 찾을 수 있다면)

이 정보는 추가 정보이기 때문에 테이블 셀에서 직접 읽을 수 있는 정보를 삭제하거나 다른 레이아웃을 변경하지 않고 툴팁에 정보를 넣는다면 반대하지 않을 것이다. 그 대신에(그리고 아마도 접근성 때문에 더 좋을 것이다), 나는 또한 유니코드 이름(및 기타 정보)을 포함한 128개 또는 256개의 코드 포인트의 별도 목록을 모든 문자 집합 기사에 추가하는 것을 반대하지 않을 것이다 - 심지어 더 상세한 설명을 제공할 수도 있다. 그러나, 수년 전 우리는 이미 많은 문자 집합 기사에 그러한 유니코드 변환 목록을 가지고 있었고 몇몇 사용자들은 그것들을 너무 오래 발견하였다. 이론적으로, 그 목록은 하위 페이지에 올려질 수 있지만 그것은 우리의 명명 규칙을 위반할 것이다.

역사 정보에 관해서, 백과사전에서, 이전의 ASCII 변형의 세부사항들은 최신 버전과 마찬가지로 관련이 있다. 나는 네가 얼마 전에 정보를 삭제했을 때 이미 마음에 들지 않았어.

--Matthiaspaul (talk) 21:20, 2018년 7월 17일 (UTC)[]

좋아, 내가 가장 반대하는 부분을 제거하기 위한 아이디어는 어때? 다음은 독립적으로 수행할 수 있는 몇 가지 사항이다.

• 유니코드 코드 포인트의 소수점 버전 또는 그 반대로 계속 혼동되고 있는 소수점 숫자 제거
• 유니코드 번호의 시작 부분에 "U+" 추가
• 가능한 한 많은 패딩을 패딩하여 100% 너비를 제거하고 ems의 최소 행/열 크기를 사용하여 테이블을 정사각형으로 유지하십시오.
• 지금 볼 수 없는 유니코드 이름 및 기타 정보를 제목(도구 설명)에 넣으십시오.
• 유니코드 문자 클래스를 기반으로 새로운 색상 세트를 만들어 자동으로 적용할 수 있게 하라(나는 여전히 이 색상들이 절대적이고 완전한 시간 낭비라고 생각한다, 그리고 그 테이블이 실제보다 더 화려해 보이도록 하기 위해 노력하기 위한 복수로 바로 거기에 있다). 지금 당장은 ASCII가 아닌 사람들에게 거의 항상 틀리고 테이블이 잘못된 색상을 입도록 강요하는 "포괄적인" 색은 없다.
• 기본 크기를 문자에 사용되는 큰 크기로 만들어 컨트롤 문자와 헤더를 반대로 만드는 대신 작은 크기로 만드십시오.

그리고 내가 삭제한 정보가 무엇인지 설명해 줄 수 있니? 스피츠악 (토크) 22:14, 2018년 7월 17일 (UTC)[]

스피츠크: 유니코드 코드 포인트의 소수점 버전 또는 그 반대로 계속 혼동되고 있는 소수점 숫자 제거

지금 여러 번 설명했듯이 문자 집합표에서 십진수 지수는 중요한 정보다. 그것을 세포에서 제거하면 테이블이 쓸모 없게 된다. 독자들이 어떤 공식을 통해 지수를 계산하기를 기대할 수는 없다.

스피츠크: 유니코드 번호의 시작 부분에 "U+" 추가

개인적으로 나는 "U+" 표기법을 매우 좋아하지만, 그것은 표를 더욱 크게 만들 것이기 때문에 선행 0을 가진 네 자리 값이면 충분하다고 생각한다. 몇 년 전, 일부 표에는 실제로 "U+"가 포함되었지만, 다른 편집자들에 의해 삭제되었다. 아마도 이것을 더 잘 설명하기 위해 테이블 LED 매크로가 개선되어야 할 것이다.

스피츠크: 가능한 한 많은 패딩을 패딩하여 100% 너비를 제거하고 ems의 최소 행/열 크기를 사용하여 테이블을 정사각형으로 유지하십시오.

나는 테이블이 사각형일 필요는 없다고 생각하지만, 같은 크기의 행과 열을 각각 갖는 것은 좋지만, 정보를 희생하지 않고 이것을 달성할 수 있어야만 한다. 토크 페이지에서는 대체 레이아웃을 제안할 수 있지만, 라이브 기사에서는 제안할 수 없다.

스피츠크: 지금 볼 수 없는 유니코드 이름 및 기타 정보를 제목(도구 설명)에 넣으십시오.

이는 이미 위에서 설명한 바와 같다. 만약 셀 매크로를 다른 어떤 정보도 제거하지 않고 유니코드 이름을 포함하도록 확장할 수 있다면, 이것은 괜찮을 것이다. 또한 대부분의 문자 글리프 링크를 유니코드 이름을 포함하는 리디렉션을 통해 라우팅하는 것을 지지한다(BTW 당신의 리디렉션 제거 중 일부는 역방향 조회를 더 어렵게 만들고 WP:파손되지 않음). 툴팁에 관한 일반적인 요점은 모든 브라우저가 이 정보를 보여주는 것은 아니므로 마우스 등으로 그 위를 맴돌지 않고 볼 수 있어야 하는 핵심 정보에 대해서는 선택적 정보에만 사용할 수 있다는 것이다. 소수점 지수(그리고 어떤 경우에는 8진수), 문자 글리프 및 해당 유니코드 코드(존재하는 경우)는 선택 사항이 아니므로 항상 볼 수 있어야 한다.

• 스피츠악: 유니코드 문자 클래스를 기반으로 새로운 색상 세트를 만들어 자동으로 적용할 수 있게 하라(나는 여전히 이 색상들이 절대적이고 완전한 시간 낭비라고 생각한다, 그리고 그 테이블이 실제보다 더 화려해 보이도록 노력하기 위한 복수로 바로 거기 있다).

현재의 색상 그룹화는 완벽하지 않지만, 당신의 새로운 색상 그룹 제안도 완벽하지 않다. 예를 들어 표준 ASCII 문자와 국제 문자는 다른 색을 가져야 한다.

• 스피츠악: 기본 크기를 문자에 사용되는 큰 크기로 만들어 컨트롤 문자와 헤더를 반대로 만드는 것이 아니라 작게 만들도록 하십시오.

기호 제어 코드 이름(NUL, LF 등)은 일반 글리프보다 작은 크기로 표시해야 한다. IERC, 이것은 당신이 모든 곳에 당신의 변화를 강요하기 시작하기 전에 (몇 표의 특별한 경우에 의해 야기된 약간의 사소한 예외를 가진) 사례였다.

--Matthiaspaul (talk) 18:46, 2018년 9월 30일 (UTC)[]

테이블에 대한 최신 변경 사항

이 페이지가 더 잘 보이므로, 나는 변경 사항을 복원했지만, 이번에는 몇 가지 단계를 거쳤으며, 또한 불필요하게 링크를 변경하는 것도 피했다(이전 것들은 다른 페이지에서 링크를 복사하기 위한 것이었다). 십진수는 삭제된 것이 아니라 사용되지 않는 템플릿 인수에 있다. 나는 이것이 실제로 나나 마티아스폴이 아닌 다른 누군가가 그 변화에 찬성하거나 반대하는 게시물로 이어지기를 바란다. 현재 IBM 3270에 찬성하는 게시물이 있지만, 그 사람도 유니코드 제거에 찬성하는 글을 올렸다.

십진수를 표시하는 가능한 방법의 예는 ISO-8859-1을 참조하십시오. IMHO가 16*y+x를 계산하는 능력은 이 정보를 사용할 수 있는 사람이라면 누구나 가정할 수 있다. 스피츠악 (토크) 16:27, 2018년 9월 28일 (UTC)[]

우리와 같은 컴퓨터 전문가들에게는 테이블이 한 줄당 16자로 정렬되어 있기 때문에 맨 위 행과 왼쪽 열에서 16진수 지수를 계산하는 것이 충분히 쉽지만, 위키피디아는 일반인도 접근할 수 있어야 한다. 십진수 지수는 중요한 정보(실제로 문자 집합 테이블이 제공해야 하는 가장 기본적인 정보 중 하나)이며, 이를 제거하면 표의 효용 가치가 현저히 감소하므로 독자들이 어떤 공식을 통해 지수를 계산하기를 기대할 수는 없다.

사람들은 페이지업과 바로 위의 동일한 정보를 보여주는 거대한 테이블을 완벽하게 볼 수 있다!스피츠악 (토크) 2018년 10월 15일 (UTC)[]

우리는 위키피디아 전역에서 사용되는 문자 집합 테이블의 일관된 표 형식을 가지고 있다. 이것은 여러 해 동안 안정되어 왔기 때문에 기사에 당신의 변경사항을 적용하기 전에, 당신은 이미 여러 곳에서 여러 번 들었듯이 그것에 대한 폭넓은 공동체적 공감대를 찾을 필요가 있다. 수십 개의 기사로 당신의 변경을 강요하려는 당신의 반복적인 시도는 WP에서 다루지 않는다.BRD, 편집-전쟁으로 대규모 교란이 일어나고 있어 전혀 좋지 않다.

지수를 값에서 더 멀리 떨어뜨리기 위해 내가 생각할 수 있는 것은 아마도 다른 색을 사용하는 두 영역으로 쪼개진 세포일 것이다. 위쪽 영역은 지수의 아래쪽 영역인 글리프 및 유니코드 또는 ASCII 코드용으로 예약된다. 이상적으로는 인덱스 영역이 셀의 오른쪽 하단 모서리에만 위치할 수 있지만 HTML 테이블에서는 대각선 분할선이 불가능하다고 생각한다.

위의 IBM 3270 코멘트와 관련하여, 이는 유니코드를 전혀 제거하지 않고 특정 테이블에서 일부 결함 있는 유니코드 코드를 제거하는 데 적용되었다(테이블의 효용 값을 0에 가깝게 만드는 정말 어리석은 발상이 될 것이다).

아니, 분명히 아니야. 당신의 지시를 위해 나는 여기에 Peter Flass의 코멘트를 오려 붙이겠다. 이것은 통제 캐릭터에 관한 것이 아니다.

"문자 집합 테이블에 ASCII 값이 있는 것은 혼란 그 이상이라고 생각한다. 나는"여러 가지 변화와 변화를 따라가지 않았지만, 한 테이블에 ASCII와 EBCRIC를 혼합하는 것은 좋지 않은 생각이라고 생각한다. 3270 ASC가 있다.II 문자 집합, 그리고 사람들이 ASCII를 보고 싶다면 별도의 ASCII 표가 있어야 한다고 생각한다. 피터 플래스(대화) 오후 12시 18분 2018년 9월 26일 수요일(19일 전) (UTC-7)."

그가 "ASCII"에 대해 말할 때 유니코드 번호를 언급한다는 점에 유의하십시오.

--Matthiaspaul (talk) 18:46, 2018년 9월 30일 (UTC)[]

나는 Matthiaspaul에 강력히 동의한다. 아스키 문자에 대한 십진수(*및* 16진수) 코드를 빠르게 조회하는 것이 기사의 메인 이미지에 대한 가장 높은 우선순위가 되어야 한다. (나는 이 이미지를 좋아하지만, 역사적 문서로서, 기사 뒷부분에서 일어나는 것은 괜찮다.)

just-yeti (talk) 19:08, 2018년 10월 8일 (UTC)[]

아무도 안내 상자 그림을 바꾸자고 제안하지 않는다. 논의 중인 내용을 다시 확인하십시오.스피츠악(토크) 19:34, 2018년 10월 15일 (UTC)[]

내 의견과 내 의견 이외의 코멘트는 무시해야 한다고 주장함에 따라, IBM 3270페이지의 또 다른 코멘트는 다음과 같다.

"사용자:Matthiaspaul은 IBM 3270의 표 1이 소수점 없이는 쓸모없다고 주장했고 사용자:스피츠크; 테이블은 십진수 없이 완벽히 유용하며, 사실, 십진수는 쓸모없다; 3270을 위한 프로그래밍은 문자를 제어하기 위해 16진수나 상징적인 참조를 사용한다. 슈무엘 (시모어 J.) Metz 사용자 이름:차툴 (대화) 오전 11시 42분, 2018년 9월 25일 화요일 (20일 전) (UTC-7)."

LEM

제어 문자 표에는 LEM이 ETB의 별칭으로 표시되지만 LEM이 무엇인지에 대한 논의는 어디에도 없다. 토크 자료도 확인해 봤고, 거기에도 없어. ETB에도 아무것도 없다. http://ascii-table.com에서 이용할 수 있는 "논리적 종료 미디어"로 초기주의가 확장되고 있지만, 더 이상의 설명은 없다. 물리적 종료가 아닌 종이 또는 자석 데이터 종료를 의미하기 위한 것으로 보인다. 192.31.168.36 (대화) 11:49, 2018년 10월 14일 (UTC)[]

"유리 TTY"

적어도 PDP-10 커뮤니티에서는 "유리 TTY"라는 이름이 표시 단자를 의미하는 것이 아니라, 커서를 임의의 위치로 이동하고 문자를 덮어쓰고 문자를 삭제하는 것을 지원하지 않는 표시장치의 경멸적인 이름이었다. 이러한 단말기는 Emacs를 지원하지 못했기 때문에 텔레타입이나 다름없다고 여겨졌다. --Briankharvey (talk) 19:37, 2018년 12월 30일 (UTC)[]

베이스64?

어쩌면 베이스64를 향해 고개를 끄덕여줄지도 몰라. 오래된 인코딩을 모두 통과하도록 개발되었지. A-Z a-z 0-9를 대부분 확신할 수 있기 때문에 — 94.232.167.4 (대화) 10:05, 2020년 2월 27일 (UTC)[]이(가) 추가되지 않은 앞선 의견

그 주제에 대한 실무 지식이 없으면 이해할 수 없다.

뭐. 누구. 왜. 언제.

즉시 상세하게 설명된다.

이게 뭐야? 간단한 영어로.

그러면 누구.

왜

언제

그리고 다른 종류의 프린터와 당신이 중요하다고 생각하는 매우 구체적인 세부사항들 사이의 라인 출력에 관한 기술 논쟁은 이 불투명한 횡설수설하게 만든다. 더덕(토크) 23:37, 2020년 6월 17일 (UTC)[]

반보호 편집요청 2021년 5월 25일

「ASCII 표준에 관한 작업은 1960년 10월 6일에 시작되었다」를 「ASCII 표준에 관한 작업은 1961년 5월에 시작되었다」로 변경한다.

내가 찾을 수 있는 유일한 출처는 1960년 이 위키백과 페이지를 참조한다. 다른 출처는 1961; (http://edition.cnn.com/TECH/computing/9907/06/1963.idg/, KwiHours (talk) 05:21, 2021년 5월 25일 (UTC)[]을 사용하는 경향이 있다.

DoneMelmann 10:22, 2021년 5월 25일 (UTC)[]