언어 불가 지론 쿠키 인코딩/디코딩 표준

Question

백엔드 플랫폼에 상관없이 쿠키 값을 인코딩/디코딩하는 데있어 표준이 무엇인지 (또는 어떤 것이 있습니까?) 알아 내기가 어려워요. RFC 2109 따르면

:

값이 사용자 에이전트 불투명 및 발신 서버는 아마도 서버 선택된 인쇄 ASCII 인코딩으로 전송하도록 선택하는 것이 될 수있다. "불투명"은 내용이 원 서버에만 관련되어 있다는 것을 의미합니다. 실제로 내용은 Set-Cookie 헤더를 검사하는 모든 사람이 읽을 수 있습니다.

"서버는 상사"처럼 들리며 인코딩이 적용되는 모든 사항을 결정합니다. 따라서 PHP 백엔드에서 쿠키를 설정하고 파이썬이나 자바 등에서 쿠키를 읽는 일은 거의 어렵습니다. 양쪽 모두 수동으로 인코딩/디코딩 처리를하지 않아도됩니다.

값을 인코딩해야한다고 가정 해 봅시다. 러시아어 /"печенье (*} значения"/은 "쿠키 값"을 의미하며 여기에 영숫자가 아닌 문자가 추가로 포함됩니다.

파이썬 :

거의 모든 WSGI 서버가 동일한을 수행하고/많은 말한다하더라도 octal literals에서 디코딩에 인코딩 파이썬의 SimpleCookie 클래스를 사용 ECMA-262, 엄격 모드에서 octal literals are depreciated 그. WTF?

그래서, 우리의 원시 쿠키 값은 "/\"\320\277\320\265\321\207\320\265\320\275\321\214\320\265 (*} \320\267\320\275\320\260\321\207\320\265\320\275\320\270\321\217\"/"

Node.js를가된다 :

모두에서 테스트하지 않았하지만 난 그냥 자바 스크립트 백엔드 기본 encodeURIComponent 및 decodeURIComponent 기능을 할 것 같은데요 hexadecimal 이스케이프/이스케이프 해제를 사용하고 있습니까?

PHP :

PHP 정확히 동일하지 encodeURIComponent 유사하지만 쿠키 값에 urlencode을 적용합니다.

이렇게 원시 값이됩니다. %2F%22%D0%BF%D0%B5%D1%87%D0%B5%D0%BD%D1%8C%D0%B5+%28%2A%7D+%D0%B7%D0%BD%D0%B0%D1%87%D0%B5%D0%BD%D0%B8%D1%8F%22%2F은 큰 따옴표로 묶지 않습니다.

그러나; 자바 스크립트 value 가변 위 PHP 부호화 값을 가지면, decodeURIComponent(value)는 /"печенье+(*}+значения"/은 .. 대신 자리의 "+"문자 표시 제공

자바, 루비, 펄 및 .NET의 상황이란

? 원하는 언어를 따르는 (또는 가장 가까운) 언어입니다. 사실, W3에 정의 된 표준이 있습니까?

Answer 1

여기에 약간 혼란스러운 점이 있다고 생각합니다. 서버의 인코딩은 클라이언트에게 중요하지 않으며 그렇게해서는 안됩니다. 그것이 RFC 2109가 여기서 말하고자하는 것입니다.

http의 쿠키 개념은 실제와 비슷합니다. 클럽 입회비를 지불하면 손목에 잉크 스탬프가 찍 힙니다. 이를 통해 다시 지불하지 않고도 클럽을 떠나 다시 시작할 수 있습니다. 손목을 경비원에게 보여 주기만하면됩니다.이 실생활의 예에서, 당신은 어떻게 생겼는지 상관하지 않으며, 보통의 빛에서 보이지 않을 수도 있습니다. 중요한 것은 경비원이 그 물건을 인식한다는 것입니다. 그것을 씻어 내면 다시 지불하지 않고 클럽에 다시 들어가는 특권을 잃을 것입니다.

