글을 snake_case로 변환 underscore_case 무료 온라인 안전

한 줄 붙여 넣으면 바로 snake_case로 읽힙니다. 모두 여러분의 브라우저 안에서 일어나고, 입력한 것은 어디로도 보내지지 않으며, 규칙은 영어가 아니라 이 쪽의 언어를 따릅니다.

다르게 써 보기

밑줄로 이은 낱말

당신의 글

결과

이 표기에 대하여

하는 일 줄을 낱말로 자르고 소문자로 바꾼 뒤 밑줄로 잇습니다. 이미 camelCase로 쓰인 줄은 거기서도 잘리므로 “fooBar”는 “foo_bar”가 됩니다.

하지 않는 일 문장 부호는 남지 않습니다. 쉼표, 마침표, 줄표는 낱말 사이의 경계이지 가져갈 글자가 아닙니다 — 파일 이름이나 데이터베이스 열 이름에는 바라는 바이고, 산문에는 아닙니다.

그리고 언어 낱말로 자르려면 경계가 있어야 합니다. 중국어와 일본어는 띄어쓰기를 하지 않으므로 그 문자로 쓴 줄은 한 낱말로 돌아옵니다 — 짐작한 자리에서 자르느니 그렇게 말하는 쪽을 택합니다.

어디에서 도는가 여러분의 브라우저 안에서. 여기 입력한 것은 어디로도 보내지지 않습니다 — 초고도, 비밀번호도, 거래처 이름도 텍스트 편집기만큼 안전합니다.

업로드 없음

같은 줄을, 일곱 가지 표기 모두로

표기	같은 줄을, 그 표기로
대문자	CRÈME BRÛLÉE 2인분 — STRASSE 17, FOOBAR
소문자	crème brûlée 2인분 — straße 17, foobar
Title Case	Crème Brûlée 2인분 — Straße 17, Foobar
snake_case	crème_brûlée_2인분_straße_17_foo_bar
kebab-case	crème-brûlée-2인분-straße-17-foo-bar
camelCase	crèmeBrûlée2인분Straße17FooBar
URL 주소	creme-brulee-2인분-strasse-17-foobar

이 표기 형식은 어디에서 왔는가

큰 글자와 작은 글자는 한때 서로 다른 두 벌의 글자였습니다. 큰 글자는 로마의 것으로 끌로 돌에 새겼고, 작은 글자는 양피지 위를 빠르게 달린 붓이 빚어낸 카롤링 소문자에서 내려왔습니다. 인쇄공들은 둘을 서로 다른 활자 상자에 두었고 — 윗상자와 아랫상자 — 상자가 사라진 뒤로도 그 이름만은 오래 남았습니다. 프로그래밍의 형식들은 훨씬 젊고, 단 하나의 문제를 풀려고 지어졌습니다. 이름에는 빈칸이 들어갈 수 없다는 문제입니다. snake_case는 초기 C에서, camelCase는 Smalltalk에서, kebab-case는 Lisp에서, 그리고 주소의 슬러그는 빈칸과 덧붙임표가 허용되지 않는 주소에 사람이 읽을 제목을 넣어야 할 필요에서 나왔습니다.

어디에서 마주치는가

낱말마다 큰 글자로 쓰는 방식은 제목과 책 표지의 것입니다. 문장처럼 쓰는 방식은 나머지 거의 전부의 것이고, 읽기가 빨라 화면의 표시에도 점점 퍼지고 있습니다. snake_case는 데이터베이스 열과 파이썬 변수에 이름을 주고, camelCase는 자바스크립트 변수와 자바 메서드에, kebab-case는 CSS 클래스와 웹 프로젝트의 파일 이름에 줍니다. 슬러그는 글의 제목을 주소의 마지막 부분으로 바꾸는 것이며, 여기 있는 변환 가운데 검색 엔진이 읽는 것은 그것뿐입니다.

자주 묻는 질문

큰 글자로 바꾸면 왜 때때로 글자 수가 달라지나요?

글자의 크기 구분은 글자 자체가 아니라 언어의 성질이기 때문입니다. 독일어 ß는 큰 글자로 SS가 되어 한 글자가 둘이 됩니다. 터키어에는 점 있는 i와 점 없는 i가 있고, i의 큰 글자는 I가 아니라 İ입니다. 여기서 틀리면 터키어 낱말이 다른 낱말이 되고 맙니다. 이 쪽의 변환은 각 쪽의 언어 규칙을 따르므로, 같은 입력이라도 터키어 쪽과 영어 쪽에서 결과가 다를 수 있습니다.

