stanford-oval/wikipedia huggingface dataset:
Base64
Bảng Base64

Bảng mục lục các ký tự của Base64:
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| STT | Nhị phân | Đầu ra |  | STT | Nhị phân | Đầu ra |  | STT | Nhị phân | Đầu ra |  | STT | Nhị phân | Đầu ra |
| 0 | 000000 | A |  | 16 | 010000 | Q |  | 32 | 100000 | g |  | 48 | 110000 | w |
| 1 | 000001 | B |  | 17 | 010001 | R |  | 33 | 100001 | h |  | 49 | 110001 | x |
| 2 | 000010 | C |  | 18 | 010010 | S |  | 34 | 100010 | i |  | 50 | 110010 | y |
| 3 | 000011 | D |  | 19 | 010011 | T |  | 35 | 100011 | j |  | 51 | 110011 | z |
| 4 | 000100 | E |  | 20 | 010100 | U |  | 36 | 100100 | k |  | 52 | 110100 | 0 |
| 5 | 000101 | F |  | 21 | 010101 | V |  | 37 | 100101 | l |  | 53 | 110101 | 1 |
| 6 | 000110 | G |  | 22 | 010110 | W |  | 38 | 100110 | m |  | 54 | 110110 | 2 |
| 7 | 000111 | H |  | 23 | 010111 | X |  | 39 | 100111 | n |  | 55 | 110111 | 3 |
| 8 | 001000 | I |  | 24 | 011000 | Y |  | 40 | 101000 | o |  | 56 | 111000 | 4 |
| 9 | 001001 | J |  | 25 | 011001 | Z |  | 41 | 101001 | p |  | 57 | 111001 | 5 |
| 10 | 001010 | K |  | 26 | 011010 | a |  | 42 | 101010 | q |  | 58 | 111010 | 6 |
| 11 | 001011 | L |  | 27 | 011011 | b |  | 43 | 101011 | r |  | 59 | 111011 | 7 |
| 12 | 001100 | M |  | 28 | 011100 | c |  | 44 | 101100 | s |  | 60 | 111100 | 8 |
| 13 | 001101 | N |  | 29 | 011101 | d |  | 45 | 101101 | t |  | 61 | 111101 | 9 |
| 14 | 001110 | O |  | 30 | 011110 | e |  | 46 | 101110 | u |  | 62 | 111110 | + |
| 15 | 001111 | P |  | 31 | 011111 | f |  | 47 | 101111 | v |  | 63 | 111111 | / |
| Đệm | Đệm | = |  |  |  |  |  |  |  |  |  |  |  |  |
Ví dụ > Đệm đầu ra

Bởi vì Base64 là mã hóa sáu bit và vì các giá trị được giải mã được chia thành các bộ tám 8 bit trên máy tính hiện đại, nên cứ bốn ký tự của văn bản được mã hóa Base64 (4 sextet = 4 × 6 = 24 bit) đại diện cho ba bộ tám chưa được mã hóa văn bản hoặc dữ liệu (3 octet = 3 × 8 = 24 bit). Điều này có nghĩa là khi độ dài của đầu vào không được mã hóa không phải là bội số của ba, thì đầu ra được mã hóa phải được thêm phần đệm để chiều dài của nó là bội số của bốn. Ký tự đệm là =, cho biết rằng không cần thêm bit nào để mã hóa đầy đủ đầu vào. (Điều này khác với A, có nghĩa là các bit còn lại đều là số không.) Ví dụ dưới đây minh họa cách cắt bớt đầu vào của câu trích dẫn trên thay đổi phần đệm đầu ra:
| Đầu vào> Văn bản | Đầu vào> Độ dài | Đầu ra> Văn bản | Đầu ra> Độ dài | Đệm |
| --- | --- | --- | --- | --- |
| light work. | 11 | bGlnaHQgd29yay4= | 16 | 1 |
| light work | 10 | bGlnaHQgd29yaw== | 16 | 2 |
| light wor | 9 | bGlnaHQgd29y | 12 | 0 |
| light wo | 8 | bGlnaHQgd28= | 12 | 1 |
| light w | 7 | bGlnaHQgdw== | 12 | 2 |
Ký tự đệm không cần thiết để giải mã, vì số byte bị thiếu có thể được suy ra từ độ dài của văn bản được mã hóa. Trong một số triển khai, ký tự đệm là bắt buộc, trong khi đối với những cách khác, ký tự này không được sử dụng. Một ngoại lệ trong đó các ký tự đệm là bắt buộc khi nhiều tệp được mã hóa Base64 đã được nối với nhau.
Ví dụ > Giải mã Base64 với ký tự đệm

