shopkeeper/korean_wiki_content_only_120125 huggingface dataset:
2022년 말 OpenAI의 독점 ChatGPT 모델이 출시된 이후, 완전히 개방된(가중치, 데이터, 코드 등) 대형 언어 모델은 극히 일부만이 출시되었다. 이 중에는 OLMo 모델 시리즈가 포함된다. 2025년 9월, 스위스 컨소시엄은 Apertus라는 완전히 개방된 모델을 출시하여 이 짧은 목록에 추가했다. 이 모델은 8B와 70B의 두 가지 크기로 출시되었다. 라틴 아메리카에 초점을 맞춘 오픈 모델인 Latam-GPT는 이 분야에서 진행 중인 다른 지역적 노력 중 하나이다.
AI 모델 개발과 병행하여 AI 개발에서 윤리적 기준을 보장하는 것에 대한 관심이 증가하고 있다. 여기에는 편향, 프라이버시 및 AI 시스템 오용 가능성과 같은 우려 사항을 다루는 것이 포함된다. 그 결과, 책임 있는 AI 개발을 위한 프레임워크와 Google이 도입한 모델 카드 개념과 같은 윤리적 고려 사항을 문서화하기 위한 지침이 인기를 얻었지만, 연구에 따르면 의도하지 않은 부정적인 결과를 피하기 위해 계속해서 채택되어야 할 필요가 있다.
리눅스 재단의 프로젝트인 LF AI &amp; Data 재단은 협업과 혁신을 촉진하고 오픈 소스 프로젝트를 지원함으로써 오픈 소스 AI 환경에 큰 영향을 미쳤다. LF AI &amp; Data는 중립적인 플랫폼을 제공함으로써 개발자, 연구원 및 조직이 최첨단 AI 및 데이터 솔루션을 구축하고 중요한 기술적 문제를 해결하며 윤리적인 AI 개발을 촉진하기 위해 단결한다.
2024년 10월 현재, 이 재단은 북미, 유럽 및 아시아의 77개 회원사로 구성되어 있으며, 엔비디아, 아마존, 인텔, 마이크로소프트와 같은 실리콘밸리 거대 기업을 포함한 다양한 조직이 기여한 67개의 오픈 소스 소프트웨어(OSS) 프로젝트를 호스팅하고 있다. 알리바바, 틱톡, AT&amp;T 및 IBM과 같은 다른 대기업들도 기여했다. NYU, 미시간 대학교 AI 연구소, 컬럼비아 대학교, 펜실베이니아 주립 대학교와 같은 연구 기관도 LF AI &amp; Data 재단의 준회원이다.
2024년에 OSAID가 개발 중인 동안, 리눅스 재단은 AI 시스템 구성 요소에 대한 기준표를 개발하고 있었으며, 모델 개방성 프레임워크(MOF) 초안을 발표했다. MOF는 기계 학습 모델의 완전성과 개방성을 평가하고 분류하기 위한 시스템이다. 여기에는 더 개방적인 것부터 덜 개방적인 것까지 세 가지 개방성 클래스가 포함된다: 클래스 I: 오픈 사이언스 모델; 클래스 II: 오픈 툴링 모델; 클래스 III: 오픈 모델. 리눅스 재단은 OSAID 개발에 참여했으며, OSAID는 동일한 구성 요소 기준표를 채택했다.
2022년 9월, Meta가 기부한 널리 사용되는 PyTorch 딥러닝 프레임워크를 감독하기 위해 PyTorch 재단이 설립되었다. 재단의 임무는 PyTorch와 통합된 오픈 소스, 공급업체 중립 프로젝트의 생태계를 조성하고 유지하여 AI 도구 채택을 촉진하고, 최첨단 도구, 라이브러리 및 기타 구성 요소에 대한 접근을 민주화하여 이러한 혁신을 모든 사람이 접근할 수 있도록 하는 것이다.
PyTorch 재단은 또한 비즈니스 및 기술 거버넌스를 분리하여 PyTorch 프로젝트는 기술 거버넌스 구조를 유지하고, 재단은 자금 조달, 호스팅 비용, 이벤트 및 프로젝트 웹 사이트, GitHub 저장소, 소셜 미디어 계정과 같은 자산 관리를 처리하여 개방형 커뮤니티 거버넌스를 보장한다. 재단 설립 시, 초기 회원사인 AMD, 아마존 웹 서비스, 구글 클라우드, 허깅 페이스, IBM, 인텔, Meta, 마이크로소프트 및 엔비디아의 대표들로 구성된 이사회를 구성했다.
오픈 소스 AI는 대형 언어 모델 (LLM)의 개발 및 채택을 지원했다. OpenAI의 GPT 시리즈와 같은 독점 모델이 대화형 시스템 및 자동화된 콘텐츠 생성과 같은 응용 분야에서 가능한 것을 재정의한 반면, 완전 오픈 소스 모델도 상당한 발전을 이루었다. Google의 BERT는 엔티티 인식 및 언어 번역과 같은 작업에 널리 사용되는 오픈 소스 모델로, NLP에서 다재다능한 도구로 자리매김했다. 이러한 오픈 소스 LLM은 고급 언어 기술에 대한 접근을 민주화하고 독점 시스템에 대한 의존도를 줄였다.
Hugging Face의 MarianMT는 광범위한 언어 쌍을 지원하는 기계 번역의 한 예이다. 또 다른 주목할 만한 모델은 OpenNMT이다. 이러한 오픈 소스 모델과 함께 유럽의회 말뭉치 및 OPUS를 포함한 WMT (Workshop on Machine Translation) 데이터 세트와 같은 오픈 소스 데이터 세트가 이 분야에 기여하며 개발자들이 특정 언어에 대한 모델을 훈련하고 미세 조정하는 데 도움을 준다.
컴퓨터 비전 모델.
OpenCV와 같은 라이브러리는 이미지 인식, 동작 추적 및 얼굴 감지와 같은 실시간 컴퓨터 비전 응용 프로그램을 지원한다. 원래 인텔에서 개발한 OpenCV는 컴퓨터 비전을 위한 가장 인기 있는 라이브러리 중 하나가 되었다. YOLO (You Only Look Once) 및 Detectron2를 포함한 다른 오픈 소스 컴퓨터 비전 모델도 유사한 기능을 제공한다.
이전 세대의 컴퓨터 비전 모델은 컨볼루션 레이어를 통해 이미지 데이터를 처리했지만, 새로운 세대의 컴퓨터 비전 모델은 비전 트랜스포머를 사용한다. 이는 이미지를 작은 패치로 분할하여 이미지에서 가장 관련성이 높은 영역을 식별하며 일반적으로 더 정확한 결과를 생성한다.
오픈 소스 인공지능은 학계와 산업계 모두에서 유연하고 확장 가능한 개발 환경을 제공함으로써 로봇공학에 상당한 영향을 미쳤다. 로봇 운영체제 (ROS)는 개발자들이 다양한 하드웨어 플랫폼과 로봇 아키텍처에서 작업하는 데 사용하는 프레임워크의 한 예이다. 가제보는 실제 배포 전에 가상 환경에서 로봇 시스템을 테스트하는 데 사용되는 또 다른 오픈 소스 로봇 시뮬레이션 소프트웨어이다.
보건분야.
의료 산업에서 오픈 소스 AI는 진단, 환자 관리 및 개인 맞춤형 치료 옵션에 사용되었다. 오픈 소스 라이브러리는 종양 감지와 같은 작업을 위한 의료 영상 분야에서 사용되어 진단 과정의 속도와 정확성을 향상시켰다. 또한, 화학 및 생물학 응용 분야에 특별히 맞춰진 오픈 소스 라이브러리인 OpenChem은 약물 발견을 위한 예측 모델 개발을 가능하게 하여 연구자들이 치료를 위한 잠재적 화합물을 식별하는 데 도움을 준다.
Meta가 오픈 소스로 설명한 Meta의 Llama 모델은 중국 인민해방군 (PLA)과 제휴한 중국 연구자들의 무단 개조가 드러난 후 록히드 마틴 및 오라클과 같은 미국 국방 계약업체에 채택되었다. 오픈 소스 이니셔티브 및 기타 기관들은 Llama의 라이선스에 비미국 군사적 사용을 포함한 사용 사례를 금지하는 이용 목적 제한 방침이 포함되어 있기 때문에 Meta가 Llama를 오픈 소스로 설명한 것에 대해 이의를 제기했다. 중국 연구자들은 Llama의 초기 버전을 사용하여 군사 정보 및 의사 결정에 최적화된 ChatBIT와 같은 도구를 개발했으며, 이에 Meta는 국가 안보를 위해 기술이 전략적으로 사용될 수 있도록 미국 계약업체와의 파트너십을 확장했다. 이러한 응용 분야에는 이제 물류, 유지 보수 및 사이버 보안 강화가 포함된다.
접근의 민주화.
오픈 소스 AI는 최첨단 도구에 대한 접근을 민주화하여 자원이 부족할 수 있는 개인 및 소규모 조직의 진입 장벽을 낮춘다. 이러한 기술을 자유롭게 사용할 수 있도록 함으로써 오픈 소스 AI는 개발자들이 재정적 제약으로 인해 접근하기 어려웠던 AI 솔루션을 혁신하고 만들 수 있도록 하여 독립 개발자, 연구원, 소규모 조직 및 스타트업이 독점 소프트웨어 라이선스의 재정적 부담 없이 고급 AI 모델을 활용할 수 있도록 한다. 이러한 경제성은 개발자들이 기존 모델을 수정하여 고유한 요구 사항을 충족할 수 있으므로 틈새 또는 전문화된 응용 분야에서 혁신을 장려한다.
협업 및 더 빠른 발전.
코드, 데이터 및 연구 결과를 공유함으로써 오픈 소스 AI는 집단적 문제 해결 및 혁신을 가능하게 한다. 텐서플로 및 PyTorch와 같은 프레임워크 개발에서 볼 수 있는 대규모 협업은 기계 학습 (ML) 및 딥 러닝 분야의 발전을 가속화했다.
이러한 플랫폼의 오픈 소스 특성은 또한 전 세계의 기여자(contributor)들이 기존 도구에 대한 수정 및 개선 사항을 제안할 수 있으므로 빠른 반복 및 개선을 용이하게 한다. ML 및 딥 러닝 내의 직접적인 개선을 넘어 이러한 협업은 공유된 지식과 전문 지식이 결합됨에 따라 AI 제품의 더 빠른 발전으로 이어질 수 있다.
공평한 개발.
개발 프로세스의 개방성은 다양한 기여를 장려하여 소외된 그룹도 AI의 미래를 형성할 수 있도록 한다. 이러한 포용성은 더욱 공평한 개발 환경을 조성할 뿐만 아니라 더 큰 이윤 중심의 기업들이 간과할 수 있는 편향을 해결하는 데 도움이 된다. 다양한 관점의 기여를 통해 오픈 소스 AI는 전 세계 커뮤니티에 더 공정하고 책임감 있으며 영향력 있는 기술을 만들 잠재력을 가지고 있다.
투명성과 불투명성.
오픈 소스 AI의 한 가지 주요 이점은 폐쇄형 대안과 비교하여 제공하는 향상된 투명성이다. 오픈 소스 모델을 통해 기본 알고리즘과 코드를 검사할 수 있으므로 책임감을 높이고 개발자가 모델이 결론에 도달하는 방식을 이해하는 데 도움이 된다. 또한 Llama 및 스테이블 디퓨전과 같은 오픈 웨이트 모델을 통해 개발자는 모델 매개변수에 직접 접근할 수 있어 응용 분야에서 편향을 줄이고 공정성을 높이는 데 도움이 될 수 있다. 이러한 투명성은 특히 의료, 형사 사법 및 금융과 같은 중요한 응용 분야에서 AI 시스템이 내린 결정의 결과가 상당할 수 있는 경우 (그러나 우려 사항 섹션에서 언급된 특정 위험을 초래할 수도 있음) 인간이 읽을 수 있는 출력을 가진 시스템, 즉 "설명 가능한 AI"를 생성하는 데 도움이 될 수 있다.
개인정보 보호 및 독립성.
Nature 사설은 의료 서비스가 언제든지 중단될 수 있고 평가하기 어렵고 환자 프라이버시를 위협할 수 있는 AI 모델에 의존하게 될 수 있다고 제안한다.&lt;ref name="10.1038/d41586-023-03803-y"&gt;&lt;/ref&gt; 저자들은 전 세계의 의료 기관, 학술 연구원, 임상의, 환자 및 기술 기업이 협력하여 기본 코드와 기본 모델에 쉽게 접근할 수 있고 자체 데이터 세트로 자유롭게 미세 조정할 수 있는 의료용 오픈 소스 모델을 구축해야 한다고 제안한다.
품질 및 보안.
현재 오픈 소스 모델은 대부분의 작업에서 폐쇄형 모델보다 성능이 떨어지지만, 오픈 소스 모델은 격차를 좁히기 위해 더 빠르게 개선되고 있다.
모델의 오픈 소스 개발은 이론적인 위험을 가질 수 있다고 여겨져 왔다. 일단 모델이 공개되면 심각한 보안 문제가 감지되더라도 롤백하거나 업데이트할 수 없다. 예를 들어, 오픈 소스 AI는 옴진리교와 같은 바이오테러리즘 그룹이 AI 모델의 파인 튜닝 및 기타 안전 장치를 제거하여 AI가 더 파괴적인 테러 계획을 개발하는 데 도움을 줄 수 있도록 허용할 수 있다. 실제 테러 계획을 개발하는 데 주요 장애물은 필요한 재료와 장비에 대한 엄격한 제한에 있다. 또한, AI 발전의 빠른 속도는 오래된 모델을 사용하는 것을 덜 매력적으로 만들며, 이는 공격에 더 취약하지만 능력도 떨어진다.
2024년 7월, 미국은 모델 가중치 공개를 제한할 충분한 증거를 찾지 못했다고 명시한 대통령 보고서를 발표했다.
공평성, 사회적 및 윤리적 함의.
인공지능이 의도치 않게 편향된 제품을 만들어낸 수많은 사례가 있었다. 주목할 만한 예로는 아프리카계 미국인의 미래 범죄 및 재범 위험을 백인보다 높게 예측하는 AI 소프트웨어, 비원어민 화자에게 성능이 떨어지는 음성 인식 모델, 여성과 피부색이 어두운 사람에게 성능이 떨어지는 안면 인식 모델 등이 있다.
연구원들은 또한 오픈 소스 인공지능이 기존의 보안 및 윤리적 문제로 인해 비판을 받아왔다. Bandit, FlawFinder 및 Semgrep과 같은 취약점 스캐너를 사용하여 허깅 페이스와 깃허브에 있는 100,000개 이상의 오픈 소스 모델을 분석한 결과 30% 이상의 모델이 심각한 취약점을 가지고 있는 것으로 나타났다. 또한, 폐쇄형 모델은 일반적으로 오픈 소스 모델보다 안전 위험이 적다. 오픈 소스 모델을 증강할 수 있는 자유는 개발자들이 GPT4-Chan과 같이 윤리적 지침 없이 모델을 출시하게 만들었다.
편향된 데이터, 모델 생성의 결함, 이러한 결과의 가능성을 인식하거나 계획하지 못하는 등의 원인으로 인해 불공평하고 편향된 AI 결과로 이어질 수 있는 수많은 시스템적 문제가 존재한다. 연구에서 강조되었듯이, 데이터 세트에서 특정 인구 통계 그룹의 과소 대표와 같은 낮은 데이터 품질과 데이터 큐레이션 과정에서 발생하는 편향은 왜곡된 모델 출력으로 이어진다.
오픈 소스 AI 프로젝트에 대한 연구에 따르면 데이터 품질 검증에 실패했으며, 프로젝트의 28% 미만이 문서에 데이터 품질 문제를 포함했다. 이 연구는 또한 개발자들이 모델의 윤리적 함의에 충분한 강조를 두지 않으며, 개발자들이 윤리적 함의를 고려할 때에도 특정 지표 (모델의 동작)에 과도하게 초점을 맞추고 다른 지표 (데이터 품질 및 위험 완화 단계)를 간과하는 더 광범위한 우려를 보여주었다.
투명성 및 "블랙박스".
안전 및 편향과 같은 문제와 관련하여 많은 AI 시스템의 또 다른 주요 우려 사항은 투명성 부족이다. 많은 오픈 소스 AI 모델은 "블랙박스"로 작동하며, 의사 결정 과정을 생성자조차 쉽게 이해할 수 없다. 이러한 해석 가능성 부족은 책임감을 방해하여 모델이 특정 결정을 내린 이유를 식별하거나 다양한 그룹에 걸쳐 공정하게 작동하는지 확인하기 어렵게 만들 수 있다.
또한, AI 모델이 폐쇄형(독점형)일 경우, 널리 채택된 수많은 안면 인식 시스템의 경우와 같이 편향된 시스템이 간과될 수 있다. 이러한 숨겨진 편향은 독점 시스템이 AI가 내린 결정에 대한 신뢰 구간과 같이 이러한 편향을 드러내는 데 도움이 될 수 있는 결정 과정에 대해 아무것도 공개하지 않을 때 지속될 수 있다. 특히 의료 분야에서 사용되는 시스템의 경우, 시스템의 추론을 보고 이해하거나 답변이 어떻게 얻어졌는지에 대한 "[정확한] 설명"을 얻는 것은 "신뢰와 투명성을 보장하는 데 중요하다".
개선을 위한 프레임워크.
이러한 문제에 대응하기 위한 노력은 AI의 윤리적 개발 및 배포를 안내하는 구조화된 문서화 프레임워크의 개발로 이어졌다.
AI 사용이 증가함에 따라 AI 투명성을 높이고 모델 편향을 줄이는 것이 점점 더 강조되는 우려 사항이 되었다. 이러한 프레임워크는 개발자와 이해 관계자가 편향을 식별하고 완화하여 AI 시스템의 공정성과 포용성을 증진하는 데 도움이 될 수 있다.
C++26은 C++23에 이어 C++ 프로그래밍 언어를 위한 국제 표준화 기구(ISO) 및 국제전기기술위원회(IEC) 14882 표준 버전의 비공식 이름이다. 이 버전의 현재 작업 초안은 N5014이다. C++ 표준 위원회에서 표준에 제안되고 채택된 문서와 2025년 6월 불가리아 소피아 및 온라인에서 개최된 표준화 회의록이 공개되어 있다. 초안의 문구는 기능적으로 완성되었으며, 국제 의견 투표를 위해 발송되고 있다. 2025년 11월 하와이 코나에서 열린 표준화 회의에서 일부 투표 의견을 해결한 후, C++ 표준 위원회는 투표 의견 해결을 완료하고 초안을 기술적으로 확정하며, 2026년 3월 런던에서 열리는 다음 표준화 회의에서 최종 승인 투표를 위해 초안을 발송할 것으로 예상된다. 일부 곧 출시될 기능을 구현한 실험적이고 표준 컴파일러는 Compiler Explorer를 통해 짧은 코드 스니펫에서 시도할 수 있다. 일부 컴파일러 변형은 "constexpr containers and adaptors"를 위한 "P3372"와 같이 구현하는 새로운 기능을 제안하는 문서의 짧은 식별자로만 구별된다.
C++26에 채택된 변경 사항은 다음과 같다.
초안이 기능적으로 완성된 소피아 C++ 표준 위원회 회의와 그 직후 열린 국제 C++ 컨퍼런스인 C++ On Sea에서 여러 사람들이 여행 보고서를 발표했다. 모두 특히 컴파일 시점 반영의 도입을 주요 변경 사항으로 강조했다. 허브 서터는 C++ 표준 위원회의 "언어 진화" 실무 그룹의 부의장인 하나 두시코바의 말을 인용하며, 이 변경 사항의 잠재적 영향을 "완전히 새로운 언어"라고 요약했다.
C++26의 계약 기능은 다양한 이유로 C++ 위원회 내 일부 사람들에 의해 비판을 받아왔다.
C++23, 공식적으로 ISO/IEC 14882:2024,는 C++20에 이어지는 C++ 프로그래밍 언어의 현재 개방형 표준이다. 이 버전의 최종 초안은 N4950이다.
2020년 2월, 프라하에서 열린 C++20 최종 회의에서 C++23에 대한 전체 계획이 채택되었다. C++23의 계획된 기능은 코루틴을 위한 라이브러리 지원, 모듈화된 표준 라이브러리, 실행자(executor), 네트워킹이었다.
C++23에 초점을 맞춘 첫 WG21 회의는 2020년 6월 초 바르나에서 열릴 예정이었으나, 코로나19 범유행으로 인해 취소되었다. 2020년 11월 뉴욕 회의와 2021년 2월 코나(Kona) 회의도 마찬가지였다. 2022년 11월까지 모든 회의는 가상으로 진행되었고, 2022년 11월 회의부터 2023년 2월 최종 회의까지는 하이브리드 형식으로 진행되었다. 이 표준은 2023년 2월 이서콰에서 열린 하이브리드 회의에서 WG21에 의해 기술적으로 최종 확정되었다.
현대적인 "Hello, world" 예제.
작업 초안에 많은 라이브러리 변경 사항이 적용된 후, 새로운 "Hello, world" 프로그램은 다음과 같다.
std::println("Hello, world!");
C++23에 승인된 변경 사항은 다음과 같다.
제거된 기능 및 폐기.
제거된 기능:
폐기된 기능:
복원된 폐기된 기능:
대면 WG21 회의가 없는 상황에서, 다음 변경 사항들은 여러 가상 WG21 회의 후 적용되었으며, 여기서 여론조사(straw poll)를 통해 승인되었다.
2020년 11월 9일 가상 WG21 회의 후 다음 사항들이 추가되었으며, 여론조사를 통해 승인되었다.
2021년 2월 22일 가상 WG21 회의 후, 다음 기능들이 추가되었으며 여론조사를 통해 승인되었다.
2021년 6월.
2021년 6월에 열린 여름 ISO C++ 표준 본회의 가상 회의 후, 새로운 기능과 결함 보고서가 여론조사를 통해 승인되었다.
2021년 10월.
2021년 10월에 열린 2021년 가을 ISO C++ 표준 본회의 가상 회의 후, 새로운 기능과 결함 보고서가 여론조사를 통해 승인되었다.
2022년 2월.
2022년 2월 7일 가상 WG21 회의 후, 다음 기능들이 추가되었으며 여론조사를 통해 승인되었다.
2022년 7월 25일 가상 WG21 회의 후, 다음 기능 및 결함 보고서가 추가되었으며 여론조사를 통해 승인되었다.
2022년 11월 7일 하이브리드 WG21 회의 후, 다음 기능 및 결함 보고서가 추가되었으며 여론조사를 통해 승인되었다.
2023년 2월.
2023년 2월 6일부터 11일까지 열린 최종 하이브리드 WG21 회의 후, 다음 기능 및 결함 보고서가 추가되었으며 여론조사를 통해 승인되었다.
C++03은 C++ 프로그래밍 언어에 대한 ISO/IEC 14882 표준의 한 버전이다. 이는 국제 표준화 기구 (ISO)와 국제전기기술위원회 (IEC)의 두 표준화 기구에 의해 ISO/IEC 14882:2003 표준으로 정의된다.
C++03은 이전 C++98 표준을 대체했다. C++03은 나중에 C++11로 대체되었다. C++03은 주로 구현자들이 더 큰 일관성과 이식성을 보장하기 위한 버그 수정 릴리스였다. 이 개정판은 92개의 핵심 언어 결함 보고서를 다루었으며, 125개의 라이브러리 결함 보고서를 다루었고, 단 하나의 새로운 언어 기능인 값 초기화만 포함했다.
C++03에서 다루어진 가장 주목할 만한 결함 보고서 중 하나는 라이브러리 결함 보고서 69였으며, 이 보고서의 해결은 벡터의 요소가 연속적으로 저장되어야 한다는 요구 사항을 추가했다. 이는 C++ codice_1 객체가 배열과 유사한 메모리 레이아웃을 사용한다는 일반적인 기대를 코드로 명시한 것이다. 대부분의 구현이 이러한 기대를 충족했지만, C++98에서는 필수가 아니었다.
C17은 공식적으로 ISO/IEC 9899:2018이며, C 프로그래밍 언어의 개방형 표준이다. 2017년에 준비되어 2018년 7월 5일에 출판되었다. 이 표준은 C11 (ISO/IEC 9899:2011 표준)을 대체했으며, 2024년 10월부터는 C23 (ISO/IEC 9899:2024)으로 대체되었다. 2017년에 개발 중이었고 2018년에 공식적으로 출판되었기 때문에 C17은 때때로 C18이라고도 불린다.
C11으로부터의 변경 사항.
C17은 새로운 언어 기능을 도입하지 않고 C11의 수많은 사소한 결함을 수정했다.
codice_1 매크로는 codice_2 값으로 증가되었다.
이전 표준으로부터의 변경 사항에 대한 자세한 목록은 C11에 대한 Clarification Request Summary를 참조한다. 변경 사항의 예로는 codice_3, codice_4, 오타 등에 대한 수정이 포함된다.
C17을 지원하는 컴파일러 목록:
포터블 C 컴파일러(Portable C Compiler, pcc 또는 때로는 pccm - portable C compiler machine으로도 알려져 있음)는 1970년대 중반 벨 연구소의 스티븐 C. 존슨이 작성한 C 프로그래밍 언어용 초기 컴파일러로, 1973년 앨런 스나이더가 제안한 아이디어에 부분적으로 기반을 두었다. 데니스 리치의 승인 하에 "벨 연구소의 C 컴파일러로 배포되었다."
다양한 컴퓨터 아키텍처용 코드를 쉽게 출력하도록 조정할 수 있는 최초의 컴파일러 중 하나였던 pcc는 긴 수명을 가졌다. Seventh Edition Unix에서 처음 등장하여 1994년 4.4BSD가 출시될 때까지 BSD와 함께 제공되었으며, 이후 GNU 컴파일러 모음으로 대체되었다. 당시 매우 영향력이 커서 1980년대 초에는 대부분의 C 컴파일러가 이를 기반으로 했다. 앤더스 마그누손(Anders Magnusson)과 피터 A 존슨(Peter A Jonsson)은 2007년에 pcc 개발을 다시 시작하여 C99 표준을 지원하기 위해 광범위하게 재작성했다.
pcc의 주요 특징은 이식성과 향상된 진단 기능이다. 이 컴파일러는 소스 파일 중 일부만이 기계 종속적이도록 설계되었다. 구문 오류에 비교적 강하고 동시대의 컴파일러보다 더 철저한 유효성 검사를 수행한다.
데니스 리치가 작성한 최초의 C 컴파일러는 재귀 하향 파서를 사용했고, PDP-11에 대한 특정 지식을 포함했으며, 생성된 어셈블리 언어 코드를 개선하기 위해 선택적인 기계별 최적화 도구에 의존했다. 대조적으로, 존슨의 pccm은 Yacc로 생성된 파서를 기반으로 했으며 더 일반적인 타겟 머신 모델을 사용했다. 두 컴파일러 모두 타겟별 어셈블리 언어 코드를 생성한 다음 이를 어셈블하여 링크 가능한 오브젝트 모듈을 생성했다.
벨 연구소에서 "QCC" 및 "RCC"로 알려진 후기 버전의 PCC는 다른 타겟 아키텍처 모델을 지원했다.
PCC가 구현하는 언어는 비야네 스트롭스트룹이 "클래식 C"라고 부른 K&amp;R C의 확장 버전으로, `void` 반환 타입(값을 반환하지 않는 함수용), 열거형 및 구조체 할당을 포함한다.
스티브 존슨의 원본을 기반으로 한 새로운 버전의 pcc는 앤더스 매그너슨이 관리하고 있다. 이 컴파일러는 BSD 라이선스 하에 제공되며, 그 개발은 BSD 펀드라는 비영리 단체의 자금 지원을 받는다. 매그너슨에 따르면:
이 새로운 버전은 2007년 9월 NetBSD pkgsrc 및 OpenBSD 소스 트리에 추가되었고, 나중에 주 NetBSD 소스 트리에 추가되었다. 한때 BSD 기반 운영체제에서 GNU 컴파일러 모음을 대체할 수 있을 것이라는 추측이 있었지만, FreeBSD 및 NetBSD는 모두 클랭을 잠재적 대체재로 보고 있으며, OpenBSD의 테오 드 라트는 pcc가 아직 gcc를 대체할 준비가 되어 있지 않으며 gcc 제거가 최우선 순위는 아니라고 주장한다. 2009년 12월 29일, pcc는 기능적인 X86 OpenBSD 커널 이미지를 빌드할 수 있게 되었다.
pcc 버전 1.0은 2011년 4월 1일에 출시되었다.
이 릴리스부터 컴파일러는 X86 및 X86-64 프로세서 아키텍처를 지원하며 NetBSD, OpenBSD, FreeBSD, 다양한 리눅스 배포판 및 마이크로소프트 윈도우에서 실행된다.
더 많은 아키텍처 지원과 FORTRAN 77 및 C++ 프런트엔드를 포함한 추가 개발은 2022년 현재 진행 중이다.
PCC는 2012년에 OpenBSD 소스 트리에서 제거되었다. 개발이 정체되었고 GNU 컴파일러 모음의 실질적인 대안이 될 수 있도록 개발할 관리자가 나타나지 않았기 때문이다.
pcc의 최신 버전인 1.1.0은 2014년 12월 10일에 출시되었다.
타이니 C 컴파일러(Tiny C Compiler), TCC, tCc 또는 TinyCC는 파브리스 벨라르가 처음 작성한 x86 (32비트), X86-64 및 ARM 프로세서용 C 컴파일러이다. 디스크 공간이 적은 느린 컴퓨터(예: 구조 디스크)에서 작동하도록 설계되었다. 윈도우 운영체제 지원은 버전 0.9.23(2005년 6월 17일)에 추가되었다. TCC는 GNU 약소 일반 공중 사용 허가서에 따라 배포된다.
TCC는 ANSI C (C89/C90)의 모든 기능을 구현한다고 주장하며, C99 ISO 표준의 대부분과 인라인 어셈블리를 포함한 많은 GNU C 확장 기능을 구현한다.
TCC는 다른 최신 C 컴파일러와 구별되는 여러 기능을 가지고 있다.
컴파일된 프로그램 성능.
일반적으로 TCC의 구현은 최적의 성능을 내는 결과보다는 작음에 중점을 둔다. TCC는 단일 패스로 코드를 생성하며, 다른 컴파일러에서 수행하는 대부분의 최적화를 수행하지 않는다. TCC는 각 문장을 자체적으로 컴파일하며, 각 문장 끝에서 레지스터 값은 스택에 다시 기록되고 다음 줄에서 레지스터의 값을 사용하더라도 다시 읽어야 한다(문장 사이에 불필요한 저장/로드 쌍을 생성함). TCC는 사용 가능한 레지스터 중 일부만 사용한다 (예: x86에서는 함수 호출 시 보존되어야 하므로 ebx, esi 또는 edi를 사용하지 않는다).
TCC는 몇 가지 최적화를 수행하는데, 모든 연산에 대한 상수 전파, 적절한 경우 곱셈과 나눗셈을 시프트로 최적화하고, 비교 연산자는 특별히 최적화된다 (프로세서 플래그에 대한 특수 캐시를 유지하여). 또한 단순한 레지스터 할당을 수행하여 단일 문 내에서 많은 불필요한 저장/로드 쌍을 방지한다.
다음은 두 가지 벤치마크 예시이다.
TCC는 2001년 IOCCC에서 벨라르가 우승하기 위해 작성한 프로그램인 Obfuscated Tiny C Compiler (OTCC)에서 비롯되었다. 그 후 벨라르는 프로그램을 확장하고 난독화를 해제하여 tcc를 만들었다.
2012년 2월 4일 이전에 파브리스 벨라르는 자신이 더 이상 TCC 작업에 참여하지 않는다고 보고하기 위해 프로젝트의 공식 웹페이지를 업데이트했다.
벨라르가 프로젝트에서 떠난 이후, 다양한 사람들과 그룹들이 TCC를 기반으로 구축하거나 문제를 해결하기 위해 TCC의 패치를 배포하거나 포크를 유지해왔다. 여기에는 데이브 닷지의 비공식 tcc 패치 모음, 데비안 및 kfreebsd 다운스트림 패치, 그리고 그리쉬카의 gcc 패치가 포함된다. 그리쉬카는 또한 프로젝트를 위한 공개 Git 저장소를 설정했다. 이 저장소에는 공유 빌드, 크로스 컴파일러, SELinux 호환성 등 수많은 기여가 추가된 mob 브랜치가 포함되어 있다. 그리쉬카의 GIT 저장소는 나중에 공식 TCC 저장소가 되었다 (파브리스 벨라르의 Savannah 프로젝트 페이지에 링크됨).
2017년 12월 현재 공식 TCC 메일링 리스트와 공식 Git 저장소(파브리스 벨라르의 Savannah 프로젝트 페이지에 링크됨) 모두 많은 개발자와 관심 있는 사용자들의 활발한 토론과 개발을 보여준다. 2017년 12월, 그리쉬카는 메일링 리스트에서 TCC 버전 0.9.27이 출시되었다고 발표했다.
LCC("Local C Compiler" 또는 "Little C Compiler")는 ANSI C 프로그래밍 언어를 위한 작고 재표적화 가능한 컴파일러이다. 소스 코드는 개인 용도로 무료로 제공되지만, LCC에서 파생된 제품은 판매할 수 없으므로 일반적인 정의에 따르면 오픈 소스 또는 자유 소프트웨어가 아니다. 단, LCC에서 파생되지 않은 구성 요소는 판매할 수 있다. 이 컴파일러는 크리스 프레이저와 데이비드 핸슨이 개발했다.
LCC.
LCC는 이해하기 매우 간단하고 문서화가 잘 되어 있다. 이 컴파일러의 설계는 프레이저와 핸슨의 저서인 "재표적화 가능한 C 컴파일러: 설계 및 구현(A Retargetable C Compiler: Design and Implementation)"에 설명되어 있다. 이 책에는 노웹을 사용하여 문학적 프로그램으로 작성된 컴파일러 버전 3.6의 대부분의 소스 코드가 포함되어 있다. 2011년 7월 현재 LCC의 최신 버전은 4.2이지만, 책의 많은 내용은 이 버전에도 여전히 적용된다. 책 출판 이후의 주요 변경 사항은 코드 생성기 인터페이스이며, 이는 별도의 문서에 설명되어 있다.
LCC의 소스 코드는 약 2만 줄로, 많은 주요 컴파일러보다 훨씬 작다.
LCC는 Alpha, SPARC, MIPS, x86을 포함한 여러 프로세서 아키텍처용 코드를 생성할 수 있다. 마이크로소프트의 공통 중간 언어를 생성하는 LCC 백엔드도 있다.
LCC를 통합한 프로젝트.
퀘이크 3.
이드 소프트웨어의 이드 테크 3 엔진은 LCC의 수정된 버전을 사용하여 각 게임 모듈 또는 타사 모드의 소스 코드를 가상 머신을 대상으로 하는 바이트코드로 컴파일한다. 이는 악의적인 모드 제작자가 제기하는 위협을 줄이기 위해 모듈이 시스템 호출과 엔진이 제공하는 제한된 파일 시스템 범위를 넘어 시스템에 무지하다는 것을 의미한다. 또 다른 고려 사항은 엔진용으로 작성된 게임과 모드가 재컴파일 없이 이식 가능하다는 것이다. 모듈을 실행하기 위해 이식만 하면 된다.
lcc-win.
lcc-win32는 마이크로소프트 윈도우용 통합 개발 환경 패키지로, LCC의 포크를 포함한다. 2012년 4월 15일부터 사용할 수 있는 lcc-win64라는 amd64 대응 버전도 있다.
펠레스 C.
Pelles C의 컴파일러는 C11 및 C17 지원, amd64 지원, 인라인 확장과 같은 추가 최적화 기법 및 IDE를 제공하는 LCC의 크게 수정된 버전이다.
매스웍스.
32비트 윈도우 머신의 경우, 매스웍스 매트랩 및 관련 제품에 다른 컴파일러가 설치되어 있지 않으면 Lcc가 기본값으로 사용된다.
LCC는 개인 용도로 무료이며, 모든 배포 미디어 및 제품 문서에 이를 인정하면 재배포할 수 있다. LCC 라이선스는 여러 경우에서 예시에 의존한다. LCC는 이윤을 목적으로 판매할 수 없지만, LCC 자체가 무료로 배포되는 한 이윤을 목적으로 판매되는 다른 소프트웨어와 함께 포함될 수 있다. 사용자별 및 무제한 사용 라이선스는 Addison-Wesley에 연락하여 얻을 수 있으며, 특히 C 컴파일러가 작업의 많은 부분을 구성할 수 있는 C++와 같은 언어의 컴파일러에 해당한다.
그놈 빌더(GNOME Builder)는 그놈 플랫폼을 위한 범용 통합 개발 환경 (IDE)으로, 주로 그놈 기반 애플리케이션 작성을 돕기 위해 설계되었다. 2015년 3월 24일에 처음 출시되었으며, Anjuta를 대체했다. 이 애플리케이션의 슬로건은 "그놈 기반 애플리케이션을 위한 도구 장인"이다.
GUADEC 2016에서 크리스티안 헤르거트(Christian Hergert)는 그놈 빌더의 다가오는 버전에 대한 를 제공했다. GTK Scene Graph Kit가 GTK에 병합되면 더 많은 기능이 통합될 것이다. sysprof는 포크되었고 버전 번호가 1.2.0에서 3.20으로 올라갔으며 버전 3.22에 통합되었다.
그놈 빌더는 GNOME 코드 어시스턴스를 사용하여 CSS, HTML, JS, JSON, 파이썬, 루비, SCSS, 셸 스크립트 및 XML에 대한 코드 진단을 제공한다. 파이썬 코드 완성에는 Jedi가 사용된다. C-like 언어의 코드 어시스턴스에는 클랭이 사용된다. 러스트 진단은 러스트 언어 서버와 통신하기 위해 Language Server Protocol을 사용하여 제공된다.
인터페이스의 대부분은 중앙에 위치한 코드 편집기에 할당된다. 편집기는 대부분의 프로그래밍 언어를 자동으로 인식하고 그에 따라 텍스트를 강조 표시한다. 버전 관리 시스템이 사용될 때, 줄 번호 옆의 색상 막대는 해당 줄의 변경 사항을 나타낸다. 지원되는 언어의 경우, 추가 기호가 오류가 있거나 형식이 잘못된 코드를 포함하는 줄을 강조 표시한다.
빌더는 빌더 자체, Vim과 유사한, 그리고 이맥스와 유사한 키보드 바인딩 사이를 전환할 수 있다.
코드 편집기 주변에는 추가 패널을 토글하여 볼 수 있다. 여기에는 프로젝트 트리, 터미널 창, 도움말 브라우저가 포함된다. 프로젝트 트리는 사용자가 파일 및 폴더 작업을 수행할 수 있도록 한다.
그놈 빌더의 개발은 2015년 1월 Indiegogo 플랫폼에서 크라우드펀딩되었다. 캠페인은 목표 자금 30,000달러의 187% (56,245달러)를 달성했다.
ISO 표준의 전자 및 로마자 표기법 목록:
ISO 259는 히브리 문자를 라틴 음소문자로 로마자를 표기하기 위한 국제 표준 시리즈로, 1984년에 제정되었으며, 업데이트된 ISO 259-2 (여러 모음 부호를 무시하고 단순화, 1994년) 및 ISO 259-3 (음소 변환, 1999년)이 있다.
ISO 259.
1984년에 제정된 ISO 259는 성서 히브리어에 사용되는 발음 구별 기호(니쿠드)를 포함한 히브리어 문자의 전자이다.
다게쉬(글자 안의 점)는 항상 위점으로 전사된다: ḃ, ġ, ż 등. 위 표의 아포스트로피(‎)는 일부 글자 뒤에 사용하여 비히브리어 소리를 표기하는 히브리어 부호 게레쉬이다:  ,  ,   등.
ISO 259-2.
ISO 259-2는 ISO 259의 모음 발음 구별 부호를 단순화한 것으로, 현대 히브리어를 위해 설계되었다.
다게쉬는 표시된 경우를 제외하고는 전사되지 않는다. 위 표의 아포스트로피(‎)는 일부 글자 뒤에 사용하여 비히브리어 소리를 표기하는 히브리어 부호 게레쉬이다.
ISO 259-3.
ISO 259-3은 우지 오르난의 로마자 표기법으로, ISO 최종 초안(FDIS) 단계에 이르렀지만 국제 표준(IS)으로 출판되지는 않았다. 이것은 히브리어의 다양한 방언이나 발음 스타일 전반에 걸쳐 히브리어 단어의 일반적인 구조를 전달하여, 사람과 기계 모두에 의해 원래 히브리어 문자로 재구성될 수 있도록 설계되었다.
이것은 히브리어의 한 발음 스타일을 문자 단위로 전자한 것도, 음성 전사한 것도 아니며, 오히려 여러 세대에 걸쳐 히브리어의 모든 다양한 방언과 발음이 동일한 구조의 다른 실현으로 간주될 수 있다는 관점에서 음소적이며, 미리 정의된 읽기 규칙에 따라 모든 발음 스타일이 직접 파생될 수 있다.
히브리어 문자의 각 자음 문자는 고유한 라틴 문자로 변환된다. ISO 259-3에는 모음 음소 5개에 해당하는 5개의 모음 문자가 있다: a, e, i, o, u. 이 외에, 일반적인 히브리어 철자에서 ⟨⟩ 뒤에 오는 또는 모음을 나타내는 여섯 번째 기호가 있다: .
다게쉬 하작(성서 히브리어의 중복 자음)은 이중 자음으로 전사된다. 다음과 같은 비음소적 모음은 무시된다:
ISO-259-3의 공식 제안은 히브리어 /에 해당하는 라틴 문자로 C/c만을 제시하지만, 오르난은 이를 Ç/ç로 대체 로마자 표기하는 것도 허용했고, 2008년 이 주제에 대한 논문에서 자신이 선호한다고 썼으며, 2003년 이전 논문에서는 특히 히브리어 지명(예: 이스라엘 도로 표지판)의 로마자 표기에 Ç/ç 사용을 권장했다.
조지아어의 로마자 표기법(Romanization of Georgian)은 조지아어를 조지아 문자에서 로마자로 전자하는 과정이다.
조지아 국가 로마자 표기 체계.
2002년 2월 조지아 국토측량학과 조지아 국립과학원 언어학 연구소에서 채택한 이 시스템은 조지아 문자를 로마자로 전자하는 시스템을 확립한다. 이 시스템은 1998년부터 운전면허증에 사용되어 왔다. 또한 2009년부터 BGN과 PCGN, 그리고 구글 번역에서도 사용된다.
비공식 로마자 표기 체계.
인기에도 불구하고 이 시스템은 때때로 모호함을 유발한다. 이 시스템은 주로 사회 네트워크, 인터넷 포럼, 채팅방 등에서 사용된다. 이 시스템은 각 키를 알파벳의 각 글자에 연결하는 일반적인 QWERTY 기반 조지아어 자판 배열의 영향을 크게 받는다 (T, W, R, S, J, Z, C 7개 문자는 Shift 키를 사용하여 다른 글자를 만든다).
ISO 9984:1996, "조지아 문자에서 라틴 문자로의 전자",는 2010년에 마지막으로 검토되고 확인되었다.
표준의 기본 원칙은 다음과 같다.
전자 표.
고대 문자는 빨간색 배경으로 표시된다.
문서 형식 의미·사양 기술 언어(Document Style Semantics and Specification Language, DSSSL)는 표준 일반화 마크업 언어 문서에 스타일시트를 제공하기 위해 개발된 국제 표준이다.
DSSSL은 문서를 표현하기 전에 문서의 트리 구조를 조작하는 데 사용할 수 있는 트리 변환 프로세스와 소스 문서의 요소를 대상 표현인 흐름 객체 트리의 특정 노드와 연결하는 서식 지정 프로세스의 두 부분으로 구성된다. DSSSL 사양은 서로 다른 플랫폼 간에 교환할 수 있는 장치 독립적인 정보이다. DSSSL은 언어의 출력을 생성하는 백엔드 포맷터를 표준화하지 않는다. 이러한 포맷터는 온스크린 표시를 위해 출력을 렌더링하거나 특정 형식(예: 포스트스크립트 또는 서식 있는 텍스트 포맷)의 컴퓨터 파일에 기록할 수 있다.
스킴 프로그래밍 언어의 하위 집합을 기반으로 하며, ISO/IEC 10179:1996 표준으로 지정되었다. ISO/IEC JTC 1/SC 34(ISO/IEC 합동 기술 위원회 1, 소위원회 34 - 문서 설명 및 처리 언어)에 의해 개발되었다.
SGML에는 기계가 읽을 수 있지만 인간이 읽을 수 있는 형식은 아닌 정보가 포함되어 있다. "스타일시트"는 SGML에 저장된 정보를 더욱 보기 좋거나 접근 가능한 방식으로 표시하는 데 사용된다. DSSSL은 RTF, HTML, LaTeX를 포함한 광범위한 형식으로 변환할 수 있다.
DSSSL은 모든 SGML 기반 문서 유형과 호환되지만 주로 닥북과 함께 사용되었다. 1997년, 소프트웨어 엔지니어 게일 오베 그론모(Geir Ove Grønmo)는 KEDIT용 구문 강조 언어 정의를 발표했다.
XML이 SGML의 대안으로 등장하면서 XML의 관련 스타일시트 언어인 XSL도 1999년경부터 널리 빠르게 채택되었다. DSSSL은 줄어드는 SGML 분야에서 계속 사용되었지만, XSL은 DSSSL이 이전에 달성했던 것보다 훨씬 더 광범위하게, 그리고 더 많은 코더에 의해 사용되기 시작했다. 이는 닥북과 같은 이전 SGML의 강자들이 SGML에서 XML로 전환하고, 선호하는 스타일시트 언어를 DSSSL에서 XSL로 전환하면서 더욱 강조되었다.
1994년 또는 그 이전에 제임스 클라크는 월드 와이드 웹 컨소시엄의 고려를 위해 "DSSSL 라이트" 사양 초안을 작성하기 시작했다. DSSSL이 월드 와이드 웹에 너무 복잡하다고 생각했기 때문이다.
ISO 31-4는 국제 표준 ISO 31의 한 부분으로, 열과 관련된 물리량과 물리 단위의 이름과 기호를 정의한다. ISO 80000-5로 대체되었다.
정의는 다음과 같다.
ISO 31-4의 부록 A는 피트, 파운드, 초를 기반으로 한 열 단위와 랭킨도, 화씨, 영국 열량 단위 및 기타 단위를 나열한다. 부록 B는 세 가지 버전의 칼로리에 대한 변환 계수를 나열한다.
ISO 31-5는 국제 표준 ISO 31의 일부로, 전기 및 자기에 관련된 물리량 및 물리 단위의 이름과 기호를 정의한다. 이 표준은 ISO 80000-6으로 대체되었다.
아래는 NIST 상수값에서 가져온 일부 정의이다.
ISO 31-6은 국제 표준인 ISO 31의 일부로, 빛과 관련 전자기파에 관련된 물리량 및 물리 단위의 명칭과 기호를 정의한다. 이 표준은 ISO 80000-7으로 대체되었다.
ISO 31-6은 1980년에 처음 발행되었고 1985년에 개정되었다. 1992년에 개정되었고 1998년에 수정되었다. 이 표준은 2008년에 ISO 80000-7으로 대체되면서 최종적으로 철회되었다.
1980년에 정의된 ISO 31-6의 정의는 다음과 같다:
ISO 31-7은 국제 표준 ISO 31의 일부로, 음향학과 관련된 물리량 및 물리 단위의 명칭과 기호를 정의한다. 이 표준은 ISO 80000-8로 대체되었다.
그 정의에는 다음이 포함된다:
ISO 31-8은 국제 표준인 ISO 31의 일부로, 물리화학 및 분자물리학과 관련된 물리량 및 물리 단위의 이름과 기호를 정의한다.
양 및 그 단위 표에서 ISO 31-8 표준은 물질의 기호를 아래첨자(예: cB, wB, pB)로 표시한다. 또한 물질의 기호와 상태는 일반적으로 같은 줄에 괄호 안에 넣는 것이 바람직하다고 명시한다(예: c(H2SO4)).
규범적 부속서.
부속서 A: 화학 원소의 이름 및 기호.
이 부속서는 원소 (화학) 번호 1(수소, H)부터 109(운닐레늄, Une)까지의 원자 번호순 원소 목록을 포함하며, 화학 원소의 이름과 표준 기호를 제공한다.
ISO 31-8:1992에 제공된 목록은 1998년 IUPAC "그린 북" Quantities, Units and Symbols in Physical Chemistry에서 인용되었으며, 표준 기호가 원소의 영어 이름과 관련이 없는 경우 정보 제공을 위해 괄호 안에 라틴어 이름을 추가하는 경우가 있다. 1992년 표준판이 발행된 이후 원자 번호 103을 초과하는 일부 원소는 발견되고 이름이 변경되었다.
부속서 B: 화학 원소 및 핵종의 기호.
화학 원소의 기호는 로마자(수직)로 작성되어야 한다. 기호 뒤에는 마침표를 찍지 않는다.
핵종 또는 분자를 지정하는 아래첨자 또는 위첨자는 다음 의미와 위치를 갖는다.
부속서 C: pH.
pH는 다음과 같이 조작적 정의된다. 용액 X의 경우, 먼저 갈바니 전지의 기전력 EX를 측정한다.
그리고 알려지지 않은 pH, pH(X)의 용액 X를 알려진 표준 pH, pH(S)의 용액 S로 대체하는 것 외에는 위와 다른 갈바니 전지의 기전력 ES를 측정한다. 그러면 X의 pH는 다음과 같이 얻어진다.
이렇게 정의된 pH는 차원 1의 양, 즉 단위가 없다. 표준 용액 S의 pH(S) 값은 Definitions of pH scales, standard reference values, measurement of pH, and related terminology. Pure Appl. Chem. (1985), 57, pp 531–542에 나열되어 있으며, 추가 세부 정보를 찾을 수 있다.
pH는 근본적인 의미를 갖지 않으며, 공식적인 정의는 실용적인 것이다. 그러나 0.1 mol/L 미만의 물질량 농도를 가지며 강염기성 또는 강산성이 아닌 묽은 수용액(2 &lt; pH &lt; 12)의 제한된 범위에서는 정의가 다음과 같다.
여기서 c(H+)는 수소 이온 H+의 물질량 농도를 나타내고 y1은 용액 내 전형적인 1가-1가 전해질의 활동 계수를 나타낸다.
ISO 31-10은 국제 표준인 ISO 31의 일부로서 핵반응 및 이온화 방사선과 관련된 물리량 및 물리 단위의 이름과 기호를 정의한다. 이 표준은 70개의 물리량과 단위에 대한 이름과 기호를 제공한다. 적절한 경우, 변환 계수도 제공된다. 이 표준은 2009년에 폐지되었고 ISO 80000-10으로 대체되었다.
정의에는 다음이 포함된다:
ISO 31-11:1992은 국제 표준 ISO 31의 일부로, 물리 과학 및 기술에 사용되는 수학적 기호 및 기호를 정의한다. 이 표준은 2009년 ISO 80000-2:2009로 대체되었고, 이후 2019년 로 개정되었다.
이 표준에는 수리논리학, 집합론, 산술 및 복소수, 함수 및 특수 함수와 값, 행렬, 벡터 및 텐서, 좌표계 및 기타 수학적 관계에 대한 기호 정의가 포함되었다.
ISO 217:2013 표준은 RA 및 SRA 용지 형식을 정의한다.
이 용지 시리즈는 재단되지 않은 원지이다. RA는 "raw format A"(원시 형식 A)의 약어이며 SRA는 "supplementary raw format A"(보조 원시 형식 A)의 약어이다. RA 및 SRA 형식은 해당 A 시리즈 형식보다 약간 크다. 이렇게 하면 나중에 크기에 맞게 잘라낼 인쇄물에 블리드(가장자리까지 잉크)가 허용된다. 이 용지는 인쇄 및 제본 후 A 형식에 맞게 잘라진다.
허용 오차.
RA 및 SRA 시리즈 형식의 용지는 formula_1의 종횡비를 갖도록 의도되었지만, 시작 형식의 치수는 정수 센티미터로 반올림되었다.
예를 들어, RA0 형식은 이론적인 치수 formula_2에서 860mm × 1220mm로 반올림되었다.
결과적인 실제 비율은 다음과 같다.
RA 시리즈의 크기는 ANSI/ASME Y14.1에 지정된 해당 인치 기반 미국 크기보다 약간 크다. 예를 들어 RA4는 대략 에 해당하고 ANSI A(별칭 미국 레터)는 로 정의된다.
ISO 128은 국제 표준화 기구(ISO)의 국제 표준으로, 기술 도면의 표시를 위한 일반 원칙, 특히 기술 도면에서 객체의 그래픽 표현을 다룬다.
주목성 확립.
다음 독립적이고 고품질의 출처는 ISO 128에 대한 중요한 내용을 제공한다:
2003년부터 ISO 128 계열은 1996년에서 2003년 사이에 시작된 15개 부분으로 확장되었다. 이 표준은 기술 도면의 실행 및 구조에 대한 일반 규칙 요약으로 시작한다. 그런 다음 선, 보기, 절단 및 단면, 그리고 기계, 건축, 토목 및 조선을 포함한 다양한 유형의 공학 도면에 대한 기본 관례를 설명한다. ISO 128은 수동 및 컴퓨터 기반 도면 모두에 적용되지만 3차원 CAD 모델에는 적용되지 않는다.
ISO 128 시리즈는 1922년에 처음 출판되고 1950년과 1968년에 업데이트된 도면, 투영 및 보기에 대한 이전 DIN 6 표준을 대체했다. ISO 128 자체는 1982년에 15페이지 분량의 문서로 직교 투영 방법에 대한 일반적인 표현 원칙을 명시하며 처음 발표되었다.
ISO 128의 여러 부분이 개별적으로 업데이트되었고 새로운 부분이 추가되었다(예: 2013년에 Part 15). 가장 최근 개정판은 2020년과 2022년에 발행되었다.
카파가, 카파 번호, 카파 넘버(Kappa number), 카파수는 표준화된 분석 방법으로 목재 펄프의 잔존 리그닌 함량 또는 표백성을 나타내는 지표이다.
카파가는 ISO 302:2004에 따라 결정된다. ISO 302는 모든 종류의 화학 및 반화학 펄프에 적용 가능하며 1–100 범위의 카파가를 제공한다. 카파가는 펄프가 소비하는 표준 과망가니즈산 칼륨 용액의 양을 측정하는 것이다. 이 측정값은 펄프에 헥센우론산이 존재하면 증가한다. 이 화합물은 화학 펄프화 과정에서 헤미셀룰로스에서 형성된다.
카파가는 제지소의 온라인 카파 분석기로 모니터링할 수 있지만, 이는 ISO 302:2004 방법으로 보정해야 한다.
카파가는 주어진 백색도를 가진 펄프를 얻기 위해 펄프 표백 중 필요한 화학 물질의 양을 추정한다. 필요한 표백제의 양은 펄프의 리그닌 함량과 관련이 있으므로, 카파가는 펄프화 공정의 리그닌 추출 단계의 효율성을 모니터링하는 데 사용될 수 있다. 이는 펄프의 잔존 리그닌 함량에 대략 비례한다.
표백성 펄프의 카파가는 25–30 범위이며, 자루 종이 펄프는 45-55 범위, 골판지 펄프는 60-110 범위이다.
비카트 연화점(Vicat softening point) 또는 비카트 경도(Vicat hardness)는 플라스틱과 같이 명확한 녹는점이 없는 재료의 연화점을 결정하는 방법이다. 단면이 인 원형 또는 사각형 평평한 바늘이 시편에 깊이로 관통할 때의 온도로 정의된다. 비카트 A 시험의 경우 의 하중이 사용된다. 비카트 B 시험의 경우 하중은 이다. 이 이름은 프랑스 엔지니어 루이 비카트의 이름을 따서 명명되었다.
비카트 연화점을 결정하는 표준으로는 ASTM D 1525와 ISO 306이 있으며, 이들은 대체로 동일하다.
열 변형 온도 대신 비카트 시험을 사용하여 연화점을 측정하는 한 가지 장점은 비카트가 사출 성형과 같은 공정으로 인해 발생하는 내부 응력에 덜 민감하다는 것이다.
비카트 연화 온도는 다양한 재료의 열 특성을 비교하는 데 사용될 수 있다.
네 가지 다른 시험 방법을 사용할 수 있다.
ISO 10350 참고
ISO 10350 비카트 값은 B50 방법으로 시험된다.
유사 표준: ASTM D1525
프론토르-콤푸르(Prontor-Compur) 연결, PC 커넥터, PC 터미널 또는 PC 소켓은 사진에서 셔터를 플래시에 동조하는 데 사용되는 표준 전기 커넥터(ISO 519에 정의됨)이다.
"프론토르(Prontor)"는 이탈리아어 "프론토(pronto)"에서 유래했으며, "준비된"을 의미한다 (가 만든 리프 셔터였다). "콤푸르(Compur)"는 "컴파운드(compound)"라는 단어에서 파생되었다 (""는 프리드리히 데켈이 만든 오랫동안 사용된 리프 셔터 시리즈였다).