슬러그는 왜 덧붙임표와 문장 부호를 없애나요?

주소는 메시지에 복사되고 종이에 인쇄되고 손으로 다시 입력되는 일을 견뎌야 하기 때문입니다. 덧붙임표가 붙은 글자는 요즘 주소에서도 허용되지만 복사할 때 백분율로 부호화되어, 읽히던 주소가 기호의 행렬로 바뀝니다. 그것을 민 글자와 숫자와 붙임표까지 깎아 내면 주소는 읽히고, 나누기 좋고, 어디에 나타나든 똑같은 모습으로 남습니다.

답이 정확한가요?

두 단위가 정수로 서로 정의되어 있으면 정확합니다 — 쪽에서 숫자 위에 그렇게 밝히고 있고, 반올림은 몇 자리를 보여 주느냐에만 있습니다. 비가 유한소수가 아닐 때는 유효숫자 열두 자리를 보여 주고 관계가 근사라고 말합니다. 아닌 척하지 않습니다.

제가 입력한 것이 기기 밖으로 나가나요?

아니요. 계산은 여러분의 브라우저 안에서 이루어집니다. 아무것도 올라가지 않고, 올릴 서버도 없습니다. 한 번 불러오면 네트워크를 꺼도 동작합니다.

텍스트를 snake_case로 변환하는 이유

프로그래머는 변수에 annual report total이라는 이름을 붙일 수 없습니다. 이름에는 공백이 들어갈 수 없기 때문입니다. 데이터베이스 열의 이름을 Customer First Name이라고 할 수도 없습니다. Final Draft (2).docx라는 파일은 조만간 스크립트를 성가시게 할 것입니다. 어딘가에서 사람의 구절은 한 단어로 바뀌어야 하고, 수많은 커뮤니티가 정착한 형태가 snake_case입니다. 글자는 모두 소문자이고 단어는 밑줄로 이어집니다. annual_report_total, customer_first_name, final_draft_2 같은 것들입니다. 텍스트를 snake_case로 변환한다는 것은 어떤 상태의 어떤 구절이든 한 번에 그 형태로 바꾸는 일입니다.

한 줄을 붙여 넣고 snake_case로 읽어 보십시오. 변환은 브라우저 안에서 이루어지고, 입력하는 내용은 어디로도 전송되지 않으며, 규칙은 영어가 아니라 이 페이지의 언어를 따릅니다. 줄을 단어로 자르고, 소문자로 바꾸고, 밑줄로 이어 붙입니다. 이미 camelCase로 쓰인 줄도 대문자에서 잘리므로 fooBar는 foo_bar가 됩니다. 아래에서는 그것이 정확히 무엇을 뜻하는지, 무엇이 버려지는지, 여러 언어의 까다로운 글자를 페이지가 어떻게 다루는지, snake_case가 관례인 곳과 아닌 곳, 그리고 서둘러 텍스트를 snake_case로 변환하는 사람들이 걸려드는 함정을 설명합니다.

변환이 하는 일

자르고, 소문자로, 이어 붙이기

페이지는 먼저 줄을 단어로 자릅니다. 그런 다음 각각을 소문자로 바꾸고 밑줄로 이어 붙입니다. Crème brûlée for 2 — straße 17, fooBar라는 줄은 crème_brûlée_for_2_straße_17_foo_bar로 돌아옵니다. 악센트는 유지되고, 숫자는 독립된 단어로 남으며, 대시와 쉼표는 사라지고, fooBar는 그 안의 대문자가 경계를 표시하기 때문에 둘로 잘렸습니다.

자르는 위치

단어의 경계는 공백, 문장 부호, 대시, 기호, 또는 단어 안에서 소문자에서 대문자로 바뀌는 지점입니다. 그래서 customerFirstName이라는 구절, Customer First Name이라는 구절, customer-first-name이라는 구절은 모두 customer_first_name이 됩니다. 이것이 변환의 실용적인 강점입니다. 거의 모든 출발점을 받아들이고 언제나 같은 곳에 도착합니다.

결과 복사하기