Khi giải mã văn bản Base64, bốn ký tự thường được chuyển đổi trở lại thành ba byte. Các ngoại lệ duy nhất là khi các ký tự đệm tồn tại. Một = chỉ ra rằng bốn ký tự sẽ chỉ giải mã thành hai byte, trong khi == chỉ ra rằng bốn ký tự sẽ chỉ giải mã thành một byte duy nhất. Ví dụ:
| Được mã hóa | Đệm | Độ dài | Được giải mã |
| --- | --- | --- | --- |
| bGlnaHQgdw== | == | 1 | light w |
| bGlnaHQgd28= | = | 2 | light wo |
| bGlnaHQgd29y | None | 3 | light wor |
Ví dụ > Giải mã Base64 không có ký tự đệm

Nếu không có phần đệm, sau khi giải mã bình thường từ bốn ký tự đến ba byte lặp đi lặp lại, có thể còn lại ít hơn bốn ký tự được mã hóa. Trong tình huống này, chỉ có thể còn lại hai hoặc ba ký tự. Một ký tự được mã hóa còn lại là không thể thực hiện được vì một ký tự Base64 chỉ chứa 6 bit và 8 bit được yêu cầu để tạo một byte, vì vậy cần có tối thiểu hai ký tự Base64: Ký tự đầu tiên đóng góp 6 bit và ký tự thứ hai đóng góp 2 bit đầu tiên của nó. Ví dụ:
| Độ dài | Được mã hóa | Độ dài | Được giải mã |
| --- | --- | --- | --- |
| 2 | bGlnaHQgdw | 1 | light w |
| 3 | bGlnaHQgd28 | 2 | light wo |
| 4 | bGlnaHQgd29y | 3 | light wor |
Phát triển và lịch sử > Bảng tóm tắt các biến thể

Việc triển khai có thể có một số ràng buộc đối với bảng chữ cái được sử dụng để biểu diễn một số mẫu bit. Điều này đáng chú ý liên quan đến hai ký tự cuối cùng được sử dụng trong bảng chỉ mục cho chỉ mục 62 và 63 và ký tự được sử dụng để đệm (có thể là bắt buộc trong một số giao thức hoặc bị loại bỏ trong các giao thức khác). Bảng dưới đây tóm tắt các biến thể đã biết này và cung cấp liên kết đến các phần phụ bên dưới.
| Mã hóa | Các ký tự mã hóa> 62nd | Các ký tự mã hóa> 63rd | Các ký tự mã hóa> đệm | Các dòng mã hóa riêng biệt> Dấu phân cách | Các dòng mã hóa riêng biệt> Độ dài | Các dòng mã hóa riêng biệt> Checksum | Giải mã các ký tự không mã hóa |
| --- | --- | --- | --- | --- | --- | --- | --- |
| RFC 1421: Base64 cho Privacy-Enhanced Mail (không còn dùng nữa) | + | / | = bắt buộc | CR+LF | 64, hoặc ít hơn cho dòng cuối cùng | Không | Không |
| RFC 2045: Base64 chuyển mã hóa cho MIME | + | / | = bắt buộc | CR+LF | nhiều nhất là 76 | Không | Bị loại bỏ |
| RFC 2152: Base64 cho UTF-7 | + | / | Không | Không | Không | Không | Không |
| RFC 3501: Base64 mã hóa cho tên hộp thư IMAP | + | , | Không | Không | Không | Không | Không |
| RFC 4648 §4: base64 (bản tiêu chuẩn) | + | / | = không bắt buộc | Không | Không | Không | Không |
| RFC 4648 §5: base64url (URL - và tiêu  chuẩn an toàn cho tên tệp) | - | _ | = không bắt buộc | Không | Không | Không | Không |
| RFC 4880: Radix-64 cho OpenPGP | + | / | = bắt buộc | CR+LF | nhiều nhất là 76 | {{Optionalss số 64 được mã hóa 24-bit CRC}} | Không |
Phát triển và lịch sử > Thư nâng cao quyền riêng tư

