190822 베네치아 게임 피드백

새로 알게된 사항들을 정리해 봅니다.

window.addEventListener(‘load’, function(){
fetch(‘wordnote.txt’)
.then(response => response.text())
.then(text=>text = text.replace(/[0–9]/g, ‘’))
.then(text => wordList = text.split(‘\n’))
.then(function(){
uniqueArray = wordList.map(function(value,index){
return value.trim();
})
})
.then(function(){
finalArray = uniqueArray.filter(function(value, index) {
return uniqueArray.indexOf(value) === index;})
})
});

이러한 코드를 통해 라인단위로 텍스트파일을 나눠 배열로 구성했다.

fetch(‘uri’)를 통해 해당 파일을 읽었고,

불러온 response에 대해 .text() 메소드를 통해

string타입 변수를 resolve하는 promise객체를 return했다.

https://developer.mozilla.org/en-US/docs/Web/API/Body/text

해당 프로미스를 정규표현식을 통해 숫자를 제거했고, 라인변화를 기준으로 split하여 배열을 생성하였다.

그러나 기대와 달리 눈에는 보이지 않던 공백이 존재했다.

다른 코드라인에서 생성된 배열을 통해 .blocks <div>의 id를 지정, 생성하였으나, $(‘#id’)로 호출이 되지 않아, 테스트를 해보니 배열에 저장된 글자는 눈에 보이지 않는 뭔가의 차이로 의도한 바대로 공백없는 단어로 id가 지정되지 않았다.

찾아보니 그 이유는 fetch하는 대상인 txt파일의 특성에 있었다.

윈도우에서 줄바꿈을 처리하는 방식은
CRLF 로 처리가 된다.

CR+LF 를 의미하는데 각각

CR : Carriage Return (\r)

LF : Line Feed (\n)

를 의미한다.

예전 타자기를 생각하면 한 라인을 다 치고
헤드를 왼쪽 으로 옮기고 한 줄 내리는 방식에서 차용한 듯 하다.

unix/rinux의 경우 \r만으로 개행을 하지만, 윈도우의 경우 CRLF를 통해 개행을 한다.

따라서 내가 \n을 통해 split을 한 경우, \r은 그대로 단어에 남아 trim()작업을 필요로 했다.

혹은 정규표현식을 이용해 numeric character를 제거할 때, range part에

[0–9] 를 [0–9,\n,\r]을 통해서

window.addEventListener(‘load’, function(){
fetch(‘wordnote.txt’)
.then(response => response.text())
.then(text=>text = text.replace(/[0–9,\r]/g, ‘’))
.then(text => wordList = text.split(‘\n’))
})

이렇게 줄일 수 있었다.

요약 — 윈도우에서 txt파일의 경우 개행을 \n이 아니라 \r\n으로 하기 때문에 \n으로 split 하게 되면 \r특수문자가 남게 된다.