결과 옆의 버튼이 클립보드로 복사해 줍니다. 이름이 필요한 편집기, 스키마, 파일 대화상자에 붙여 넣으십시오.

변환이 하지 않는 일

문장 부호는 유지하지 않습니다

쉼표, 마침표, 대시는 옮겨 갈 문자가 아니라 단어 사이의 경계입니다. 파일 이름이나 데이터베이스 열에는 원하는 바이지만 산문에는 그렇지 않습니다. 문장을 이 페이지에 통과시키면 문장이 아니라 이름으로 돌아오며, 원래의 문장 부호는 사라집니다.

악센트를 제거하지 않습니다

줄은 악센트가 붙은 글자를 그대로 유지합니다. crème_brûlée처럼 말입니다. 많은 시스템이 이를 받아들이지만 그렇지 않은 시스템도 있으며, 악센트가 든 이름은 오래된 도구에서 문제를 일으킬 수 있습니다. 일반 글자가 필요하다면 라틴 글자의 표시를 없애 주는 URL 슬러그 페이지를 쓰십시오.

이름이 여러분의 언어에서 유효한지는 확인하지 않습니다

프로그래밍 언어에는 저마다의 규칙이 있습니다. 숫자로 시작하는 이름을 금지하는 언어도 있고, class나 return 같은 단어를 예약어로 두는 언어도 있습니다. 페이지는 텍스트를 알맞은 모양의 이름으로 바꿀 뿐이며, 그 이름이 쓰는 곳에서 합법적인지는 여전히 여러분이 확인해야 합니다. 2 for 1 offer 같은 구절은 2_for_1_offer가 되는데, 대부분의 언어는 맨 앞에서 이를 거부합니다.

언어가 중요합니다

공백 없이 쓰는 문자

단어로 자르려면 경계가 필요합니다. 중국어와 일본어는 공백 없이 쓰므로, 이런 문자로 된 줄은 하나의 단어로 돌아옵니다. 잘못된 위치에서 자르면 그럴듯해 보이지만 엉뚱한 뜻의 이름이 만들어지므로, 페이지는 짐작해서 자르느니 그렇다고 말하는 편을 택합니다.

튀르키예어와 점이 있는 i

소문자 변환은 페이지 언어의 규칙을 따릅니다. 튀르키예어에서 I의 소문자는 점 없는 ı이고, İ의 소문자는 i입니다. 영어 규칙을 적용하는 변환기는 단어를 바꿔 놓습니다. 이 페이지는 쓰인 언어를 따릅니다.

독일어와 날카로운 s

독일어 ß는 이미 소문자이므로 straße_17처럼 그대로 유지됩니다. 대문자 STRASSE는 strasse로 돌아오는데, 대문자 형태는 그것이 ß에서 왔는지 두 글자에서 왔는지 기억하지 못하기 때문입니다.

오른쪽에서 왼쪽으로 쓰는 문자와 인도 계열 문자

아랍어, 히브리어, 인도 계열 문자는 단어 사이에 공백이 있고 대소문자가 없으므로, 페이지는 그 단어들을 밑줄로 이어 붙이고 글자는 그대로 둡니다. 어떤 도구가 그런 이름을 받아들이는지는 또 다른 문제입니다.

snake_case가 관례인 곳

Python과 Ruby

Python 스타일 가이드는 함수, 변수, 모듈에 snake_case를 권장하며 Ruby도 같은 습관을 따릅니다. 어느 쪽으로든 코드를 쓴다면 이름은 거의 언제나 이 형태입니다.

데이터베이스

SQL의 테이블과 열 이름은 흔히 snake_case입니다. customer_id, created_at, order_total 같은 식입니다. 이름을 따옴표로 감쌀 필요가 없고 데이터베이스 시스템 전반에서 안전하며, 일부 시스템은 따옴표 없는 이름을 한 가지 대소문자로 접어서 camelCase를 알아볼 수 없는 글자 덩어리로 바꿔 버립니다.

데이터 파일과 API

많은 웹 서비스가 JSON에 snake_case 키를 쓰며, 추가 처리를 위해 내보낸 스프레드시트도 snake_case 머리글을 지니는 경우가 많습니다. 데이터가 CSV를 JSON으로 변환을 거치는 중이라면 머리글 행이 키가 되고, 깔끔한 snake_case 머리글은 결과를 쓰기 쉽게 해 줍니다.

상수와 환경 변수