Việc sử dụng mã hóa chuẩn hóa đầu tiên được biết đến hiện nay được gọi là MIME Base64 nằm trong giao thức Thư điện tử nâng cao quyền riêng tư (PEM), được đề xuất bởi RFC 989 vào năm 1987. PEM định nghĩa một lược đồ "mã hóa có thể in" sử dụng mã hóa Base64 để biến đổi một chuỗi octet tùy ý sang một định dạng có thể được thể hiện bằng các dòng ngắn gồm các ký tự 6 bit, theo yêu cầu của các giao thức truyền như SMTP.
Phiên bản hiện tại của PEM (được chỉ định trong RFC 1421) sử dụng bảng chữ cái 64 ký tự bao gồm các chữ cái La Mã viết hoa và viết thường (A–Z, a–z), các chữ số (0–9), và các ký tự + và / . Ký tự = cũng được sử dụng như một hậu tố đệm. Đặc điểm kĩ thuật gốc, RFC 989, cũng đã sử dụng ký tự * để phân tách dữ liệu được mã hóa nhưng chưa được mã hóa trong luồng đầu ra.
Để chuyển đổi dữ liệu sang mã hóa có thể in PEM, byte đầu tiên được đặt trong 8 bit quan trọng nhất của bộ đệm 24 bit, byte tiếp theo trong 8 bit ở giữa và byte thứ ba trong tám bit ít quan trọng nhất. Nếu còn lại ít hơn 3 byte để mã hóa (hoặc tổng số), các bit đệm còn lại sẽ bằng không. Sau đó, bộ đệm được sử dụng, 6 bit tại một thời điểm, quan trọng nhất trước tiên, làm chỉ số cho chuỗi: "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/", và ký tự được chỉ định là đầu ra.
Quá trình được lặp lại trên dữ liệu còn lại cho đến khi còn lại ít hơn 4 octet. Nếu 3 octet vẫn còn, chúng được xử lý bình thường. Nếu còn lại ít hơn 3 octet (24 bit) để mã hóa, dữ liệu đầu vào sẽ được đệm bên phải với các bit 0 để tạo thành bội số tích phân của 6 bit.
Sau khi mã hóa dữ liệu không đệm, nếu 2 octet của bộ đệm 24 bit là số không có đệm, hai ký tự =  được thêm vào đầu ra; nếu 1 octet của bộ đệm 24 bit được lấp đầy bởi các số không có đệm, một ký tự = được thêm vào. Điều này báo hiệu cho bộ giải mã rằng các bit 0 được thêm vào do đệm phải được loại trừ khỏi dữ liệu được tái tạo. Điều này cũng đảm bảo rằng độ dài đầu ra được mã hóa là bội số của 4 byte.
PEM yêu cầu tất cả các dòng được mã hóa bao gồm chính xác 64 ký tự có thể in được, ngoại trừ dòng cuối cùng, có thể chứa ít ký tự có thể in hơn. Các dòng được phân cách bằng các ký tự khoảng trắng theo quy ước cục bộ (dành riêng cho nền tảng).
Phát triển và lịch sử > MIME