HTTP에서도 똑같은 일이 발생합니다. 서버는 브라우저에 쿠키를 설정합니다. 브라우저가 서버로 돌아 오면 (읽기 : 다음 HTTP 요청) 서버에 쿠키를 표시합니다. 서버는 쿠키를 인식하고 그에 따라 작동합니다. 그러한 쿠키는 "WasHereBefore"마커처럼 간단 할 수 있습니다. 다시 말하지만 브라우저가 무엇인지 이해하는 것은 중요하지 않습니다. 쿠키를 삭제하면 서버는 마치 이전에 본 적이없는 것처럼 행동하게됩니다. 마치 해당 은행의 경비원이 해당 잉크 스탬프를 씻어 낸 경우와 같습니다.

오늘날 많은 쿠키는 단지 하나의 중요한 정보 즉 세션 식별자를 저장합니다. 다른 모든 것은 서버 측에 저장되고 해당 세션 식별자와 연관됩니다. 이 시스템의 장점은 실제 데이터가 서버를 떠나지 않고 신뢰할 수 있다는 것입니다. 클라이언트 측에 저장된 모든 것은 위조 될 수 있고 신뢰되어서는 안됩니다.

편집 : 당신의 코멘트를 읽고 다시 아직을 질문 을 읽은 후, 나는 마침내 상황을 이해 생각, 당신은 당신의 프로그래밍 언어로 떠나는보다는 쿠키의 실제 인코딩에 관심이있는 이유 : 동일한 서버에 두 가지 다른 소프트웨어 환경 (예 : Perl 및 PHP)이있는 경우 다른 언어로 설정된 쿠키를 디코딩 할 수 있습니다. 위의 예제에서 PHP는 Perl 쿠키를 디코딩해야하며 그 반대의 경우도 마찬가지입니다.

데이터가 쿠키에 저장되는 방법에는 표준이 없습니다. 이 표준은 브라우저가 과 정확히 일치하는 쿠키를과 똑같이 보낼 것이라고 말합니다. 사용 된 인코딩 체계는 프로그래밍 언어가 무엇이든지간에 적합합니다.

실사 예제로 돌아 가면, 영어를 사용하는 경비원과 러시아어를 사용하는 경비원이 있습니다. 두 사람은 한 종류의 잉크 스탬프에 동의해야합니다. 아마도 다른 언어를 배우는 사람들 중 적어도 한 명이 참여할 것입니다.

브라우저 동작이 표준화되었으므로 서버에서 사용되는 다른 모든 언어에서 하나의 언어 인코딩 체계를 모방하거나 사용되는 모든 언어로 자신의 표준화 된 인코딩 체계를 만들면됩니다. 이를 달성하기 위해서는보다 높은 수준의 루틴 대신 PHP의 header()과 같은 하위 루틴을 사용해야 할 수도 있습니다 (예 : start_session()).

BTW : 동일한 방식으로 서버 측 세션 데이터를 저장하는 방법을 결정하는 것은 서버 측 프로그래밍 언어입니다. PHP의 $_SESSION 배열을 사용하여 Perl의 CGI::Session에 액세스 할 수 없습니다.

Answer 2

쿠키가 클라이언트에 불투명한지 여부와 관계없이 여전히 HTTP 사양을 준수해야합니다. rfc2616은 모든 HTTP 헤더가 ASCII (ISO-8859-1) 여야 함을 지정합니다. rfc5987은 다른 문자 세트를 지원하도록이를 확장하지만, 얼마나 널리 지원되는지는 알지 못합니다.

Answer 3

나는 UTF8로 인코딩하고 base64 인코딩으로 감싸는 것을 선호합니다. 빠르고, 유비 쿼터스하며, 어느 쪽이든 데이터를 조작하지 않습니다.

래핑 할 때도 UTF8 로의 명시적인 변환이 이루어져야합니다. 다른 언어 & 런타임은 유니 코드를 지원하지만 내부적으로 UTF8로 문자열을 저장할 수는 없습니다 ... 많은 Windows API와 같습니다. 파이썬 2.x는 내 경험에 의하면 명시 적 변환없이 유니 코드 문자열을 거의 얻지 못합니다.

ENCODE : nativeString -> utfEncode() -> base64Encode()

DECODE : base64Decode() -> utfDecode() ->이 nativeString

은 거의 내가 알고있는 모든 언어, 요즘이 지원 . 보편적 인 단일 함수 인 코드를 찾을 수는 있지만 조심스럽게 잘못하고 두 단계 접근 방식을 선택합니다 ... 특히 외국 문자 집합을 사용하십시오.