상수와 환경 변수는 관례상 밑줄이 있는 대문자로 씁니다. MAX_RETRIES, DATABASE_URL 같은 식입니다. 이를 얻는 방법은 먼저 텍스트를 snake_case로 변환한 다음 결과를 텍스트를 대문자로 변환으로 올리는 것입니다.

파일 이름

밑줄이 있는 소문자는 모든 시스템에서 안전한 파일 이름이며, 정렬과 검색도 예측대로 됩니다. 많은 사진가, 연구자, 관리자가 바로 그 이유로 이를 씁니다.

관례가 아닌 곳

JavaScript와 Java

이 언어들은 변수와 함수에는 camelCase를, 클래스에는 PascalCase를 선호합니다. Python 스크립트의 이름은 JavaScript 파일에 나타나기 전에 변환이 필요할 수 있습니다. 그 경우에는 camelCase를 보십시오.

CSS와 웹 주소

CSS 클래스 이름과 웹 주소는 보통 밑줄이 아니라 하이픈을 씁니다. 그 도구는 kebab-case입니다. 검색 엔진은 하이픈을 단어 구분자로, 밑줄을 이어 주는 글자로 취급하는데, 작은 차이가 하이픈 주소의 습관 뒤에 있습니다.

산문과 제목

snake_case는 이름을 위한 것이지 읽기 위한 것이 아닙니다. 제목이나 문장을 이 형태로 쓰면 눈이 피곤합니다. 사람이 읽는 텍스트는 단어와 공백을 유지하고, 제목에는 Title Case를 고려하십시오.

여기서 텍스트를 snake_case로 변환하는 방법

텍스트를 붙여 넣거나 입력

첫 번째 칸에 구절을 입력하십시오. 결과가 두 번째 칸에 바로 나타나므로, 입력하는 동안 바뀌는 모습을 지켜볼 수 있습니다.

자른 위치 확인

단어가 어디에서 나뉘었는지 보십시오. iPhone이나 eBay 같은 단어는 대문자에서 잘리고, HTTPServer 같은 약어는 의도한 대로 나왔는지 한 번 훑어볼 필요가 있습니다.

복사

복사 버튼을 누르고 필요한 곳에 결과를 붙여 넣으십시오. 같은 줄의 다른 형태는 아래를 보십시오.

프로젝트 전체에서 snake_case 쓰기

스택 전체에 하나의 관례

이름 짓기 스타일이 뒤섞인 프로젝트는 약간 못생겼더라도 일관된 프로젝트보다 읽기 어렵습니다. 데이터베이스가 snake_case를 쓰면 그것과 대화하는 코드도 흔히 그렇게 하고, 둘 사이를 오가는 파일도 따릅니다. 새 열이나 새 필드를 위해 텍스트를 snake_case로 변환할 때는 다른 모든 계층이 감수해야 할 이름을 고르는 것이므로, 한 번 고르고 끝까지 이어 가십시오.

관례 사이에서 이름 옮기기

조만간 한 관례의 이름이 다른 관례에 나타나야 합니다. 데이터베이스 열 customer_first_name은 JavaScript 객체에서는 customerFirstName이, CSS 클래스나 URL에서는 customer-first-name이 됩니다. 각각을 손으로 다시 입력하는 대신, 원본을 필요한 형태를 만드는 페이지에 붙여 넣으십시오. C와 JavaScript 계열의 코드에는 camelCase를, 스타일과 주소에는 kebab-case를 쓰십시오. 같은 이름의 세 형태는 서로의 정확한 번역이며, 변환기는 이를 일관되게 만들어 줍니다.

설정 파일

설정 파일은 snake_case 키를 쓰는 경우가 많으며, 특히 많은 도구가 쓰는 YAML에서 그렇습니다. JSON으로 보관한 데이터로 그런 파일을 준비할 때 JSON을 YAML로 변환은 키를 쓴 그대로 유지하고, YAML을 JSON으로 변환은 반대로 해 줍니다. 시작하기 전에 키에 snake_case를 쓰기로 정해 두면 형식 사이의 변환이 키를 흩뜨리지 않습니다.

한꺼번에 이름 바꾸기