Bài chi tiết: MIME
Đặc điểm kỹ thuật MIME (Tiện ích mở rộng thư Internet đa năng) liệt kê Base64 là một trong hai lược đồ mã hóa nhị phân thành văn bản (lược đồ kia được trích dẫn-in được). Mã hóa Base64 của MIME dựa trên mã hóa phiên bản RFC 1421 của PEM: nó sử dụng cùng một bảng chữ cái 64 ký tự và cơ chế mã hóa như PEM và sử dụng ký tự =cho phần đệm đầu ra theo cách tương tự, như được mô tả tại RFC 2045.
MIME không chỉ định độ dài cố định cho các dòng được mã hóa Base64, nhưng nó chỉ định độ dài dòng tối đa là 76 ký tự. Ngoài ra, nó chỉ định rằng bất kỳ ký tự ngoài bảng chữ cái nào phải được bộ giải mã tuân thủ bỏ qua, mặc dù hầu hết các triển khai đều sử dụng cặp dòng mới CR/LF để phân tách các dòng được mã hóa.
Do đó, độ dài thực tế của dữ liệu nhị phân được mã hóa Base64 tuân thủ MIME thường bằng khoảng 137% độ dài dữ liệu gốc, mặc dù đối với các tin nhắn rất ngắn, chi phí có thể cao hơn nhiều do chi phí của các tiêu đề. Rất đại khái, kích thước cuối cùng của dữ liệu nhị phân được mã hóa Base64 bằng 1,37 lần kích thước dữ liệu gốc + 814 byte (đối với tiêu đề). Kích thước của dữ liệu được giải mã có thể được tính gần đúng với công thức sau:
bytes = (string_length(encoded_string) - 814) / 1.37
Phát triển và lịch sử > UTF-7

UTF-7, được mô tả đầu tiên trong RFC 1642, mà sau đó đã được thay thế bởi RFC 2152, đã giới thiệu một hệ thống được gọi là Base64 đã được sửa đổi. Lược đồ mã hóa dữ liệu này được sử dụng để mã hóa UTF-16 dưới dạng ký tự ASCII để sử dụng trong truyền tải 7 bit như SMTP. Nó là một biến thể của mã hóa Base64 được sử dụng trong MIME.
Bảng chữ cái "Modified Base64" bao gồm bảng chữ cái MIME Base64 nhưng không sử dụng ký tự đệm "=". UTF-7 được thiết kế để sử dụng trong tiêu đề thư (được định nghĩa trong RFC 2047),và ký tự "=" là được dành riêng trong ngữ cảnh đó làm ký tự thoát cho mã hóa "có thể in được trích dẫn". Base64 được sửa đổi chỉ cần bỏ qua phần đệm và kết thúc ngay sau chữ số Base64 cuối cùng chứa các bit hữu ích để lại tối đa ba bit không sử dụng trong chữ số Base64 cuối cùng.
Phát triển và lịch sử > OpenPGP

OpenPGP, được dựa trên RFC 4880, mô tả mã hóa Radix-64, còn được gọi là "ASCII armor". Radix-64 giống với kiểu mã hóa "Base64" được mô tả từ MIME, với việc bổ sung CRC 24 bit tùy chọn. Tổng kiểm tra được tính toán trên dữ liệu đầu vào trước khi mã hóa; sau đó tổng kiểm tra được mã hóa bằng cùng một thuật toán Base64 và tiền tố là ký tự "=" như một dấu phân cách, được nối vào dữ liệu đầu ra được mã hóa.
Phát triển và lịch sử > RFC 3548

RFC 3548, có thể Mã hóa dữ liệu Base16, Base32 và Base64 là một bản ghi nhớ thông tin (không quy chuẩn) cố gắng thống nhất RFC 1421 và RFC 2045 thông số kỹ thuật của mã hóa Base64, mã hóa bảng chữ cái thay thế và mã hóa Base32 (hiếm khi được sử dụng) và Base16.
Trừ khi các triển khai được viết cho một thông số kỹ thuật đề cập đến RFC 3548 và đặc biệt yêu cầu khác, RFC 3548 cấm việc triển khai tạo thông báo có chứa các ký tự bên ngoài bảng chữ cái mã hóa hoặc không có phần đệm và nó cũng tuyên bố rằng việc triển khai bộ giải mã phải từ chối dữ liệu có chứa các ký tự bên ngoài bảng chữ cái mã hóa.
Phát triển và lịch sử > RFC  4648

RFC này bị lỗi thời RFC 3548 và tập trung vào Base64/32/16:
Phát triển và lịch sử > Các ứng dụng URL

