국가별 우편번호 형식: 2026 정규식 레퍼런스

미국은 다섯 자리 또는 ZIP+4를 사용하기 때문에 개발자들이 우편번호를 정수로 모델링하기 쉽습니다. 하지만 이 모델은 캐나다, 영국, 네덜란드, 아일랜드, 몰타, 아르헨티나에서 문자를 포함하므로 즉시 깨집니다. 독일, 프랑스, 스페인, 이탈리아, 폴란드에서는 앞자리 0이 의미를 가지는데 정수 컬럼이 이를 조용히 없애기 때문에 역시 깨집니다.

두 번째 부류의 버그는 위치에서 비롯됩니다. 대부분의 서구 국가는 도시 뒤에 우편번호를 두지만, 독일, 프랑스, 네덜란드, 일본은 도시 앞에 두며, 일본은 전체 코드를 주소의 맨 앞에 둡니다. 폼이 고정 템플릿을 렌더링하면 모든 필드가 채워져 있어도 현지 독자에게 명백히 잘못된 주소가 생성됩니다.

유럽 대부분은 고정 길이 숫자 코드를 사용합니다. 독일, 프랑스, 스페인, 이탈리아, 그리스, 터키, 사우디아라비아는 다섯 자리, 오스트리아, 벨기에, 스위스, 덴마크, 노르웨이, 헝가리, 남아프리카공화국은 네 자리, 폴란드와 포르투갈은 하이픈을 추가합니다. 스웨덴은 세 자리, 공백, 두 자리를 사용합니다. 체코는 다섯 자리이며 보통 세 번째 자리 뒤에 공백을 둡니다.

아시아와 라틴아메리카는 대부분 숫자형이지만 길이가 다릅니다. 인도, 중국, 러시아, 싱가포르, 나이지리아는 여섯 자리, 일본은 일곱 자리이며 관례적으로 세 번째 뒤에 하이픈을 둡니다. 한국은 다섯 자리, 브라질은 여덟 자리이며 다섯 번째 뒤에 하이픈을 둡니다. 칠레는 일곱 자리, 콜롬비아는 여섯 자리, 페루와 멕시코는 다섯 자리입니다. 길이만으로는 국가를 식별할 수 없으므로 검증기는 무엇이든 검증하기 전에 국가 필드가 필요합니다.

캐나다는 A1A 1A1 패턴을 사용하며 문자에 제한이 있습니다. 첫 문자는 D, F, I, O, Q, U, W, Z가 될 수 없고, 나머지 문자는 D, F, I, O, Q, U가 될 수 없습니다. 두 삼중자 사이의 공백은 관례입니다. 아무 문자나 허용하는 검증기는 Canada Post가 절대 발급하지 않는 코드를 받아들입니다.

영국은 2~4자리의 아우트워드 코드, 단일 공백, 3자리 인워드 코드를 사용합니다(예: SW1A 1AA). 네덜란드는 네 자리, 공백, 두 개의 대문자입니다. 아일랜드는 7자리 Eircode를 3자리 라우팅 키와 4자리 고유 식별자로 나눕니다. 몰타는 세 글자, 공백, 네 자리입니다. 아르헨티나는 8자리 CPA를 사용하며, 문자 하나, 네 자리, 세 글자입니다(예: C1425ABC).

홍콩과 아랍에미리트는 우편번호 체계가 없습니다. 둘 다 이 사이트의 38개국 픽스처 세트에 포함되어 있으며, 생성기는 숫자를 만들어내지 않고 빈 우편번호 값을 반환합니다. 이것이 올바른 동작이며 유용한 테스트 케이스이기도 합니다. 우편번호를 필수로 표시하는 폼은 두 시장 모두에서 깨지기 때문입니다.

아랍에미리트의 관례는 P.O. Box 번호이며, 이는 우편번호가 아니므로 해당 필드에 강제로 넣어서는 안 됩니다. 홍콩 주소는 구역과 거리를 사용하며 우편물은 코드 없이 배달됩니다. 데이터 모델이 null이 아닌 우편번호 값을 요구한다면 가짜 코드가 아니라 국가 수준 플래그 같은 명시적 센티널을 사용하세요. 가짜 코드는 검증을 통과한 뒤 실제 코드를 가정하는 모든 다운스트림 검사에서 실패하기 때문입니다.

