04-19

utf-8 ? utf-8 bom? 무슨차이? 왜 오류?


현상 : 가끔씩 페이지 맨 위에 빈 공백이 생김, 찾아보면 빈 공백만 있음, 크롬으로 찾아보면  문자열이 표시되있음

The character in question &#65279 is the Unicode Character 'ZERO WIDTH NO-BREAK SPACE' (U+FEFF) attached to your code on a copy/paste or during a faulty Save its so simple to fix that, just open that file by notepad++ and step follow -->  Encoding->Encode in UTF-8 without BOM. then save that. It work for me as well!

http://stackoverflow.com/questions/15801043/php-include-creates-unwanted-gaps-in-html


해결책 : UTF-8 BOM으로 되있는 페이지를 UTF-8로 변경

QA 1 : BOM(Byte Order Mark)이란?

유니코드가, little-endian 인지 big-endian 인지 아니면 UTF-8 인지 쉽게 알 수 있도록, 유니코드 파일이 시작되는 첫부분에 보이지 않게, 2~3바이트의 문자열을 추가 이것을 BOM이라고 함.

QA 2 : little-endian 인지 big-endian은 무엇인지?

MS윈도에서 내부적으로 사용되는 유니코드(UTF-16LE)는 16비트 즉 2바이트로 하나의 글자를 표현합니다. 바이트가 2개니까 이 바이트에 순서가 정해져 있어야 합니다. big-endian 은 있는 순서 그대로 바이트를 자연스럽게 나열하는 것이고, little-endian 은 속도를 빠르게 하기 위해서 거꾸로 나열하는 것입니다.

MS윈도의 유니코드는 리틀 엔디안 little-endian이 기본값입니다. 빅 엔디안 유니코드는, 울트라에디터 v11 등의 일부 프로그램에서 전혀 인식하지 못했습니다.


반면 UTF-8 에는 리틀 엔디안이나 빅 엔디안의 구분이 없습니다.


결론 : UTF-8 BOM으로 되있는 페이지를 UTF-8로 변경

2017-04-03

char vs varchar 차이

char는 고정길이 데이터
varchar는 가변길이(고정길이 포함)일 경우 사용

varchar2 블럭분할 발생
char 데이터가 없어도 빈(null) 데이터를 저장시 미리 공간 할당 하기때문에
비어있는 데이터를 update 하더라도 미리 할당된 공간 내에서 저장

2개의 블럭 I/O보다
1개의 블럭 I/O를 읽어오는것이 성능에 더 이득

https://okky.kr/article/217655 참고

===================================

varchar(10)이면 한글은 대체 몇자?

mysql , MariaDB

varchar(10) : 한글10자, 영문,숫자 10자

MS-SQL
varchar(10) : 한글 5자, 영문,숫자 10자
nvarchar(10) : 한글 10자, 영문, 숫자 10자

Oracle
varchar2(10) : 한글 3자, 영문,숫자 10자
nvarchar2(10) : 한글 10자, 영문,숫자 10자

라라벨(laravel) 동작정리

1. 모든 시작점
public/index.php

2. apache/nginx 요청

3. include  bootstrap/app.php 실행(서비스 컨테이너 인스턴스를 생성);

4. 서비스 컨테이너 인스턴스를 생성

5. 각 요청에 따라 http커널 or console커널로 보냄

5.1. HTTP 커널은 Illuminate\Foundation\Http\Kernel 클래스를 상속하고 있으며, 요청을 실행하기 전에 처리되는 bootstrappers (시작 코드)의 배열을 정의하고 있습니다. 이 시작 코드들은 에러 처리, 로그 설정, 어플리케이션 동작 환경의 감지 등 실제로 요청이 처리되기 전에 수행해야 되는 작업들을 의미합니다.

5.1.1 커널 부팅(부트스트래핑) 과정의 가장 중요한 것 중의 하나는 어플리케이션의 서비스 프로바이더를 로딩하는 것입니다. 어플리케이션의 모든 서비스 프로바이더는 config/app.php 파일의 providers 배열에 설정되어 있습니다. 먼저, 모든 서비스 프로바이더의 register 메소드가 호출되고, 이후에 등록 된 모든 서비스 프로바이더의 boot 메소드가 호출되어 집니다.