Mã hóa Base64 có thể hữu ích khi thông tin nhận dạng khá dài được sử dụng trong môi trường HTTP. Ví dụ: một khung bền vững cơ sở dữ liệu cho các đối tượng Java có thể sử dụng mã hóa Base64 để mã hóa một id duy nhất tương đối lớn (thường là UUID 128 bit) thành một chuỗi để sử dụng làm tham số HTTP trong các biểu mẫu HTTP hoặc URL HTTP GET. Ngoài ra, nhiều ứng dụng cần mã hóa dữ liệu nhị phân theo cách thuận tiện để đưa vào URL, bao gồm cả trong các trường biểu mẫu web ẩn và Base64 là cách mã hóa thuận tiện để hiển thị chúng một cách nhỏ gọn.
Sử dụng Base64 tiêu chuẩn trong URL yêu cầu mã hóa các ký tự +, / và = thành chuỗi thập lục phân được mã hóa theo phần trăm đặc biệt (+ trở thành %2B, /trở thành %2F và = trở thành %3D), điều này làm cho chuỗi dài hơn một cách không cần thiết.
Vì lý do này, Base64 đã sửa đổi cho các biến thể URL (chẳng hạn như base64url trong RFC 4648), trong đó các ký tự + và / của Base64 tiêu chuẩn được thay thế tương ứng bởi - và _, để việc sử dụng bộ mã hóa/giải mã URL không còn cần thiết và không ảnh hưởng đến độ dài của giá trị được mã hóa, giữ nguyên dạng được mã hóa tương tự để sử dụng trong cơ sở dữ liệu quan hệ, biểu mẫu web và mã định danh đối tượng nói chung. Một số biến thể cho phép hoặc yêu cầu bỏ qua phần đệm = để tránh chúng bị nhầm lẫn với dấu phân cách trường hoặc yêu cầu bất kỳ phần đệm nào như vậy phải được mã hóa theo phần trăm. Một số thư viện [cái gì?] sã mã hóa = thành ., có khả năng khiến các ứng dụng bị tấn công theo đường dẫn tương đối khi tên thư mục được mã hóa từ dữ liệu người dùng.
Phát triển và lịch sử > HTML

Các phương thức JavaScript atob() và btoa() được xác định trong bản thảo HTML5, cung cấp chức năng mã hóa và giải mã Base64 cho các trang web. Phương thức btoa() xuất ra các ký tự đệm, nhưng các ký tự này là tùy chọn trong đầu vào của phương thức atob().
Phát triển và lịch sử > Các ứng dụng khác

Base64 có thể được sử dụng trong nhiều ngữ cảnh khác nhau:
Base64 có thể được sử dụng để truyền và lưu trữ văn bản có thể gây ra xung đột dấu phân cách.
Những kẻ gửi thư rác sử dụng Base64 để trốn tránh các công cụ chống gửi thư rác cơ bản, những công cụ này thường không giải mã được Base64 và do đó không thể phát hiện ra các từ khóa trong các thư được mã hóa.
Base64 được sử dụng để mã hóa chuỗi ký tự trong tệp LDIF.
Base64 thường được sử dụng để "nhúng" dữ liệu nhị phân vào tệp XML, sử dụng cú pháp tương tự như <data encoding="base64">…</data> ví dụ. biểu tượng yêu thích trong Firefox xuất ra bookmarks.html.
Base64 được sử dụng để mã hóa các tệp nhị phân chẳng hạn như hình ảnh trong các tập lệnh, để tránh phụ thuộc vào các tệp bên ngoài.
Lược đồ URI dữ liệu có thể sử dụng Base64 để biểu diễn nội dung tệp. Ví dụ: hình nền và phông chữ có thể được chỉ định trong tệp biểu định kiểu CSS dưới dạng URIs data:, thay vì được cung cấp trong các tệp riêng biệt.
Việc triển khai FreeSWAN IPSec đứng trước chuỗi Base64 bằng 0s, vì vậy chúng có thể được phân biệt với chuỗi văn bản hoặc chuỗi thập lục phân. [cần dẫn nguồn]
Mặc dù không phải là một phần của thông số kỹ thuật chính thức cho SVG, một số người xem có thể hiểu Base64 khi được sử dụng cho các phần tử "nhúng", chẳng hạn như hình ảnh bên trong SVG.
Phát triển và lịch sử > Các ứng dụng Radix-64 không tương thích với Base64