구조 검사는 문자열이 국가 패턴과 일치하는지 답합니다. 존재 검사는 코드가 참조 데이터셋에 나타나는지 답합니다. 두 번째만이 코드가 한 번도 할당되지 않았음을 알려줄 수 있습니다. 이 사이트는 38개국 모두에 구조 검사를 수행하고, US ZIP에 대해서는 40,979행과 대조하는 존재 검사를 수행하며, 누구도 하나를 다른 것으로 혼동하지 않도록 다르게 표시합니다.

어느 검사도 배달 가능성을 증명하지 않습니다. 다섯 자리 US ZIP은 존재할 수 있지만 그 아래의 도로명 주소는 존재하지 않을 수 있고, 구조적으로 유효한 독일 코드는 제공된 도시와 다른 도시에 속할 수 있습니다. 그 수준의 보증이 필요하다면 우편번호 참조 데이터셋과 도로 수준 데이터베이스가 필요하며, 이는 형식 검사기와는 다른 제품입니다.

모든 패턴을 앵커링하세요. 앵커가 없는 /\d{5}/는 아홉 자리 문자열 안의 다섯 자리와 일치하여 성공을 보고합니다. ^와 $ 또는 동등한 전체 일치 API를 사용하세요. JavaScript에서 \d는 ASCII 숫자만 일치하지만, Python에서 \d는 기본적으로 유니코드 숫자를 일치하므로 re.ASCII로 컴파일하거나 [0-9]를 쓰지 않으면 패턴이 동아라비아 숫자를 받아들일 수 있습니다.

구분자가 필수인지 명시적으로 결정하세요. 표시할 때는 표준 구분자를 직접 삽입하세요. 입력에서는 공백이나 하이픈 0개 또는 1개를 허용하고 정규화하세요. 문자 클래스 내부의 하이픈은 이스케이프하거나 마지막에 두지 않으면 범위를 정의하므로 주의하세요. 그리고 정규화 버그를 덮으려고 대소문자 무시 플래그를 사용하지 마세요. 쓰기 시 값을 대문자로 바꾸고 표시 형식은 표준형으로 유지하세요.

하나의 표준형을 저장하고 표시형을 파생하세요. 표준형은 보통 표준 구분자를 포함한 대문자이거나, 구분자가 순전히 관례일 때는 숫자만입니다. 정규화는 손실이 있으므로 감사 추적이 필요하면 원본 사용자 입력을 별도 컬럼에 보관하세요. 지원 담당자가 정확히 무엇이 입력되었는지 볼 필요가 있을 수 있습니다.

국가별 정규화는 작지만 실질적입니다. 캐나다는 대문자-숫자-대문자, 공백, 숫자-대문자-숫자를 원합니다. 네덜란드는 숫자 뒤 대문자를 원합니다. 영국은 단일 공백과 대문자를 원합니다. 브라질과 일본은 사용자가 자주 생략하는 하이픈을 사용하므로 하이픈 형식으로 정규화하세요. 독일은 구분자를 전혀 원하지 않으며 앞자리 0을 반드시 유지해야 합니다.

모든 검증기에는 국가별로 최소 하나의 유효 사례와 하나의 무효 사례, 그리고 정규화와 저장을 특별히 테스트하는 사례가 필요합니다. 아래 표는 시작 세트입니다. 여러 무효 사례가 일반적이지 않고 국가별 이유로 무효라는 점에 주목하세요. 대부분의 손으로 작성한 테스트가 너무 일찍 멈추는 지점입니다.

우편번호가 없는 국가, 앞자리 0, 사용자가 실제로 입력하는 구분자 변형에 대한 사례를 추가하세요. 검증기가 클라이언트와 서버에서 공유된다면 동일한 코퍼스를 두 구현 모두에 대해 실행하세요. 관대한 클라이언트와 엄격한 서버 사이의 불일치는 "폼은 받아들였는데 API가 거부했다"는 보고의 가장 흔한 원인입니다.