머리글이 여러 스타일로 뒤섞인 데이터 파일을 물려받았다면 이 페이지로 각 머리글을 변환하고 한 번에 교체하십시오. 먼저 작은 표본으로 시험하십시오. 머리글로 파일을 읽는 스크립트는 이름이 일부에서만 바뀌면 깨지기 때문입니다. 동료가 무엇이 바뀌었는지 볼 수 있도록 옛 이름과 새 이름의 목록을 파일 옆에 보관하십시오.

오래가는 이름 쓰기

저장 방식이 아니라 그것이 무엇인지 말하기

좋은 이름은 내용을 설명합니다. order_total은 그 숫자가 무엇을 뜻하는지 말해 주지만 col7은 그렇지 않습니다. 텍스트를 snake_case로 변환할 때는 출발하는 구절이 쓸 수 있는 가장 명확한 것인지 확인하십시오. 변환기는 그 명확함도 혼란도 충실하게 보존하기 때문입니다.

자기만 아는 약어를 피하기

cust_fn_dt 같은 이름은 다른 누구에게도, 여섯 달 뒤의 여러분에게도 수수께끼입니다. 밑줄은 싸고 단어를 더하는 것도 쌉니다. 문장처럼 읽히는 긴 이름이 범례가 필요한 짧은 이름보다 다음 사람에게 더 좋은 선물입니다.

단수와 복수를 일관되게

테이블 이름을 단수 customer로 할지 복수 customers로 할지 정하고 지키십시오. 관례보다 균일함이 더 중요합니다. snake_case로 바뀐 구절은 여러분이 준 수를 그대로 유지합니다.

도움이 되면 접두사 붙이기

큰 스키마에서는 짧은 접두사가 관련된 이름을 묶어 줍니다. billing_address, billing_city, billing_country 같은 식입니다. 접두사를 붙여 구절을 입력하고 변환하면 일관된 결과가 나오며, 알파벳 순 목록은 저절로 묶입니다.

확정하기 전에 이름을 시험하기

이름이 스키마나 API에 들어가기 전에, 나타날 곳에서 시험해 보십시오. 쿼리, 변수, 파일 목록입니다. 세 곳 모두에서 자연스럽게 읽힌다면 쓸 만합니다. 어색하다면 구절을 줄이거나 고쳐 쓰고 텍스트를 snake_case로 다시 변환하십시오. 처음의 잠깐의 시험이 나중에 수백 개 파일에 걸친 이름 바꾸기를 덜어 줍니다.

같은 줄의 일곱 가지 표기

형태 표

변환기 아래의 표는 예시 줄을 사이트가 제공하는 일곱 가지 형태로 모두 보여 줍니다. 대문자, 소문자, Title Case, snake_case, kebab-case, camelCase, URL 슬러그입니다. 같은 단어가 각 형태에서 어떻게 보이는지 빠르게 확인하는 방법입니다.

이 형태들은 어디서 왔을까

두 가지 알파벳

대문자와 소문자는 한때 서로 다른 두 알파벳이었습니다. 대문자는 로마의 것으로 끌로 돌에 새겼고, 소문자는 카롤링거 소문자에서 내려온 것으로 양피지 위를 빠르게 움직이는 펜이 빚어냈습니다. 인쇄공들은 이 둘을 별개의 상자, 곧 위 칸(upper case)과 아래 칸(lower case)에 보관했고, 상자가 사라진 뒤에도 이름은 오래 남았습니다.

공백 없는 이름

프로그래밍 형태들은 훨씬 젊으며 하나의 문제를 풀기 위해 발명되었습니다. 이름에는 공백이 들어갈 수 없다는 것입니다. snake_case는 초기 C에서, camelCase는 Smalltalk에서, kebab-case는 Lisp에서 나왔고, URL 슬러그는 공백과 악센트가 허용되지 않는 주소에 사람의 제목을 넣어야 할 필요에서 나왔습니다. 밑줄은 당시 키보드에서 편리한 문자였고, 줄 위에 놓인 공백처럼 보입니다.

텍스트를 snake_case로 변환할 때의 함정

숫자로 이름을 시작하는 것

대부분의 언어와 데이터베이스는 숫자로 시작하는 이름을 거부합니다. 구절이 숫자로 시작한다면 앞에 글자나 단어를 붙이십시오.

예약어가 처리되기를 기대하는 것

class나 order 같은 구절은 여러분의 언어나 SQL에서 예약어일 수 있습니다. 페이지는 알지 못하므로 직접 확인해야 합니다.

약어