Uuencoding, tthường được sử dụng trên UNIX, sử dụng ASCII 32 liên tiếp (  (khoảng trống)) đến 95 (_), tạo thành bộ 64 ký tự  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_. Việc tránh sử dụng tất cả các chữ cái viết thường rất hữu ích vì nhiều máy in cũ chỉ in chữ hoa. Sử dụng các ký tự ASCII liên tiếp giúp tiết kiệm sức mạnh tính toán vì chỉ cần thêm 32 ký tự, không phải tra cứu. Việc sử dụng hầu hết các ký tự dấu câu và ký tự khoảng trắng làm hạn chế tính hữu dụng của nó.[cần dẫn nguồn]
BinHex 4 (HQX), vốn được sử dụng trong Mac OS cổ điển, sử dụng một bộ 64 ký tự khác. Nó sử dụng các chữ cái viết hoa và viết thường, các chữ số và các ký tự chấm câu, nhưng không sử dụng một số ký tự dễ gây nhầm lẫn trực quan như 7, O, g và o'. Bộ 64 ký tự của nó là !"#$%&'()*+,-012345689@ABCDEFGHIJKLMNPQRSTUVXYZ[`abcdefhijklmpqr.
Một số ứng dụng khác sử dụng các bộ cơ số 64 tương tự hơn nhưng theo thứ tự khác với định dạng Base64, bắt đầu bằng hai ký hiệu, sau đó là chữ số, sau đó viết hoa, rồi viết thường:
Unix lưu trữ các băm mật khẩu được tính bằng crypt trong tệp /etc/passwd sử dụng mã hóa cơ số 64 được gọi là B64. Nó sử dụng một bộ ký tự chủ yếu là chữ và số, có thêm . và /. Bộ 64 ký tự của nó là ./0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz. Ký tự đệm không được sử dụng.
GEDCOM 5.5 tiêu chuẩn được dùng để trao đổi dữ liệu phả hệ mã hóa các tệp đa phương tiện ở định dạng tệp phân cấp dòng văn bản bằng cách sử dụng cơ số 64. Bộ 64 ký tự của nó cũng là "./0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz".
bcrypt được thiết kế để sử dụng theo cách tương tự như crypt (3) truyền thống và thuật toán sử dụng một bảng chữ cái tương tự nhưng được hoán vị. Bộ 64 ký tự của nó là ./ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789.
Xxencoding sử dụng bộ ký tự chủ yếu là chữ và số tương tự như crypt và GEDCOM, nhưng sử dụng + và - còn hơn là sử dụng . và /. Bộ 64 ký tự của nó là +-0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz.
6PACK, được sử dụng với một số bộ điều khiển nút đầu cuối, sử dụng một bộ 64 ký tự khác nhau từ 0x00 đến 0x3f.
Bash hỗ trợ các ký tự số trong cơ số 2-64, kéo dài đến một bộ ký tự của 0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ@_.
Example of an SVG containing embedded JPEG images encoded in Base64
Vettaikaranpudur

| Vettaikaranpudur |
| --- | --- |
Vettaikaranpudur
Quốc gia:  Ấn Độ
Bang: Tamil Nadu
Dân số (2001)
 • Tổng cộng: 17,594
Múi giờ: UTC+05:30
Vettaikaranpudur là một thị xã panchayat của quận Coimbatore thuộc bang Tamil Nadu, Ấn Độ.
Nhân khẩu

Theo điều tra dân số năm 2001 của Ấn Độ, Vettaikaranpudur có dân số 17.594 người. Phái nam chiếm 50% tổng số dân và phái nữ chiếm 50%. Vettaikaranpudur có tỷ lệ 53% biết đọc biết viết, thấp hơn tỷ lệ trung bình toàn quốc là 59,5%: tỷ lệ cho phái nam là 60%, và tỷ lệ cho phái nữ là 46%. Tại Vettaikaranpudur, 10% dân số nhỏ hơn 6 tuổi.
Vengurla

| Vengurla |
| --- | --- |
Vengurla
Quốc gia:  Ấn Độ
Bang: Maharashtra
Độ cao: 11 m (36 ft)
Dân số (2001)
 • Tổng cộng: 12,471
Múi giờ: UTC+05:30
Mã điện thoại: 2366
Vengurla là một thành phố và là nơi đặt hội đồng đô thị (municipal council) của quận Sindhudurg thuộc bang Maharashtra, Ấn Độ.
Địa lý

Vengurla có vị trí 15°52′B 73°38′Đ﻿ / ﻿15,87°B 73,63°Đ﻿ / 15.87; 73.63 Nó có độ cao trung bình là 11 mét (36 feet).
Nhân khẩu

Theo điều tra dân số năm 2001 của Ấn Độ, Vengurla có dân số 12.471 người. Phái nam chiếm 49% tổng số dân và phái nữ chiếm 51%. Vengurla có tỷ lệ 81% biết đọc biết viết, cao hơn tỷ lệ trung bình toàn quốc là 59,5%: tỷ lệ cho phái nam là 86%, và tỷ lệ cho phái nữ là 76%. Tại Vengurla, 10% dân số nhỏ hơn 6 tuổi.
Đức Mẹ Naju

Đức Mẹ Naju hay Đức Mẹ khóc tại Naju dùng để chỉ một hiện tượng mà một số người cho là đã xảy ra đối với Tượng Đức Maria tại thành phố Naju, miền nam Hàn Quốc khi pho tượng này chảy nước mắt trong 700 ngày, từ ngày 30 tháng 6 năm 1985 đến ngày 14 tháng 1 năm 1992. Pho tượng cũng được cho là đã toát ra dầu thơm và đổ máu.
Bức tượng là sở hữu của gia đình ông bà Julia Kim (Tên bà là Hong Sun Youn và tên ông là Man Box Julio Kim), một gia đình Công giáo trong thành phố. Bà Julia được cho là người được Đức Mẹ hiện ra để mời gọi mọi người cầu nguyện cho có sự an bình trên thế giới. Tuy nhiên cho đến này, hiện tượng Đức Mẹ khóc tại Naju vẫn chưa được tòa thánh Vatican công nhận. Giới chức công giáo địa phương gần đây cũng phủ nhận điều này và tuyên bố dứt phép thông công những người đến đây cầu nguyện.
Thị nhân

Julia Kim sinh năm 1947. Năm 25 tuổi, bà kết hôn với Juliô. Ông bà sinh được 4 người con là Rosa, Tomas, Térèsa và Philip. Trước đó, cả hai theo đạo Tin Lành và từ năm 1981, hai người gia nhập đạo công giáo.
Ông Lubino Park là khách hàng quen thuộc ở cửa hàng của gia đình bà. Ông bị chứng bệnh sưng phổi và đã xin bà Julia cầu nguyện cho trước khi khám nghiệm giải phẫu. Bà đã cầu nguyện cho ông. Kết quả sau ba lần tái khám, bác sĩ cho hay ông đã khỏi bệnh. Để trả ơn bà Julia, ông đã tặng bà bức tượng Đức Mẹ ban ơn làm kỷ vật. Đó là nguồn gốc của pho tượng Đức Maria.
Biến cố

Về sự việc Đức Mẹ khóc, Bà Kim thuật lại: "...tôi đến Naju lúc 11 giờ 20 khuya ngày 30 tháng 6 năm 1985. Tôi đọc kinh Mân côi xin cho kẻ có tội được ơn trở lại và cho những người đang đau khổ tại Kwangju. Đang khi đọc kinh, tôi ngạc nhiên thấy nước mắt chảy dài trên đôi mắt tượng Mẹ. Tôi hồ nghi không phải là nước mắt Mẹ nên tôi đánh thức chồng tôi đang ngủ gục, để nhìn cho rõ. Hai chúng tôi nhìn sát mắt Mẹ và chúng tôi xác định là nước mắt thật sự đã chảy ra từ khoé mắt Mẹ".
Sáng hôm sau khi đến quan sát lại, bà thấy vệt nước chảy từ khoé mắt mẹ hôm qua, giờ vẫn còn chảy đều nhưng bà và chồng đã không tiết lộ chuyện này cho người ngoài. Tuy nhiên sau đó sự việc được nhiều người truyền tai nhau và gia đình ông bà Juliô đã trở thành nơi cầu nguyện suốt đêm ngày. Đức mẹ được cho là đã đổ lệ suốt ba tháng.
Từ ngày 18 tháng 7 năm 1985, bà Julia tự nhận là mình được đón nhận những thông điệp của Đức Mẹ và Chúa Giêsu. Theo đó, Đức Mẹ kêu gọi cầu nguyện để ngăn chặn tội ác, cầu nguyện cho hàng linh mục, tu sĩ, tiếp nhận Thánh Thể và trở nên Tông Đồ của Mẹ. Tiếp đó, bà Julia được cho là đã xuất thần xuất hiện dấu đanh ở chân và máu chảy ra lần đầu vào ngày 19 tháng 10 năm 1987 và tiếp tục trong những lần sau đó.
Chú thích

↑  Linh mục Raymond Spies Anyang, Đại Hàn. “Lời giới thiệu của linh mục linh hướng của Julia”. Bản gốc lưu trữ ngày 3 tháng 10 năm 2013. Truy cập ngày 29 tháng 9 năm 2013.
↑  “Thứ tự các biến cố tại Naju”. Truy cập ngày 29 tháng 9 năm 2013.[liên kết hỏng]
↑  “Đức Mẹ Khóc Tại Nước Đại Hàn”. Website cộng đoàn Mẹ Đồng Công. Truy cập ngày 29 tháng 9 năm 2013.[liên kết hỏng]
↑  “Sơ Lược Biến Cố Đức Mẹ Khóc Tại Naju, Đại Hàn”. Bản gốc lưu trữ ngày 3 tháng 10 năm 2013. Truy cập ngày 29 tháng 9 năm 2013.
↑  “Tiểu sử Chị Julia Kim”. Bản gốc lưu trữ ngày 3 tháng 10 năm 2013. Truy cập ngày 29 tháng 9 năm 2013.
↑  “Thứ Tự Các Biến Cố Đức Mẹ Khóc Và Huyết Lệ Tại Naju, Đại Hàn”. Bản gốc lưu trữ ngày 3 tháng 10 năm 2013. Truy cập ngày 29 tháng 9 năm 2013.
↑  “Ghi Nhận Sự Kiện Những Lần Hiện Ra Tại Các Nước và Phép lạ Thánh Thể tại Naju Đại Hàn”. Tài liệu Thánh Mẫu. Bản gốc lưu trữ ngày 2 tháng 10 năm 2013. Truy cập ngày 29 tháng 9 năm 2013.
↑  “Chứng Tá của Đức Giám mục Dominic Su”. Bản gốc lưu trữ ngày 3 tháng 10 năm 2013. Truy cập ngày 29 tháng 9 năm 2013.
↑  Victorinus K. Youn, Tổng Giám mục Kwangju. “Bản Tuyên bố về "Những Hiện Tượng và Thông Điệp liên hệ đến Julia Youn,Naju, và tượng Đức Mẹ của chị ta"”. Bản gốc lưu trữ ngày 3 tháng 10 năm 2013. Truy cập ngày 29 tháng 9 năm 2013.
↑  “Vạ Tuyệt Thông dành cho nhóm tự nhận đã Thị kiến Đức Mẹ ở Naju”. Vietcatholic. Truy cập ngày 29 tháng 9 năm 2013.
Gopalganj

| Gopalganj |
| --- | --- |
Gopalganj
Quốc gia:  Ấn Độ
Bang: Bihar
Độ cao: 66 m (217 ft)
Dân số (2001)
 • Tổng cộng: 54,418
Múi giờ: UTC+05:30
Mã điện thoại: 6156
Gopalganj là một thành phố và khu đô thị của quận Gopalganj thuộc bang Bihar, Ấn Độ.
Địa lý

Gopalganj có vị trí 26°28′B 84°26′Đ﻿ / ﻿26,47°B 84,43°Đ﻿ / 26.47; 84.43 Nó có độ cao trung bình là 66 mét (216 feet).
Nhân khẩu

Theo điều tra dân số năm 2001 của Ấn Độ, Gopalganj có dân số 54.418 người. Phái nam chiếm 53% tổng số dân và phái nữ chiếm 47%. Gopalganj có tỷ lệ 63% biết đọc biết viết, cao hơn tỷ lệ trung bình toàn quốc là 59,5%: tỷ lệ cho phái nam là 70%, và tỷ lệ cho phái nữ là 55%. Tại Gopalganj, 15% dân số nhỏ hơn 6 tuổi.