서비스 프로바이더는 프레임워크의 데이터베이스, 큐, validation, 라우팅 컴포넌트와 같은 다양한 컴포넌트의 부트스트래핑(부팅과 같은 기초 작업들)의 처리를 책임집니다. 프레임워크가 제공하는 모든 기능을 초기화 하고 설정하는 것으로, 서비스 프로바이더는 라라벨의 부팅(부트스트래핑) 과정에서 가장 중요한 기능이라고 할 수 있습니다.

php에서 메일제목 한글이 깨질때

php에서 한글인코딩을 보낼 경우 한글이깨지는 경우가 발생한다.

상황

- 홈페이지(php, linux, mysql)에서 메일(linux)을 보내는데 한글이 깨짐 

현상확인

#그림1

  (그림1 다음메일)


그렇다고 모두 그런것은 아니다.

#그림2

(그림2. 네이버 메일)


많이 쓰는 메일들에 대해서 테스트 해보았는데
(gmail, naver, daum or hanmail, nate 그리고 회사메일)
daum과 회사메일이 그림1과 같은 현상이 발생되었다.

그럼 원인에 대해서 생각해보자

1. 메일서버
2. 웹서버
3. DB
4. backend 언어
5. etc...


그럼 하나씩 짚고 넘어가보자

1. 메일서버 (x)
3. DB (x)
  - 기존 언어(asp, mysql) 홈페이지에서 메일(linux)을 보냈을때 정상적으로 발송됨

2. 웹서버의 문제
  - 리눅스서버 설정은 확인하고 조작해보기 힘드므로 마지막순위로 밀겠다

4. backend 언어(php)
- 남은건 이거 하나

해결

1. php한글깨짐을 검색해보면 관련 블로그가 많다

내용을 살펴보면 메일을 보낼때 헤더값으로 관련 정보를 넘겨준다.
넘겨줄때

$subject = "메일제목";

이럴경우

$subject = '=?UTF-8?B?'.base64_encode( "메일제목" ).'?=';

으로 utf-8로 메일을 보낸다는것을 명시해주면 된다.

기본적으로 메일을 보낼때 ASCII 문자열로 넘어가기때문에 인코딩에 대한 명시를 해줘야된다 한다.

이러한 형태로 인코딩을 적용되어 될 부분은 한글이 들어가야되는 부분(보내는이 이름, 받는이 이름) 들도 포함이다. 
그리고 내용은 하지말아야 한다.(해보니까 더 깨진다.. 그냥 보내야 정상임)
이부분에 대해선 더 확인해봐야될듯 하다.

HTTP Referer ?? HTTP Referrer ??

원래 Referrer 라고 써야하지만, 필립 할람-베이커Phillip Hallam-Baker가 HTTP스펙에 필드를 추가로 제안할때 오타로 Referer로 기재함.
오타가 그대로 표준에 반영되어 RFC-1945 문서에 포함됐고, 현재까지 Referer로 사용하고 있다.

제로데이 공격(Zero-Day Attack)

제로 데이 공격(또는 제로 데이 위협, Zero-Day Attack)은 컴퓨터 소프트웨어의 취약점을 공격하는 기술적 위협으로, 해당 취약점에 대한 패치가 나오지 않은 시점에서 이루어지는 공격을 말한다. 이러한 시점에서 만들어진 취약점 공격(익스플로잇)을 제로 데이 취약점 공격이라고도 한다.

드라이브 바이(drive by), 파밍(pharming) 공격

드라이브 바이(drive by)
~쪽으로 자동차를 운전하다 라는 의미
온라인 광고업체에서 사용자가 아무런 의심없이 동의버튼을 누르는 버릇을 악용해 광고 콘텐츠 설치 유도(드라이브 바이 인스톨 - drive by install) 또는 한번 클릭하는 선택적 설치(one click opt install)
사용자의 동의 없이 자동으로 악성코드 다운로드 및 실행하는 현상


파밍(pharming)
악성코드 또는 다른 공격으로 인해 DNS가 변경되어 피싱사이트로 유도하는 공격
c:\window\system\drivers\etc 에 존재하는 host 파일 조작 혹은 레지스트리를 변조시켜 로컬프락시 설정, 악성코드 자체가 로컬 DNS가 되는 방식도 있다.