parseHTMLString처럼 camelCase 이름 속의 약어는 규칙에 따라 parse_h_t_m_l_string이나 parse_html_string으로 잘릴 수 있습니다. 결과가 원하는 것인지 확인하십시오.

매우 긴 이름

데이터베이스와 파일 시스템에는 길이 제한이 있습니다. 긴 구절로 만든 이름이 그 제한에 걸릴 수 있습니다. 변환하기 전에 표현을 줄이십시오.

변환 전에 사람들이 묻는 질문

문장 부호는 어떻게 되나요?

단어 사이의 경계로 취급되며 옮겨지지 않습니다.

숫자는 유지되나요?

네, 독립된 단어로서 밑줄로 구분됩니다.

camelCase 입력도 처리하나요?

네. 단어 안의 대문자가 자르는 지점을 표시하므로 fooBar는 foo_bar가 됩니다.

다른 언어에도 쓸 수 있나요?

네, 페이지 언어의 규칙으로 처리됩니다. 중국어와 일본어처럼 공백 없이 쓰는 문자는 하나의 단어로 돌아옵니다.

제 텍스트가 업로드되나요?

아니요. 여기에 입력한 내용은 어디로도 전송되지 않으므로, 초안, 비밀번호, 고객의 이름도 텍스트 편집기에서만큼 안전합니다.

하이픈으로 바꾸려면 어떻게 하나요?

텍스트를 kebab-case로 변환을 쓰십시오.

실제 사용 예

도서관용 작은 데이터베이스를 만들고 있는데 직원들이 스프레드시트의 열 제목을 보내 주었다고 해 봅시다. Book Title, Author's Last Name, Year Published (YYYY), ISBN-13입니다. 하나씩 변환하면 book_title, author_s_last_name, year_published_yyyy, isbn_13이 읽힙니다. 아포스트로피 때문에 저자 열이 지저분해졌으므로 원문을 Author Last Name으로 줄여 다시 변환하면 author_last_name이 됩니다. 연도 열은 형식 메모가 없는 편이 더 명확하므로 year_published로 둡니다. 깔끔한 열 이름 네 개가 잠깐 만에 쓰였고, 각각 데이터베이스가 받아들일 이름입니다.

간단한 점검표

변환 전

괄호 속 메모 없이 구절을 쉬운 말로 쓰십시오. 대상이 밑줄과 악센트를 받아들이는지 확인하십시오.

변환 중

구절을 붙여 넣고, 자른 위치를 보고, 이름이 글자로 시작하는지 확인하십시오.

변환 후

길이를 확인하고, 예약어와 대조하고, 이름이 그 뜻까지 거슬러 추적될 수 있도록 원래 구절의 기록을 보관하십시오.

흔한 실수

사람이 읽을 텍스트에 snake_case 쓰기

이름을 위한 것이지 산문을 위한 것이 아닙니다.

대상이 허용하는 것을 잊기

맨 앞의 숫자, 악센트, 길이 제한은 시스템마다 다릅니다.

약어를 살펴보지 않고 변환하기

약어 주변에서 자른 위치를 확인하십시오.

텍스트는 기기에 머뭅니다

변환은 로컬에서 이루어집니다. 텍스트는 여러분의 브라우저가 처리하며 아무것도 어디로도 전송되지 않습니다. 나중에 지울 것도, 만들어야 할 계정도 없습니다. 이것이 텍스트를 snake_case로 변환하는 소박한 방법입니다.

요약

여기서 텍스트를 snake_case로 변환하려면 한 줄을 붙여 넣고, 단어로 잘리고, 소문자로 바뀌고, 밑줄로 이어진 결과를 읽으면 됩니다. 이미 camelCase로 쓰인 줄도 그 지점에서 잘리므로 fooBar는 foo_bar가 됩니다. 페이지는 문장 부호를 유지하지 않습니다. 쉼표, 마침표, 대시는 옮겨 갈 문자가 아니라 단어 사이의 경계이며, 파일 이름이나 데이터베이스 열에는 원하는 바이지만 산문에는 그렇지 않습니다. 단어로 자르려면 경계가 필요하므로, 공백 없이 쓰는 중국어와 일본어는 하나의 단어로 돌아옵니다. 소문자 변환은 페이지의 언어를 따릅니다. 아무것도 업로드되지 않습니다.

길이와 넓이 질량과 부피 온도 통화